Comments on: To Brace or not to Brace in C# ifs and other Constructs

By: Why I Love the Semicolon! | PeterKellner.net

Why I Love the Semicolon! | PeterKellner.net — Sat, 24 Oct 2009 15:23:59 +0000

[...] so we all want to be somewhat popular, and it seems that my last article, “To Brace Or Not to Brace”, seems to have gotten a lot of attention, so, here goes my opinion on the popular semi-colon [...]

By: mongo lloyd

mongo lloyd — Fri, 23 Oct 2009 09:17:55 +0000

I agree with always using braces*, mostly because if I don’t, whenever I realise I have to do more than just one statement after an if (or within a for/while, etc), I have to actually reformat the code. Inserting brackets is a bit annoying to have to do. It’s not just a one-keystroke move (unless you have a really intelligent editor).

Should the code actually have to be reformatted for such a simple and common code change? I think not.

*: Except for in case blocks, where I think it is really daft and pointless. One of my pet peeves actually.

By: andyclap

andyclap — Thu, 22 Oct 2009 10:31:40 +0000

Most of the problems solved by consistently bracing single lines are also solved with a code beautifier.

The additional benefits of beautification (consistency, SCM diff) are enough to warrant including beautification as part of the dev process.

Now … does anybody know a beautifier as good as R# that can be invoked through nAnt?

By: Ian

Ian — Wed, 21 Oct 2009 14:19:17 +0000

I use resharper to force {} everywhere possible. I have been bitten too many times by people that write multi-line statements, but forget to add the braces. It can be quite difficult to track down these kinds of bug. I also use CodeKana which gives me a mental image of my code structure without needing to read the code (works very nicely with the {} in the code).

By: Juozas

Juozas — Wed, 21 Oct 2009 13:58:54 +0000

My rule of thumb is: always use braces, except when all you do is return, e.g:

if (param == null)
return false;

This rule has exceptions – if condition is complex, I use braces even for simple return statement. And I NEVER write statements in condition line.

By: Peter

Peter — Wed, 21 Oct 2009 13:19:15 +0000

@Giraffe and @David: I would write it the short way, but was just making a point about it does get uglier and is that worth it.

By: Giraffe

Giraffe — Wed, 21 Oct 2009 09:17:36 +0000

@David,

I think rather that you should be comparing

if (myObject1==null) err = “bad1″;
if (myObject2==null) err = “bad2″;

with

if (myObject1==null) { err = “bad1″; }
if (myObject2==null) { err = “bad2″; }

By: Garry Pilkington

Garry Pilkington — Wed, 21 Oct 2009 08:31:48 +0000

I agree with you, it makes the code much easier to read and understand. However as soon as I put any else statements in there I judge whether it would look neater using a conditional operator. I always believe that code should be firstly understood by a human, the compiler doesn’t really care either way.

By: David Kemp

David Kemp — Wed, 21 Oct 2009 08:26:29 +0000

so you’re saying

if (myObject1==null)
{
err = “bad1″;
}
if (myObject2==null)
{
err = “bad2″;
}

is more readable than

if (myObject1==null) err = “bad1″;
if (myObject2==null) err = “bad2″;

Have you lost your mind?

You’ll be telling me I can only have one “return” statement per function next!

By: Reflective Perspective - Chris Alcock » The Morning Brew #459

Reflective Perspective - Chris Alcock » The Morning Brew #459 — Wed, 21 Oct 2009 07:26:09 +0000

[...] To Brace or not to Brace in C# ifs and other Constructs – Peter Kellner asks one of the great coding style questions of all time, ‘do I have to use braces with that?’ [...]

By: Bart Czernicki

Bart Czernicki — Tue, 20 Oct 2009 23:29:51 +0000

could be cleaner with the ternary operator:

myObject1 == null ? err = “bad1″ : err = “something else”;

Many people code in multiple languages and even in SQL writing code like this can get you in trouble:

if (@someVariable is NULL)
err = “bad”1
err2 = “bad also”

err2 would not be under the condition and should have the begin/end (curly bracket equivelant in c#). So sticking to general good practices is a good idea.