A Poll, a Poll, a very simple Poll!

[Nick George]

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:

   if(joe.notSuchABadGuy()){
      women.oughtToShunHimLess();
   }

Choice B:

   if(joe.notSuchABadGuy())
   {
      women.oughtToShunHimLess();
   }

As administer of this poll, I, in the name of true neutrality, shall abstain from answering.
[ May 09, 2004: Message edited by: Joseph George ]

[Tim West]

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:

if (myGoodFriendJoe.isAFamousActor() &&
    Constants.notAllowedMoreThanEightyCharsPerLine())
{
    System.out.println("Go Joe");
}

vs.

if (myGoodFriendJoe.isAFamousActor() &&
    Constants.notAllowedMoreThanEightyCharsPerLine()) {
    System.out.println("Go Joe");
}

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

[Gail Schlentz]

I'm with ya, Tim! I vote "B".

[paul wheaton]

B

[shankar vembu]

I've always coded using choice A.
As per thr original poster's instructions to keep a count of choices...
A: 1
Anybody interested in joining me, please add 1 to the latest count
Regards.

[Jose Velarde]

A

[Manish Hatwalne]

B for me! B=4
However, with choice "A", one can get away with using a semi-colon ; at the end of the condition, whereas with B it would change the intention of the entire code. Many seasoned programmers are used to having a semi-colon at the end of every line.
- Manish

[Joyce Lee]

Though Sun recommends choice A - Sun Coding Convention, I prefer choice B.
Joyce

[Warren Dew]

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:

/*  c code since this is a non-Java forum
 */
if (joe_flags & nice_flag)
{   joe_gets_girl();
}

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]

A
To me its simple, '}' closes a construct, not an opening braces - '{'.

[David O'Meara]

B always.

[fred rosenberger]

As a reminder, it's makes life easier for everyone if you post the tally with your answer...
i prefer b.
tally
a:3
b:7

[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. 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.,

doSomething();
if (somethingElse()) {
  doSomethingElse();
}

is much worse than

doSomething();
if (somethingElse()) {
  doSomethingElse();
}

but

doSomething();
if (somethingElse())
{
  doSomethingElse();
}

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

doSomething();
if (somethingElse())
{
  doSomethingElse();
}

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]

I agree that the blank line before the condition is better than after the condition. This is the way I've done it at least.

joe.WakeUp();
/* blank line here */
if (joe.hasHangover()) {
   joe.hitSnooze();
}

So, I vote A:

A: 5
B: 7

[ May 12, 2004: Message edited by: Jeffrey Hunter ]

[Bear Bibeault]

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

[Mani Ram]

I go for 'A', just because I'm used to it.

A: 7
B: 7

Equalizer!

[Warren Dew]

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.