IMO, just learn to love whatever your favorite IDE (or the IDE your employer insists that you use) does for free, when it reformats your code.

A friend of mine loves to use Xcode, and it's autocomplete feature is set to use method 1 by default. However, I'm not really a big fan of method 1 because it can scrunch the code together when you have control structures with statements long enough such that they're pushed onto the next line. I've used Xcode before, and I got around this by simply turning off the autocomplete functionality for brace placement. I normally just use Text Wrangler for writing code and g++ to compile it. If I do use an IDE, it's usually Bloodshed's Dev-C++. It's free and works well enough for the things I've been needing to do in my courses.

One thing I've noticed with different IDEs is the way they choose to format indentation when opening a file. Most of them have an option to reformat the code using whatever tab setting you want, but if they don't, it can really make of mess of things.

Staff: Mentor

Staff: Mentor

I prefer method 2, for the reasons that DrGreg and jtbell give.

However, method 1 is the preferred method in Javascript programming, which I am doing more of, lately. In Javascript, method 2 can lead to unexpected results, due to the quirky nature of this language. I can't think of an example off the top of my head, but I'll dig one up and post it later.

This is a theological arguement. Hard core C programmers who learned at the knee of K&R's white book will prefer #1 for no better reason than that that's the way the masters do it.

To try to resolve this among several dozen programmers who worked for me some years back, I took the issue to NON-programmers and without exception they said that method #1 is moronic (or words to that effect).

I agree. I also like the visual separation it creates between structures and code blocks.

I sometimes use method 2 for this reason. However, I also use method 1 for this reason.

That is, I often don't want the separation. e.g. short loops, conditionals, and functions are often best read as one unit. Adding the spacing breaks apart the flow of the code. It also means that the breaks between units require dramatic formatting.

Even groups of functions should often be clustered. e.g. a block of code like

to define the other comparison operators on a class in terms of < and == already takes up more space than it really deserves. Aside from assuring you don't exceed 78 character lines, there is nothing to gain from "properly" formatting these.

Style 1 causes the JavaScript interpreter to think that you forgot to put a ; on the line with the return statement, so to help you out, it adds one there. This means that what is actually returned is undefined, not an object with its status property set to true.

To prevent this behavior, include the right brace - { - on the same line with the return keyword.

Personally, I prefer method 1 as I don't really like all the extra lines of code method 2 results in. However, as long as you are consistent within a given project, there should be no problems for another coder to understand what you are doing.

I prefer method one. Mostly because I consider two to be a waste of real estate on my screen. If my methods are so long that I can't see the alignments well, that tells me that I'm probably overcoding it.

I've been on projects where the code gets auto-formatted to method two when it's checked into the code repository. I would much rather see the people that implement that nonsense to focus on putting in proper error handling or commenting their code.

On a related note, if you want a good laugh on how not to code, check out the link below.