Actually, though. I do have one 'odd' habit that would probably get me smacked by some people.
if(condition) {/*dostuff in one line*/}
I never use 'braceless' blocks.
That's actually considered good, not something that'll 'get you smacked'. 
It's not something I follow myself, but it is a good habit. It's not all that odd or uncommon either.
I also never use non-braced blocks. They only cause confusion and leave the potential for future problems, especially when adding debug code to print values or just later updating code to do more than a single statement of work.
I prefer to keep my opening braces on the same line. It feels cleaner and it reduces the use of vertical real-estate.
I personally don’t understand the main reason people put them on their own lines, which is that they are easier to pair up with the closing brace.
When I am scanning up from a closing brace to its opening brace, I go by indentation level and nothing else, so it doesn’t matter if there is specifically an opening brace at the same level as the closing brace or if it is an if, while, for, function declaration, etc.
Scanning only based on indentation levels keeps things simple and it means that code where braces are on their own lines is just as easy to read for me as any other style.
It is a huge problem when trying to read code that has not been indented consistently, but we can all agree that is a no-no. Regardless of your bracing style, proper indentation is necessary.
But in practice I use whichever style is necessary.
In my own works, it is necessary (by the law of satisfying one’s own taste) to keep them on the same lines as the if/while/etc.
At the office, the general style is to put them on their own lines. They aren’t so picky on that but I do it just to keep the code as consistent as possible, because that matters much more than which brace style you use.
L. Spiro
Yeah. Indentation is the main thing. Anime-Planet changed the format of a table in their user-page anime listing and I spent an hour making a 5-minute fix to a greasemonkey script last night because the html is indented using what appears to be the shotgun whitespace method. Finally I just copied out the page source into SciTE and corrected the indentation and everything became clear....
Well...
As clear as JS DOM gets, anyway.
When it comes to curly braces... I used to do this...
if (x == 0)
// do something
else
// do something else
But during university I was taught that I should always use curly braces and I should always comment everything - my lecturer was pretty strict with coding styles and marked us on the style instead of the code itself. Since leaving my coding style has changed from above to..
// Used to check if x is equal to 0
if (x == 0)
{
x = 5; // give x the value of 5
}
else // if x is not equal to 0 then do this
{
x = 4; // give x the value of 4
}
Personally I now find this easier on the eyes and easier to read,
However i've found myself now starting to do this for functions
void ReturnX() { return x; }
Someone needs to spank your lecturer if they think that comments such as those are acceptable. That's as bad as
i++; // increment i
EDIT: Comments should describe the usage or intent of the code, not the syntax
// Used to check if x is equal to 0 if (x == 0) { x = 5; // give x the value of 5 } else // if x is not equal to 0 then do this { x = 4; // give x the value of 4 }
Did he mark you down for not commenting the curly braces themselves ?
Pretty much every comment there is unnecessary in my opinion. There is such a thing as commenting too much and hindering readability.
As for me I tend to use braces in this manner:
void func() {
}
I'm not sure why it's just habit. I've recently started using C# and found the auto-formatting in VS very annoying. Took me a while to work out how to disable it.
Edit:
Just occurred to me that the block Andy posted was likely just an example.
in-fact i wouldn't mind if C++ ditched the braces completely in the next version of the standard and switched to using indentation to set the scope)
Easy there, trigger.
EDIT:
By the way, I've never asked anyone this because I've rarely had anyone else read my code, but I wonder if this habit I have is a case of "overcommenting." Basically, I keep the opening brace on the same line, and I always comment the closing brace, even if it's really really obvious. It helps me with re-reading my code, but I do sometimes wonder if another programmer might think I'm overdoing it haha. For example:
void myFunction(){
if(/*condition*/){
doSomething(x, y);
doSomethingElse(a, b);
switch(/*condition*/){
case blah:
break;
}//end of switch
}//end of if
}//end of myFunction()
The only comment I want in that code is one explaining what `x' means, and why it makes sense that up to that point in the code values like 0 or something else made sense, and after that point in the code 4 and 5 make sense. Separating x into two variables (one for whatever it represented up to that point in the code and one for whatever it represented after that point in the code) and giving them good names would result in code that is much more readable than that horrible thing you just posted.
// Used to check if x is equal to 0 if (x == 0) { x = 5; // give x the value of 5 } else // if x is not equal to 0 then do this { x = 4; // give x the value of 4 }
int default_number_of_tax_allowances = (number_of_children == 0) ? 5 : 4;
EDIT:
By the way, I've never asked anyone this because I've rarely had anyone else read my code, but I wonder if this habit I have is a case of "overcommenting." Basically, I keep the opening brace on the same line, and I always comment the closing brace, even if it's really really obvious. It helps me with re-reading my code, but I do sometimes wonder if another programmer might think I'm overdoing it haha. For example:void myFunction(){ if(/*condition*/){ doSomething(x, y); doSomethingElse(a, b); switch(/*condition*/){ case blah: break; }//end of switch }//end of if}//end of myFunction()
EDIT:
By the way, I've never asked anyone this because I've rarely had anyone else read my code, but I wonder if this habit I have is a case of "overcommenting." Basically, I keep the opening brace on the same line, and I always comment the closing brace, even if it's really really obvious. It helps me with re-reading my code, but I do sometimes wonder if another programmer might think I'm overdoing it haha. For example:void myFunction(){ if(/*condition*/){ doSomething(x, y); doSomethingElse(a, b); switch(/*condition*/){ case blah: break; }//end of switch }//end of if}//end of myFunction()
I actually started doing that recently because it really helps clear up the end of a 4- or 5-level nested loop if you want to add to it later. After using lisp in college, I made a habit of always writing my opening and closing brace/parens IMMEDIATELY, and then adding the content inside. This leads to chains of closing braces at the end of some of my more workhorse functions or complex algorithms and it's really nice to have the tags via comments to see where you want to jump in to do something "inside loop 2 but post switch case".
Also, in general to the thread, I ALWAYS brace my conditionals, even if they're on one line. I've had too many stealth bugs creep in because I had skipped braces on a one-line if statement and added a second instruction.
I too automatically create the open and closed braces for bodies of code and then go back in and put the code in the body.
I don't think putting a comment at the end of braces is a bad idea at all, especially if you have a lot of nesting and things going on. Whatever helps you and others understand your code easier is not a waste of time in my opinion as long as you don't over do it.
