|
I thought K&R put the function declaration on the previous line too.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
Reformat the whole lot to Whitesmiths style!
Then you can breathe easy... 
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
OriginalGriff wrote: Reformat the whole lot to Whitesmiths style!
I came to C/C++ from turbo pascal - so naturally I did C/C++ in the Whitesmiths style ...
I still guess that the primary reason for
void foo() {
}
was the 12" monitors of yesteryears ...
On the other hand, I guess the best reason for having a coding style-guide is to avoid wasting time discussing coding styles.
|
|
|
|
|
Whitesmith's rules!
I never seize to amaze over the triviality of this eternal style format discussion.
Who is to say one style is better or worse than another?
Is it not more important that the code is A. readable, B. intuitive, C. Bug Free!
What I truly detest in coding style is all the code written as if programmers were paid by each line of code (ancient format of reimbursement) and everyone simply tries to fill a load of dead line space whilst appearing smart.
This entire theme of discussion is in my years of writing code simply for small talk on coffee breaks and not really adding functionality in my personal opinion.
|
|
|
|
|
MRJIT wrote: What I truly detest in coding style is all the code written as if programmers were paid by each line of code (ancient format of reimbursement) and everyone simply tries to fill a load of dead line space whilst appearing smart.
Oddly, what I truly detest in coding style is the code packed so tightly as to be completely inscrutable to any other programmer --- to appear smart.
Truth,
James
|
|
|
|
|
James Curran wrote: Oddly, what I truly detest in coding style ...
I'll buy that for a dollar.
Sorry, saw the ads for Robocop, pulled up the original and recently rewatched it.
Use of var object being assigned using 5 levels of subroutine calls, gack
|
|
|
|
|
Spacing in code is similar to spacing in prose text documents:
-make_the_lines_too_long_and_chances_are_you'll_skip_lines_when_reading,_because_you_need_to_move_your_view_to_the_left_and_right_too_much (there's a reason text in newspapers is split into columns!)
- lines
too
short,
and
you'll
run
into
difficulties
recognizing
the
meaning
of
compound
statements
that
were
torn
apart
and
split
into
multiple
lines
- put in too many blank lines,
and you feel
like you're working more scrolling
than actually reading meaningful text
- put in toofew blanksandspaces andyouhave difficulties recognizing thecontent(program) structure.
Either way, people are different in how much separation they need to feel comfortable with a given text/program, or how little they need to make the text/program feel coherent. As an author/programmer, you need to find a sensible middle ground.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
MRJIT wrote: Is it not more important that the code is A. readable...
Yes readability does matter, and that's exactly why brace style matters.
MRJIT wrote: What I truly detest in coding style is all the code written as if programmers were paid by each line of code (ancient format of reimbursement) and everyone simply tries to fill a load of dead line space whilst appearing smart.
I have never understood the desire to save vertical space. Can anyone tell me why, in this day and age, vertical space is so important that it's worth sacrificing readability for?
The best brace style is the most readable one, and also the one that is least likely to get mangled during refactoring. Allman, of course.
|
|
|
|
|
StatementTerminator wrote: Can anyone tell me why, in this day and age, vertical space is so important ...
Putting a bunch of filler space does sacrifice readability when you have to scroll up and down to see what it is doing. I'm not complaining about putting a single statement on a single line. I'm talking about putting multiple lines of whitespace so you have 20 commands put in 100 lines of "code".
|
|
|
|
|
I can see that if there are a lot of pointless blank lines everywhere, I hate that myself. But putting an opening brace on its own line only adds one line per code block, and it doesn't add blank lines. Though I do think that blank lines can be useful to logically separate pieces of code, if used well.
I don't know this for a fact, but I strongly suspect that K&R style was at least partly adopted to save space in print. It became popular during a time when people were learning programming from examples in actual printed books, and when you are including code samples in print the vertical space really matters, that's money. But with modern IDEs capable of collapsing code blocks, I don't see it as much of an issue.
|
|
|
|
|
Usually an opening brace is preceded by a control statement such as if, for or while. In those cases, I see no reason to place the opening brace on a separate line. These, by themselves, are easily recognizable as the start of a code block, especially when used in combination with reasonable indention. This is especially obvious for
do {
Or would you really prefer
do
{?
As for collapsing code blocks, that suggestion isn't helpful. For one I collapse blocks only when it's contents aren't meaningful to the stuff I try to understand or fix - it doesn't make a difference how it's spaced or formatted in that case. Conversely, if parts of the block are relevant to me, I can't collapse it just because I don't like the formatting!
K&R style was influenced a lot by the page format in printing, that is true. But today, in a similar fashion, it is much influenced by how much we can comfortably display on the screen - and that is not so much different at all!
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Stefan_Lang wrote:
do {
Or would you really prefer
do
{?
I really do prefer the second one, actually. The reason is that the braces line up, making it easy to match up braces at a glance even when you have a lot of nested structures. It can also make debugging and refactoring easier, since you can quickly replace, comment, move around, etc. the control statement without messing with the braces. None of that is a huge deal however, and neither is the extra space used if you put it on a new line.
|
|
|
|
|
As mentioned before, any of the control keywords are just as good for me to recognize the start of a code block as a brace, so that is not a good reason in my book. A control keyword lining up with a closing brace is all I need.
This is all the more true when you have a lot of nested structures: it's hard to recognize the actual functionality of a code if half of the editor window shows only control statements and braces.
As for refactoring, why would you move the control statement without the succeeding block?
But as you said, none of this is a huge deal. For the code I currently deal with it probably would be a bad idea. It's old and riddled with control statements - it's hard to figure out what it does no matter the formatting, but not being able to see much of the relvant statements in the editor window because of added lines for braces would even be worse. For newly written code it probably would be much less of an issue either way.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
IMHO - the goal of formatting is to make the structure of the code visible, explicit, so the reader does not have to dig into the code and try to decipher its structure. Some people have the naive view that formatting as merely "pretty printing" or making the code neat and tidy. This leads to inconsistent formatting conventions and the mistaken idea that formatting is a matter of individual style rather than an engineering topic.
Making the code pretty with an individual style only accomplishes half of the goal of making the structure explicit. It does not provide a basis for a consistent set of guidelines for the formatting.
|
|
|
|
|
Member 10475170 wrote: This leads to inconsistent formatting conventions and the mistaken idea that formatting is a matter of individual style rather than an engineering topic.
It is a matter of individual style.
Conversely if you think it is not then presumably you have some objective data to back up the assertion that it provides measured benefit.
|
|
|
|
|
Maintenance programmers everywhere would like a word with you outside.
|
|
|
|
|
jschell wrote: Conversely if you think it is not then presumably you have some objective data to back up the assertion that it provides measured benefit.
hear hear
(Or should that be here here?? )
|
|
|
|
|
The problem is that everyone experiences program structures in a subtly different way, and thus, if asked to format the code accordingly, will use different styles. It's not so much that the programmers format the code with the goal in mind to make it "look pretty" - they format it in the way that makes the most sense to their personal perception.
The funny (or sad, depending on how you look at it) thing is, that the only objective argumments that you can get people to agree on are those related to "pretty printing", e. g. line length or width of indentation. It's pretty much impossible to agree on how to "correctly" express program structure in formating... 
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
|
|
|
|
|
Espen Harlinn wrote: is to avoid wasting time discussing coding styles.
Yes, wasting time is much better spent on what the sport team did last weekend and what it will do next weekend.
|
|
|
|
|
jschell wrote: Yes, wasting time is much better spent on what the sport team did last weekend and what it will do next weekend.
True, and everybody knows that we're wasting time, and not pretending to work 
|
|
|
|
|
OriginalGriff wrote: Reformat the whole lot to Whitesmiths style!
Then you can breathe easy... 
+1
Isn't that the real 1TBS? 
Ralf
|
|
|
|
|
Code VB instead! *Hides* 
It's an OO world.
public class Sander : Lazy<Person>{
public void DoWork(){ throw new NotImplementedException(); }
}
|
|
|
|
|
Well VB at least has the advantage of not being able to run on a crackdingleberry.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
Giving up coding seems a bit of an overreaction...
|
|
|
|
|
...I don't see a problem here! Does that make me a bad person?
Well fads they come and fads they go.
And God I love that rock and roll!
Well the point was fast but it was too blunt to miss.
Life handed us a paycheck, we said, "We worked harder than this!"
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
