In my last post, I found a use for inverting if statements. That is, I postulated that it is better to have an explicit else when it’s impossible for that code to be executed. The argument for just falling through the loop with no else is that why have unnecessary code.
My argument is intent. I personally like to make the intent of my code as clear as possible and having the extra else provides that for me.
Now, for the braces discussion. That is, is it OK to do this:
if (myObject1==null) err = "bad1"; if (myObject2==null) err = "bad2"; if (myObject3==null) err = "bad3"; if (myObject4==null) err = "bad4"; if (myObject5==null) err = "bad5";
or should you be required by coding standards to do this:
if (myObject1==null) { err = "bad1"; } if (myObject2==null) { err = "bad2"; } //...
I always follow the second, even though the code is clumsier. I’m a creature of small errors and have found that it can lead to insidious errors when I don’t That is, I may say the following and expect both to be executed and will be sadly surprised.
if ( myObject==null) err1 = "bad1"; errorno=3;
Of course, in the above example, errno will always be 3 whether or not myObject is null or not.
I’m supported in my thinking by Juval Lowy of IDesign in his coding standard 2.32. I’m not in 100% agreement with these coding specs (specifically around the use of m_, but overall, I like them very much.
I’m also supported by one of my favorite .net guys, Brad Abrams in his writings.
HTH’s!
October 20th, 2009 at 4:29 pm
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.
October 21st, 2009 at 12:26 am
[...] 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?’ [...]
October 21st, 2009 at 1:26 am
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!
October 21st, 2009 at 1:31 am
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.
October 21st, 2009 at 2:17 am
@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″; }
October 21st, 2009 at 6:19 am
@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.
October 21st, 2009 at 6:58 am
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.
October 21st, 2009 at 7:19 am
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).
October 22nd, 2009 at 3:31 am
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?
October 23rd, 2009 at 2:17 am
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.
October 24th, 2009 at 8:23 am
[...] 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 [...]