Mouton Posted October 10, 2004 Share Posted October 10, 2004 We had a discussion at work the other day about using brackets for single line statements. 1. if (something == somethingElse) { doSomething(); } 2. if (something == somethingElse) { doSomething(); } 3. if (something == somethingElse) doSomething(); Explain your choice if you have a reason... Link to comment Share on other sites More sharing options...
0 Rob2687 Posted October 10, 2004 Share Posted October 10, 2004 number 1, cause its easier to read the code...at least for me. Link to comment Share on other sites More sharing options...
0 Ianmac45 Posted October 10, 2004 Share Posted October 10, 2004 if i only had one command after the if statement, i'd use ex. 3. otherwise, i'd use ex. 1 Link to comment Share on other sites More sharing options...
0 vcv Posted October 10, 2004 Share Posted October 10, 2004 I use #2, single line or not. Easier to line up conditions/blocks. Link to comment Share on other sites More sharing options...
0 ramesees Posted October 10, 2004 Share Posted October 10, 2004 Yeah I use #2, its just a lot easier for me to type it and makes more sense when lining up { } in for loops or nested if/elses I never could get used to #1 style of bracketting, I didn't like it either Link to comment Share on other sites More sharing options...
0 caustiK Posted October 10, 2004 Share Posted October 10, 2004 i use style #2. i'm with you guys, it's easier to line up the braces, i hate putting the first one on the same line as the function/control statement. i used to use example #3, but after awhile i realized that i would often end up adding more lines to the if statement and have to put them in anyways. Link to comment Share on other sites More sharing options...
0 azcodemonkey Posted October 10, 2004 Share Posted October 10, 2004 #2 for me if I have multiple lines in the conditional, otherwise, no braces. Link to comment Share on other sites More sharing options...
0 Sn1p3t Posted October 11, 2004 Share Posted October 11, 2004 I use #2 in almost all cases. I've used #3 for single line, but it ends up getting more confusing. I code like this: public void DoSomething() { int test; float otherTest; if(condition) { statement; } if(othercondition) { statement; } } I try to group statements together, but have a line between each group. Link to comment Share on other sites More sharing options...
0 kjordan2001 Posted October 11, 2004 Share Posted October 11, 2004 For a single line, I'll switch between 1 & 3, mostly 3 though, and for multiple lines, 1. Link to comment Share on other sites More sharing options...
0 +virtorio MVC Posted October 11, 2004 MVC Share Posted October 11, 2004 I always style my code like in example two. Link to comment Share on other sites More sharing options...
0 mrvc Posted October 11, 2004 Share Posted October 11, 2004 if one statement example 3 else { example 2 } Link to comment Share on other sites More sharing options...
0 _kane81 Posted October 11, 2004 Share Posted October 11, 2004 I use "1" because that is what my work has told me is standard there. I Like "2" and use to use it because it make the code so much easier to read. "3" I use only when there is one line to execute about the "if, else, for" statement Link to comment Share on other sites More sharing options...
0 DrZoidberg Posted October 11, 2004 Share Posted October 11, 2004 Neither! if (condition) statement; if (condition) { statement1; statement2; statement3; } I find one line "if" statements to be perfectly readable. Maybe it's just me :). Link to comment Share on other sites More sharing options...
0 drekon_v1 Posted October 11, 2004 Share Posted October 11, 2004 #3 for a single line...will use #2 for else, and I don't use #1 at all Link to comment Share on other sites More sharing options...
0 GatorV Posted October 11, 2004 Share Posted October 11, 2004 Example 2!!, it makes the code more clean and easier to explain :cool: Link to comment Share on other sites More sharing options...
0 _kane81 Posted October 11, 2004 Share Posted October 11, 2004 Neither! if (condition) statement; I like it !!!!!! Actually I use it in delphi programming, an sometimes in java Link to comment Share on other sites More sharing options...
0 ilmcuts Posted October 12, 2004 Share Posted October 12, 2004 #2 always - though the choice between #1 and #2 boils down to a question of taste only. Explain your choice if you have a reason... #3 and the other posted variant (#4 from here on): if (condition) statement; are way more error-prone. They easily break, for example, if one day you convert a function to a macro. If a call to that function happens to be your one "statement;" and your macro change makes it two function calls - fun, fun. That example might seem a little contrived, but it's not really. You don't even need to be tired to introduce such bugs. Even if the example were contrived, you could still add a second statement and forget to add the braces. That does happen, especially when you're tired or already thinking of the next few lines. There are probably lots of other ways this can break that elude me right now. Feel free to reply with more. Also consider that #2 in particular makes a program better readable (actually that could be considered a question of taste again). It nicely separates the block that is only executed conditionally from the "regular" program flow. #1 and #2 aren't exactly a waste of screen estate either - we aren't in the age of 80x25 displays any more. But the main argument is still that #1 and #2 are less error-prone. If you think about it for a moment, there are situations where #3 and #4 turn working programs into faulty programs. They can turn the slight changes into many hours of debugging. Programs using #1 and #2 will still work. #3 and #4 might break, but #1 and #2 won't. Of course there are examples where #1 and #2 break - but if they aren't contrived they will usually break #3 and #4 as well. Still, #1 and #2 follow the "defensive programming" principle. You code in a way that tries to avoid as many inadvertent bugs as possible. You can never avoid all bugs, but that pair of braces avoids some of them. Then again, all my points are rendered invalid if you are, say, competing in an obfuscation contest or something equally fancy. PS. Slightly OT, but a remark about my macro example above: As a rule of thumb you should prefer small (possibly template) function to macros. The above scenario isn't the only reason, but it should be reason enough already. And yes, there are (very, very few) situations where macros are better. Link to comment Share on other sites More sharing options...
0 John Veteran Posted October 12, 2004 Veteran Share Posted October 12, 2004 Always like #2 :yes: Link to comment Share on other sites More sharing options...
0 DrZoidberg Posted October 12, 2004 Share Posted October 12, 2004 #2 always - though the choice between #1 and #2 boils down to a question of taste only.#3 and the other posted variant (#4 from here on): if (condition) statement; are way more error-prone. They easily break, for example, if one day you convert a function to a macro. If a call to that function happens to be your one "statement;" and your macro change makes it two function calls - fun, fun. That example might seem a little contrived, but it's not really. You don't even need to be tired to introduce such bugs. Even if the example were contrived, you could still add a second statement and forget to add the braces. That does happen, especially when you're tired or already thinking of the next few lines. There are probably lots of other ways this can break that elude me right now. Feel free to reply with more. Also consider that #2 in particular makes a program better readable (actually that could be considered a question of taste again). It nicely separates the block that is only executed conditionally from the "regular" program flow. #1 and #2 aren't exactly a waste of screen estate either - we aren't in the age of 80x25 displays any more. But the main argument is still that #1 and #2 are less error-prone. If you think about it for a moment, there are situations where #3 and #4 turn working programs into faulty programs. They can turn the slight changes into many hours of debugging. Programs using #1 and #2 will still work. #3 and #4 might break, but #1 and #2 won't. Of course there are examples where #1 and #2 break - but if they aren't contrived they will usually break #3 and #4 as well. Still, #1 and #2 follow the "defensive programming" principle. You code in a way that tries to avoid as many inadvertent bugs as possible. You can never avoid all bugs, but that pair of braces avoids some of them. Then again, all my points are rendered invalid if you are, say, competing in an obfuscation contest or something equally fancy. PS. Slightly OT, but a remark about my macro example above: As a rule of thumb you should prefer small (possibly template) function to macros. The above scenario isn't the only reason, but it should be reason enough already. And yes, there are (very, very few) situations where macros are better. 584720577[/snapback] Interesting points. I have no formal training in programming at all so all this talk about "defensive programming" goes way over my head. I'm entirely self-taught - be it VB, .NET, C# or whatever (my degree is in Law - I should really have studied computer science). I've never been on a programming training course either, so my code is probably full of bad habits. Makes sense to me, though... :) Edit: don't have problems with #4 and macros as I usually program in C#. Presumably you mean macros as in #define statements - C# doesn't support them, IIRC. Link to comment Share on other sites More sharing options...
0 oik Posted October 12, 2004 Share Posted October 12, 2004 i do it like #2's style... if you ever need to go back and add something, it's easier to do (code maintenance). Link to comment Share on other sites More sharing options...
0 azcodemonkey Posted October 12, 2004 Share Posted October 12, 2004 PS. Slightly OT, but a remark about my macro example above: As a rule of thumb you should prefer small (possibly template) function to macros. The above scenario isn't the only reason, but it should be reason enough already. And yes, there are (very, very few) situations where macros are better. 584720577[/snapback] If defensive programming is a concern, you should forgo macros altogether and use inline functions. At least then, you give the compiler the option of testing type safety, and whether or not to expand inline. Link to comment Share on other sites More sharing options...
0 ilmcuts Posted October 13, 2004 Share Posted October 13, 2004 If defensive programming is a concern, you should forgo macros altogether and use inline functions. At least then, you give the compiler the option of testing type safety, and whether or not to expand inline. 584721770[/snapback] Precisely what I was trying to express. There are borderline cases however, read this article written by Andrei Alexandrescu. Macros have other uses as well - to automatically append file name and line number to ASSERT messages for example. There are other string concatenation uses. Granted, they are often a convenience rather than a necessity. So in short, use them if you absolutely must use text replacement. But in other cases, avoid them as much as you can. Good books about all this are Scott Meyers' "Effective C++" and "More Effective C++". They go way beyond style or even simple const-correctnes questions. I'm sure there are other equally nice books, but those are the ones I know. This is getting quite OT for this thread though. Link to comment Share on other sites More sharing options...
0 MrRogers Posted October 14, 2004 Share Posted October 14, 2004 I used to always do #2, but now in most cases I'll do #3 unless I've got some complex algorithm that I need explicit code. I went to #3 because #2 really bloated the code with simple stuff like assessors and whatnot. Link to comment Share on other sites More sharing options...
Question
Mouton
We had a discussion at work the other day about using brackets for single line statements.
1.
if (something == somethingElse) { doSomething(); }2.
if (something == somethingElse) { doSomething(); }3.
Explain your choice if you have a reason...
Link to comment
Share on other sites
22 answers to this question
Recommended Posts