The curley bracket!

[acoder]

My style:

if (<condition>) singleStatement;
if (<condition>) {
   state1;
   state2;
   state3;
} else if (<condition>) {
   state1;
   state2;
} else singleStatement;

intIndex++;

That's exactly how I code. Agree on the 'uglier' point too.

[AricC]

intIndex++ wherever I can use it. CFScript (Coldfusion scripting language) doesn't allow these so I'm forced to use intIndex = intIndex + 1 (so much typing!)

Wow! That has to heinous! Maybe that is why Cold Fusion isn't widely used anymore. Although, I don't know much about it :)

[r035198x]

I prefer

 if(condition) { 
}

I like to see the closing brace close a construct rather than another brace. It is also easier to memorise which statement is on which line number if the braces are placed this way. This is also the prefered Java convention in the Java formatting conventions.

[Banfa]

if (<condition>) singleStatement;

Personally I think this is particularly bad and confusing, and breaks you rule of indenting show code level.

Most of the coding standard I have worked with specifically stipulate that you MUST ALWAYS use braces round a code block. This actually reduces maintenance work in the long run because of the slight tendancy towards people forgeting to add the braces if they add an extra statement to the code block.

As an aside I have worked with specification languages (TTCN specifically) where the indent level actually did give the code level, no braces or other syntax to indicate when a code block ended just code back out at the previous indentation level. Obviously putting in an extra TAB or leaving one out is quite easy but would cause horendous errors in the generated code.

[Ganon11]

As an aside I have worked with specification languages (TTCN specifically) where the indent level actually did give the code level, no braces or other syntax to indicate when a code block ended just code back out at the previous indentation level. Obviously putting in an extra TAB or leaving one out is quite easy but would cause horrendous errors in the generated code.

I don't know about you, but that seems like a terrible idea. Although it would force any programmers to learn proper indenting techniques, it would be a killer learning curve.

[Banfa]

I don't know about you, but that seems like a terrible idea. Although it would force any programmers to learn proper indenting techniques, it would be a killer learning curve.

It was a complete nightmare, the code was shipped to us written by a 3rd party and then we used another 3rd party compiler to compile the TTCN into compilable C.

The TTCN source was full of bugs and the 3rd party compiler was full of bugs. getting a working system was a lot of hardwork everytime they produce a new version of either.

[Motoma]

My style:

if (<condition>) singleStatement;
if (<condition>)
{
   state1;
   state2;
   state3;
}
else if (<condition>)
{
   state1;
   state2;
}
else
   singleStatement;

intIndex++;

I use the second method, and here's why:
As part of my last job, I would assist one of my professors in teaching his students PHP. A very common error among students was leaving brackets open. The easiest way for my to have them search for it was through the "counting method." You simply work your way down the page, at a certain scope (determined by the intent), counting up for every { you hit and counting down for every } you hit. If you ever go negative, or enter a higher scope when you aren't at 0, you have an error.
Teaching this got me in the habit of coding this way (however, I am starting to get lazy :P)

[sicarie]

I use the second method, and here's why:
As part of my last job, I would assist one of my professors in teaching his students PHP. A very common error among students was leaving brackets open. The easiest way for my to have them search for it was through the "counting method." You simply work your way down the page, at a certain scope (determined by the intent), counting up for every { you hit and counting down for every } you hit. If you ever go negative, or enter a higher scope when you aren't at 0, you have an error.
Teaching this got me in the habit of coding this way (however, I am starting to get lazy :P)

I used the first method until I got stuck in a grad-level Java coding course last semester of my senior year (I'm still mad at my advisor for that), and the teacher there used the second. I tend to be pretty OCD when it comes to how my code looks, and I had to conform to his standard because of all the libraries he gave us that we had to modify and add to. After doing nothing but coding like that for 3 months, I was unable to break the habit.

(I also put all my single statement conditionals in curly braces, just in case I have to go back later and change them)

[Motoma]

(I also put all my single statement conditionals in curly braces, just in case I have to go back later and change them)

I usually keep single statements on the same line as their conditions, unlike the else statement in my previous post.

The other reason I like the first is because putting a { on it's own line makes things look empty. When there is space just sitting there after a condition, there is no reason not to fill it with a cursory description of the condition you are in:

if(something == happened())
{ // Must comment on condition, otherwise I will look empty!
  docrap();
  twiddle.fingers();
  crash();
}

[sicarie]

The other reason I like the first is because putting a { on it's own line makes things look empty. When there is space just sitting there after a condition, there is no reason not to fill it with a cursory description of the condition you are in:

if(something == happened())
{ // Must comment on condition, otherwise I will look empty!
  docrap();
  twiddle.fingers();
  crash();
}

Ah, my comments on condition usually come immediately above, and then I comment at the end what the result is:

// here I check to see if something happened
if (something == happened) {
    twiddle.fingers();         // I steal code too, by the way ;)
} // and comment here where twiddle.fingers() might be necessary/have to be checked

[Ganon11]

// here I check to see if something happened
if (something == happened) {
    twiddle.fingers();         // I steal code too, by the way ;)
} // and comment here where twiddle.fingers() might be necessary/have to be checked

Comments? Documentation! Pfft! Preposterous.

>.>

[Motoma]

Ah, my comments on condition usually come immediately above, and then I comment at the end what the result is:

// here I check to see if something happened
if (something == happened) {
    twiddle.fingers();         // I steal code too, by the way ;)
} // and comment here where twiddle.fingers() might be necessary/have to be checked

This seems like it could get confusing with multiple conditions with else ifs:

// here I check to see if something happened
if (something == happened) {
    twiddle.fingers();          // Verbose comment that probably runs off the screen or causes a word-wrap.
} // Is this a comment about twiddle.fingers() or then next condition?
else if (something.else == happened) {
    dance.wildly();                  // Comment which is not properly aligned with the above comment, causing me to cry like a sissy.
} // I just love to dance.

Working from my laptop, I often curse when people put comments at the end of lines of code...Verbosit y is desired; however, scrolling and word-wrapping are not! Comments MUST all have similar indentation!!

if (something == happened)
{ // Oh Em Ef Gee, something happened.
    twiddle.fingers();
} // Really dodged a bullet there!
else if (something.else == happened)
{ // I have no idea what is going on
    dance.wildly();
} // Beats the crap out of walking in random patterns

[sicarie]

This seems like it could get confusing with multiple conditions with else ifs:

// here I check to see if something happened
if (something == happened) {
    twiddle.fingers();          // Verbose comment that probably runs off the screen or causes a word-wrap.
} // Is this a comment about twiddle.fingers() or then next condition?
else if (something.else == happened) {
    dance.wildly();                  // Comment which is not properly aligned with the above comment, causing me to cry like a sissy.
} // I just love to dance.

Working from my laptop, I often curse when people put comments at the end of lines of code...Verbosit y is desired; however, scrolling and word-wrapping are not! Comments MUST all have similar indentation!!

if (something == happened)
{ // Oh Em Ef Gee, something happened.
    twiddle.fingers();
} // Really dodged a bullet there!
else if (something.else == happened)
{ // I have no idea what is going on
    dance.wildly();
} // Beats the crap out of walking in random patterns

// here I check to see if something happened
if (something == happened) {
    // would usually comment here on twiddle.fingers() if necessary...
    twiddle.fingers();          // definitely didn't think this one through in the heat of the moment (and trying to get you to cry again for pointing it out)
} // Is this a comment about twiddle.fingers() or then next condition?

I'm very liberal with my comments, and feel no remorse about putting a comment line in between spaces

/* this would have to be a pretty weird function to require comments before,
   during, and after the function executes */
if (something == happened) {
    // this is where I would usually put the comment
    twiddle.fingers();
} // say twiddle.fingers() doesn't need to be set below, or another test does
// then comment on else-if (if necessary)
else if (something == didnt_happen) {
    make.somethingHappen();
} // so twiddle now needs to be set

[sicarie]

Yeah, yours definitely looks cleaner.

/me ponders going off on discussion about code obfuscation and how it relates to job security....

[enreil]

I just have to chime in my support of the second method. Aesthetics aside, that makes it much easier to logically segment my code with a quick glance. The first way, though cleaner, I find takes a bit more time to decipher.

Also, I have to support the ++ way.