• Create Account

## if statement in for loop, brackets needed?

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

32 replies to this topic

### #21wack  Members

Posted 12 February 2013 - 02:27 PM

I have programmed in C-like languages for aboud 20 years now, 13 of them professionally. I have never ever seen a problem with the use of braces. So I don't think it's that important.It could also depend on what editor you use. Emacs understands the level of indentation you are at, so when you go to add a second line to the then' clause, the cursor will go to a place where it's obvious that you need braces.I agree with everyone that the most clear style should be used. So use whatever you think is more clear.

I agree with this, after (is it 15 now?) years of coding i have never seen anyone accidentally add code to a statement without braces and failing to add them. Part of it might be because I have mostly worked with coding styles that dictate braces on new lines, and ide/editor support, as you say.

### #22King Mir  Members

Posted 12 February 2013 - 03:16 PM

Empty loops get a pair of braces on the same line.

That's an interesting idea. I use empty braces on the same line for an empty function or class definition. My empty loops look like this:
while(*(src++) = *(dst++))

;

I guess I just feel like loop bodies should start on the next line, no matter what. I'm also strongly against semi-colon on the same line to prevent things like this:
for(;;);
{
//Why am I not executed as expected?
}

It's nice to have the same convention for all blocks, including both functions and loops. And {} is much more noticeable than ;, in part because one doens't normally put {} after a statement otherwise, and in part because it actually means something different for functions, so we're trained to notice it.

### #23swiftcoder  Senior Moderators

Posted 13 February 2013 - 11:48 AM

As I said, emacs makes it very obvious if you are writing at the wrong level of indentation.

To my mind this is 90% of it. If you aren't using an editor that is highly aware of syntax (vim, emacs, sublime, etc), then informal code conventions are going to trip you up.

I really don't know why so many programmers adamantly continue to use inferior tools. For example:

$g++ -Wall test.cpp versus: $ clang++ test.cpp

test.cpp:5:12: warning: if statement has empty body [-Wempty-body]

if (1 < 2);

^

test.cpp:5:12: note: put the semicolon on a separate line to silence this warning

Tristam MacDonald - Software Engineer @ Amazon - [swiftcoding] [GitHub]

### #24Bregma  Members

Posted 13 February 2013 - 12:16 PM

o my mind this is 90% of it. If you aren't using an editor that is highly aware of syntax (vim, emacs, sublime, etc), then informal code conventions are going to trip you up.

But a syntax-aware editor is not going to catch the valid use of valid syntax.

if (someCondition())
LOG_DEBUG("after if-statement\n");
doSomethingBuggy();


Perfectly valid syntax.  Problem is, as is often reported on this forum, the bug goes away in debug mode.

Relying on a single tool that works well for writing new code is not a win when you're involved in the 80% of software development called 'maintenance'.  Code is meant to be read, after all, not written, and that includes when looking at diffs during code reviews and online in VCS webviews, where building in a context-sensitive C++ front-end is just not going to cut it.

The missing braces after a code change is a common and vexing bug.  I've seen it come up here at gd.net on several occasions.  It's 100% avoidable by always using braces.

Oh, and condemning tools as inferior because you do not know how to use them says less about the tools.

$cat empty.cpp int main() { if (1 < 2); }$ g++ -Wall -Wextra -o empty empty.cpp
empty.cpp: In function ‘int main()’:
empty.cpp:3:13: warning: suggest braces around empty body in an ‘if’ statement [-Wempty-body]


Stephen M. Webb
Professional Free Software Developer

### #25swiftcoder  Senior Moderators

Posted 13 February 2013 - 12:38 PM

But a syntax-aware editor is not going to catch the valid use of valid syntax.

All of my primary editors fix the incorrect indentation there - it doesn't make the bug go away, but it makes it damn easy to spot during code reviews.

Code is meant to be read, after all, not written, and that includes when looking at diffs during code reviews and online in VCS webviews, where building in a context-sensitive C++ front-end is just not going to cut it.

Then auto-format all your code using a pre-checkin hook on your version control.

You should probably be doing this anyway, to deal with funky whitespace issues.

Oh, and condemning tools as inferior because you do not know how to use them says less about the tools.

The point isn't that I don't know how to use gcc (I do), the problem is that it's off by default, and many users don't know how to turn it on. The whole idea that -Wall does not, in fact, turn on *all* warnings, is a bit of a non sequitur.

Tristam MacDonald - Software Engineer @ Amazon - [swiftcoding] [GitHub]

### #26wintertime  Members

Posted 14 February 2013 - 06:04 AM

You expect people who dont know how to add a compiler option to get the source of clang and flawlessly compile this and be able to integrate this with libstdc++ from gcc?

### #27frob  Moderators

Posted 14 February 2013 - 06:25 AM

Let's please move away from the personal attacks, and back to the topic of the merits and drawbacks of coding standards. Thanks.

Check out my book, Game Development with Unity, aimed at beginners who want to build fun games fast.

Also check out my personal website at bryanwagstaff.com, where I occasionally write about assorted stuff.

### #28swiftcoder  Senior Moderators

Posted 14 February 2013 - 07:35 AM

You expect people who dont know how to add a compiler option to get the source of clang and flawlessly compile this and be able to integrate this with libstdc++ from gcc?

I expect vendors to ship the best tool for the job. Clang is already the default compiler on OS X, FreeBSD and MINIX - and I hear of testing against the Debian archives, so Ubuntu may be next.

You can't really divorce the discussion of coding standards from the discussion of tools. To my mind there are two types of coding standards:

• Standards that are purely stylistic (i.e. spaces vs tabs)
• Standards that work around deficiencies in languages/tools (i.e. brace conventions)

The former you can't really have a meaningful debate on, and the latter are only a concern so long as the tools don't account for it.

Tristam MacDonald - Software Engineer @ Amazon - [swiftcoding] [GitHub]

### #29SiCrane  Moderators

Posted 14 February 2013 - 08:16 AM

Aside from the provider of the OS, there are other sources for clang binaries. Ex: on Windows you can use cygwin to get clang.

### #30BinaryPhysics  Members

Posted 15 February 2013 - 07:10 AM

When I started programming in C I gained this obsession for using as few characters as possible. To me if you don't need the braces don't use them. However, not everyone has this philosophy and while I now make a special effort to look at whether braces exist or not before I make a modification I recognise the terrible slip ups that have already been mentioned.

For the sake of working when tired or as part of a team it probably is better to included them. More importantly teams should probably have a standards document they all follow such that if they see a single line statement they hopefully remember to change it appropriately.

### #31Yrjö P.  Members

Posted 15 February 2013 - 08:40 AM

I tell my students to always use braces, because this is the kind of thing that trips them up.

On the other hand, at least in my eyes, the situation where braces and indentation do not match is too obvious to be dangerous. In code that is otherwise properly indented, I can't miss it. Never saw a coworker make that mistake either. I find omitting the braces from one-liners makes the code easier to read and understand. Compare this:
foo();

if(condition)
{
bar();
}

xyzzy();
with this:
foo();

if(condition)
bar();

xyzzy();
With braces, the visual distance of every line with text is almost the same. It's harder to see that the two lines in the middle are logically related to each other. The version without braces has the same visual rhythm as if you were reading the logic aloud: "foo, (pause), if condition then bar, (pause), xyzzy."

### #32King Mir  Members

Posted 15 February 2013 - 12:31 PM

Putting the first curly on the same line helps that:

foo();

if(condition){
bar();
}

xyzzy();`

### #33warnexus  Prime Members

Posted 15 February 2013 - 01:00 PM

use braces even if it is one statement. you wont think other person reading your code to think less about these little subtle things. it makes it more readable in my opinion

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.