Basic Code Layout Question

Question

HI, I have a simple question, I've asked 3-4 different people and have had different answers from each of them.

Which code layout is better and used more?

does it really matter as long as it's consistent?

Which is seen as better practice in the world of working as a programmer?

Eg

A)

for(int i=0;i<8;i++)
{
    for(int p=0;p<8;p++)
    {
        if(array[i][p]->Equals(String))
        {
                    //Do Stuff
        }
    }
}

OR

B)

for(int i=0;i<8;i++){
 for(int p=0;p<8;p++){
  if(array[i][p]->Equals(String)){
                    //Do Stuff
                }
        }
}

Thanks, Tim

Answer 1

This is entirely subjective. Both are popular.

Answer 2

Several published style guides exist -- for example, Google's is here, and it mandates, for functions:

ReturnType ClassName::FunctionName(Type par_name1, Type par_name2) {
  DoSomething();
  ...
}

and for blocks:

if (condition) {  // no spaces inside parentheses
  ...  // 2 space indent.
} else {  // The else goes on the same line as the closing brace.
  ...
}

with similar examples for other blocks.

So, look around a few such style guides, pick one that's from a somewhat prestigious source and that you like, and if anybody objects to your style just say "oh, I picked it up from X" (where X may be Google, geosoft, or whatever other source you like (many more are listed here).

Answer 3

There's no right or wrong here. It's up to the preference of you, or your team/organization.

As far as the braces go, my current team has chosen option B, but I actually prefer option A.

Personally I would recommend a little more spacing especially after the "for" and "if", and a bit more indentation on option B, for readability. But, that's just my preference.

Answer 4

In almost all cases in practice, there is a clear answer: Use the style that is currently in use in the codebase that you're working with. If you are starting a new project, use the style that is currently in use in the other projects maintained by the team that will be maintaining your code.

The codebases I've worked with have largely had their roots in GCC and other FSF software, which means that all of my projects have used the style with the "{" on a separate line. I could come up with justifications for why that's "better", but that's a matter of subjective style. Being consistent within a project and within a team is objectively better.

Answer 5

What, no middle ground? Just two examples, each designed to take a (relatively) extreme position?

Clearly, you've left out a whole bunch of intermediate examples with lots and lots of slightly different formatting rules.

You're not really putting any effort into it if you can't think of at least ten more variants. Two variants isn't enough focus on nuance.

You can -- if you want -- be lazy. A decent IDE will format for you. I use Eclipse and it formats for me and that's what I use without thinking about it at all.

You can also download and read open-source code and actually emulate styles you find there. That's a little less lazy approach, you do have to read other's people's code.

Answer 6

I am not sure its possible to come up with reasons why one is better than the other that arent completely subjective and only valid for a small set of projects.

I like the compressed style, it tends to make code more compact and since I like my functions to be compact and fit on screen it helps.

It drives other people nuts though, and they dont like not seeing a block start and end on its own line. I can see their point.

Usually its not a big deal as each developer uses their own settings and we let the source control system store it in an agnostic format (doesnt really matter which one).

Of course YMMV.

Answer 7

As some have already pointed out, you should use the style that is already in use by the code base or the team.

However, if you are in college or have never used a language that uses curly braces, I would suggest placing the curly braces on their own line. I have found that new developers can have problems identifying missing curly braces when they are placed on the same line as code. This probably isn't as big of a deal with modern IDEs.

Answer 8

When I was younger, I used to believe that all of these questions were matters of opinion, subjective, and best left to individual taste.

As I have aged, my vision has become increasingly astigmatic. Without surgery, astigmatism is correctable using either glasses or contacts -- but the correction is far from perfect.

Astigmatism makes reading harder, including reading code.

For a person with astigmatism, such as myself, identifiers_with_underscored_spacing are much easier to read than IdentifiersWithCamelCaseWordBreaks.

Similarly, for me, braces on lines by themselves are easier to read than braces sharing a line with code.

Therefore I recommend the second style you propose because it is more accessible.