Why do C# developers newline opening brackets?

Question

I've spent most of the last several years working mainly with C# and SQL. Every programmer I've worked with over that time was in the habit of placing the opening brace of a function or control flow statement on a new line. So ...

public void MyFunction(string myArgument)
{
     //do stuff
}

if(myBoolean == true)
{
    //do something
}
else
{
    //do something else
}

I have always been struck by how space wasteful this is, especially in if/else statements. And I know alternatives exist in later versions of C#, like:

if(myBoolean == true)
    //do something on one line of code

But hardly anyone used them. Everyone did the curly-brace-on-newline thing.

Then I got back into doing JavaScript after a long absence. In my memory, JavaScript developers used to do the exact same curly-brace-newline thing but with all the fancy new libraries and stuff, most developers put the opening brace after the declaration:

function MyJavaScriptFunction() {
    //do something
}

You can see the sense in this, because since using closures and function pointers has become popular in JavaScript, it saves a lot of space and makes things more readable. So I wondered why it wasn't seen as the done thing in C#. In fact, if you try the above construct in Visual Studio 2013, it actually reformats it for you, putting the opening brace on a new line!

Now, I just saw this question on Code Review SE: https://codereview.stackexchange.com/questions/48035/questions-responses-let-me-tell-you-about-you In which I learned that in Java, a language I'm not overly familiar with, it's considered de-rigour to open your curly braces right after the declaration, in modern JavaScript fashion.

I had always understood that C# was originally modelled after Java, and kept to a lot of the same basal coding standards. But in this instance, it seems not. So I presume there must be a good reason: what is the reason? Why do C# developers (and Visual Studio) enforce opening curly brackets on a new line?

Answer 1

The brace at the end of the line is the ancient K&R C standard, from Brian Kernighan and Dennis Ritchie's book The C Programming Language, which they published in 1978 after co-inventing the UNIX operating system and the C programming language (C was mostly designed by Ritchie, based on B, which another Bell employee Ken Thompson had adapted from the older BCPL programming language), at AT&T.

There used to be flame wars about "the one true brace style."

So Ritchie created the C language, and Kernighan wrote the first tutorial, when computer displays only showed a few lines of text. In fact, UNICS (later UNIX) development started on a DEC PDP-7, which used a typewriter, printer and paper tape for a user interface. UNIX and C were finished on the PDP-11, with 24-line text terminals. So vertical space was indeed at a premium. We all have slightly better displays and higher resolution printers today, right? I mean, I don't know about you, but I have three 24" 1080p displays in front of me right now. :-)

Also, so much of that little book The C Programming Language is code samples that putting the braces at the ends of the lines instead of on their own lines allegedly saved an appreciable amount of money on printing.

What is truly important is consistency throughout a project, or at least within a given source code file.

There are also scientific studies showing that the brace on its own line (indented to the same level as the code, in fact) improves code comprehension despite what people think they think of the aesthetics. It makes it very clear to the reader, visually and instinctively, which code runs in which context.

if( true )
    {
    // do some stuff
    }

C# has always supported evaluating a single command after a branching expression, by the way. In fact, that's the only thing it does, even now. Putting code in braces after a branching expression just makes that one command a goto (the compiler creates scope using jmp instructions). C++, Java, C# and JavaScript are all more or less based on C, with the same underlying parsing rules, for the most part. So in that sense, C# is not "based on Java."

Summing up, this is a bit of a religious/flame-war issue. But there are studies making it pretty clear that arranging code in blocks improves human comprehension. The compiler couldn't care less. But this is also related to the reason why I never put a line of code after a branch without braces--it's just too easy for me or another programmer to slap another line of code in there later and slip on the fact that it will not execute in the same context with the line right before or after it.

EDIT: Just go look at the Apple goto fail bug for a perfect example of this exact issue, which had very serious real world consequences.

if( true )
    doSomething();

becomes...

if( true )
    doSomething();
    doSomethingElse();

In this case, doSomethingElse() executes every time, regardless of the outcome of the test, but because it is indented to the same level as the doSomething() statement, it's easy to miss. This isn't really arguable; studies back this up. This is a big source of bugs introduced into source code during maintenance.

Still, I'll admit that JavaScript closure syntax looks a little silly with braces on their own lines...aesthetically. :-)

Answer 2

The reason C# developers do it is because it is the default setting of the Visual Studio auto-formatter. While this setting can be changed, most people don’t, and thus all developers in a team have to go with the majority.

As for why this is the default in Visual Studio, I don’t know.

Answer 3

As I hypothesized in this answer here - https://softwareengineering.stackexchange.com/a/159081/29029 - I suppose the decision to go with Allman's bracing could be a sign of Pascal heritage, given that Hejlsberg created Delphi before he designed C#. Same as Pascal case for method names.

Personally I believe in following the adage "in Rome do as Romans do". I use Allman's in C#, but K&R in Java. I am so used to it that switching the convention either way is jarring to me.

I believe that some convention diversity is actually beneficial for a "multilingual" developer as it helps to remember which language they're coding in at the moment and makes it easy to differentiate various habits. It's a mental equivalent of muscle memory, so to speak.

Answer 4

The convention that you associate with Java is the K&R style, or the "One true brace style," and originally comes from C. This page indent-style from the venerable Jargon File shows how old the distinction is.

I've always thought that the Allman style and its variants are a reflection of how the authors think about code, elevating the block delimiters to the level of keywords similar to how some languages use "begin" and "end" around blocks of code.

Answer 5

I assume it all started because the work is paid by number of code lines. (Now it is too late for fix). This is the most reasonable explanation to me.

Code is read by coders. I disagree that extra new lines will improve the code comprehension or make it more readable. Especially the cases with "else", "catch", "finally":

}
else
{

Code is not one line, no one is reading single line. The code is functions and function body is readable when it fits in one screen. Extra new lines are not helping. Opposite - it makes the code more un-readable.

The new line separate paragraphs in the books and the articles. The paragraphs are split by the story. That makes it more readable! (Not a simplified rules without meaning like - new line after 'if' and before 'then').

I like the comment from @Neil_UK:

...indent to control program flow is what humans naturally want to do...

...those braces ... actually reflect the indentation...