Jump to content

  • Log In with Google      Sign In   
  • 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.

  • You cannot reply to this topic
32 replies to this topic

#21 wack   Members   -  Reputation: 1263

Like
0Likes
Like

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.

Sponsor:

#22 King Mir   Members   -  Reputation: 1931

Like
1Likes
Like

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.



#23 swiftcoder   Senior Moderators   -  Reputation: 9759

Like
0Likes
Like

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]


#24 Bregma   Crossbones+   -  Reputation: 4848

Like
3Likes
Like

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

#25 swiftcoder   Senior Moderators   -  Reputation: 9759

Like
1Likes
Like

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]


#26 wintertime   Members   -  Reputation: 1640

Like
0Likes
Like

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?



#27 frob   Moderators   -  Reputation: 19757

Like
0Likes
Like

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 personal indie blog at bryanwagstaff.com.

#28 swiftcoder   Senior Moderators   -  Reputation: 9759

Like
0Likes
Like

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]


#29 SiCrane   Moderators   -  Reputation: 9495

Like
0Likes
Like

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.

#30 BinaryPhysics   Members   -  Reputation: 294

Like
0Likes
Like

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.



#31 Yrjö P.   Crossbones+   -  Reputation: 1412

Like
0Likes
Like

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

#32 King Mir   Members   -  Reputation: 1931

Like
0Likes
Like

Posted 15 February 2013 - 12:31 PM

Putting the first curly on the same line helps that:

 

foo();

if(condition){
    bar();
}

xyzzy();


#33 warnexus   Prime Members   -  Reputation: 1396

Like
0Likes
Like

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.



PARTNERS