32 replies to this topic

[wack]

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.

[King Mir]

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.

[swiftcoder]

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

[Bregma]

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]

[swiftcoder]

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.

[wintertime]

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?

[frob]

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

[swiftcoder]

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.

[SiCrane]

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

[BinaryPhysics]

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.

[Yrjö P.]

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."

[King Mir]

Putting the first curly on the same line helps that:

 

foo();

if(condition){
    bar();
}

xyzzy();

[warnexus]

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