A Poll, a Poll, a very simple Poll!
Nick George
Ranch Hand
Posts: 815
posted 13 years ago
Seems to me that the best way to keep an accurate tally of this poll (punch cards eliminated for logistical reasons) is that everyone post the current tally. One need only look at the last post and add one to the option of their choice, and, barring foul play, a accurate tally can be kept.
I've seen it done both ways, in about equal numbers, and I have a passing curiosity...
Which do you find to be more asthetically acceptable?
Choice A:
Choice B:
As administer of this poll, I, in the name of true neutrality, shall abstain from answering.
[ May 09, 2004: Message edited by: Joseph George ]
I've seen it done both ways, in about equal numbers, and I have a passing curiosity...
Which do you find to be more asthetically acceptable?
Choice A:
Choice B:
As administer of this poll, I, in the name of true neutrality, shall abstain from answering.
[ May 09, 2004: Message edited by: Joseph George ]
I've heard it takes forever to grow a woman from the ground
Tim West
Ranch Hand
Posts: 539
posted 13 years ago
I vote B.
I know everyone knows the issues on this one, but for me the selling point is when you want to have a two-line conditional:
vs.
It clearly separates the conditional from the body of the if statement.
And yes I know I could use a temporary variable, but I don't wanna. I could also have a blank line before the System.out call, but then I might have well have put the opening brace in the blank line
The worst thing about style discussions is that very often the code samples are simple. If all variables/methods had short names and you never had more than two in a compound if-statement, I'd have voted A. In real-life code, I go B.
Hmm...who's with me??
--Tim
I know everyone knows the issues on this one, but for me the selling point is when you want to have a two-line conditional:
vs.
It clearly separates the conditional from the body of the if statement.
And yes I know I could use a temporary variable, but I don't wanna. I could also have a blank line before the System.out call, but then I might have well have put the opening brace in the blank line
The worst thing about style discussions is that very often the code samples are simple. If all variables/methods had short names and you never had more than two in a compound if-statement, I'd have voted A. In real-life code, I go B.
Hmm...who's with me??
--Tim
shankar vembu
Ranch Hand
Posts: 309
Warren Dew
blacksmith
Ranch Hand
Ranch Hand
Posts: 1332
2
posted 13 years ago
Seems like there should be a "programming practices" forum for this kind of thread. Then again, I guess it's a religious topic, after all!
I've thought a lot about this one. I believe there was a study by NASA which found that B led to fewer bugs, because it was easier line up the braces when reading the code. On the other hand, it seems to me like more and more experienced coders are using A, presumably because it can save significant amounts of vertical space, allowing you to see more code without scrolling. I've developed a style with elements of both:
This way, I don't have to pick between the A people and the B people - they can both get equally upset at my formatting!
A: 2
B: 5
[ May 10, 2004: Message edited by: Warren Dew ]
I've thought a lot about this one. I believe there was a study by NASA which found that B led to fewer bugs, because it was easier line up the braces when reading the code. On the other hand, it seems to me like more and more experienced coders are using A, presumably because it can save significant amounts of vertical space, allowing you to see more code without scrolling. I've developed a style with elements of both:
This way, I don't have to pick between the A people and the B people - they can both get equally upset at my formatting!
A: 2
B: 5
[ May 10, 2004: Message edited by: Warren Dew ]
Ashok Mash
Ranch Hand
Posts: 1936
posted 13 years ago
A
To me its simple, '}' closes a construct, not an opening braces - '{'.
To me its simple, '}' closes a construct, not an opening braces - '{'.
[ flickr ]
posted 13 years ago
My opinion: all arguments based on extra semicolons, code alignment, etc are more or less irrelevant if you're using an editor or IDE to auto-format your code. If you're still making the extra-semicolon error, then you seriously need better tools. The only real basis for argument here is which is easier to read. Again, with decent tools, good syntax highlighting is going to make the distinction less important.
Lest you think I'm a slave to a particular IDE, actually these arguments hold perfectly well for Emacs, which I used exclusively for years until quite recently (now I'm a huge IntelliJ fan.)
Now, as far as my feelings on the poll question: I think B is harder to read, because that extra blank line disconnects the condition from the action. Far more important, I think, is a blank line before the condition, not after; i.e.,
is much worse than
but
if far, far, far worse. In this last sample, the extra blank line from the brace serves to separate the condition from the action, and so the condition looks like it's associated (in some way) with the previous statement. The last permutation is
and again, the extra line with the brace makes the association of the condition and the action less clear.
So I vote for A, and the tally is now
a:4
b:7
Lest you think I'm a slave to a particular IDE, actually these arguments hold perfectly well for Emacs, which I used exclusively for years until quite recently (now I'm a huge IntelliJ fan.)
Now, as far as my feelings on the poll question: I think B is harder to read, because that extra blank line disconnects the condition from the action. Far more important, I think, is a blank line before the condition, not after; i.e.,
is much worse than
but
if far, far, far worse. In this last sample, the extra blank line from the brace serves to separate the condition from the action, and so the condition looks like it's associated (in some way) with the previous statement. The last permutation is
and again, the extra line with the brace makes the association of the condition and the action less clear.
So I vote for A, and the tally is now
a:4
b:7
Jeffrey Hunter
Ranch Hand
Posts: 305
posted 13 years ago
I've used both formats depending upon the conventions set up at the particular job, and I think that it's a minor point as long as the code is well constructed otherwise.
Given a preference, or when I am the one setting up the conventions, I prefer A; mostly for reasons that echo EFH's post.
bear
a: 6
b: 7
Given a preference, or when I am the one setting up the conventions, I prefer A; mostly for reasons that echo EFH's post.
bear
a: 6
b: 7
Mani Ram
Ranch Hand
Posts: 1140
Warren Dew
blacksmith
Ranch Hand
Ranch Hand
Posts: 1332
2
posted 13 years ago
Ernest Friedman-Hill:
My opinion: all arguments based on extra semicolons, code alignment, etc are more or less irrelevant if you're using an editor or IDE to auto-format your code.
I agree that legibility should be the primary issue, though I think the jury is out on which is more legible.
On the other hand, I think autoformatting can be a bad thing because of its effects when doing maintenance. If you make a 'fix' that turns out not to work, and you change the code back, it will still show up different on a diff tool if it's been automatically reformatted in the meantime. This can make it much more time consuming when trying to track down subtle bugs that were introduced in earlier versions of code - especially since a common cause of such bugs are exactly fixes that didn't work, but that the programmer neglected to change back.
My opinion: all arguments based on extra semicolons, code alignment, etc are more or less irrelevant if you're using an editor or IDE to auto-format your code.
I agree that legibility should be the primary issue, though I think the jury is out on which is more legible.
On the other hand, I think autoformatting can be a bad thing because of its effects when doing maintenance. If you make a 'fix' that turns out not to work, and you change the code back, it will still show up different on a diff tool if it's been automatically reformatted in the meantime. This can make it much more time consuming when trying to track down subtle bugs that were introduced in earlier versions of code - especially since a common cause of such bugs are exactly fixes that didn't work, but that the programmer neglected to change back.
| Consider Paul's rocket mass heater. |