Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GCC 6: -Wmisleading-indentation vs. “goto fail;”

developerblog.redhat.com

Post reply on HN
Print view View original

91–100 of 168 posts

Re: GCC 6: -Wmisleading-indentation vs. “goto fail;”

#91

Post by to3m »

ktRolster wrote: post #64
to3m wrote: post #55

Earlier quoted context omitted.

I've never met a C or C++ debugger that handled this case nicely, unfortunately. Totally ridiculous, of course, because they could! They just never seem to. Meeting snippets of code like that when debugging is a constant source of frustration for me, because I have to stop what I was doing, edit the code, rebuild, then get back to where I was. Particularly galling when the code in question is in a commonly-included h…

>I've never met a C or C++ debugger that handled this case nicely, unfortunately. Apparently you never use Visual Studio. It can highlight a portion of the statement on each step (at least it used to)

Last I looked, this only worked for C# (possibly all CLR-based languages...) - but native C/C++ breakpoints were addressed by file and line only.

Re: GCC 6: -Wmisleading-indentation vs. “goto fail;”

#92

Post by alextgordon »

dcvuob wrote: post #80
oftenwrong wrote: post #60

Semi-related: What do people think about if-else-if... chains vs nested simple if-else blocks? I have seen many cases on the job where someone writes a complex if-else-if chain and then an oversight in their logic WRT the dependencies between conditions causes the wrong branch to be taken. I prefer the latter style of the ones I've put below, especially when the conditions are more complex. For me, it makes it easier…

Second example is very readable using Allman style: if( condition_a ) { if( condition_b ) { do_thing_a(); } else { do_thing_b(); } } else { do_something_else(); } Editor space is free, why not use it.

Horizontal space is free, vertical space is not.

The more lines that are visible on your screen, the less you have to keep in your working memory. Human memory is fragile, so you really don't want to rely on it.

I can only fit 51 lines vertically (damn widescreen laptop) so that one snippet fills a good 1/3 of my screen.

Personally I'd write that as

    if (condition_a) {
        if (condition_b) do_thing_a();
        else do_thing_b();
    }
    else {
        do_something_else();
    }

Re: GCC 6: -Wmisleading-indentation vs. “goto fail;”

#94

Post by kbenson »

MichaelBurge wrote: post #77
gravypod wrote: post #57

Earlier quoted context omitted.

Yes, but from what I understand this bug is more commonly introduced in code that is being updated. Notice that I said "avoided", not "fixed". That is because I am rather focused on making code that is maintainable. I posted this original comment to have a dialogue about something I include in my programming practices. I wanted to see how other people viewed this as a development technique.

You didn't say it explicitly, but your original comment came off more like "This option is unnecessary and should be removed from gcc, since we can simply enforce a style of using curly braces everywhere" C doesn't do this, but I like this feature from Perl for single-statement checks: return if is_red($traffic_light); return unless is_green($traffic_light); In C, I usually put the early returns on their own line wit…

I love that feature of Perl, and to be explicitly clear to those that are unfamiliar with it, Perl does not allow unbraced single line if's in the normal sense (pre-conditional ifs), and does not allow braced post-conditional ifs. For example, these are valid:

    if ( $foo ) {
      bar();
      baa();
    }
    quux() if $foo;
And these are not:

    if ( $foo ) bar();
    { bar(); baz(); } if $foo;

Re: GCC 6: -Wmisleading-indentation vs. “goto fail;”

#95

Post by pklausler »

marcosdumay wrote: post #82
noamsml wrote: post #11

Nice. These sorts of warnings are why it's worth investing the extra effort to enable -Werror in your codebase if you can.

No, I've never seen a real use case for -Werror. What's the difference if compilation stops at the warning? You'll (or your team, or whoever) fix it anyway, and if you won't, you have a people problem, that must be solved at the policy (or HR) level. Solving people problems at the tooling level is a certain way to get unintended consequences and alienate the good people that weren't part of the problem. Of course, yo…

-Werror is a cheap unavoidable automatic code review tool that limits the blast radius of what you call "people problems". It slows good programmers down a little but it can stop the dangerously bad ones in their tracks.

Re: GCC 6: -Wmisleading-indentation vs. “goto fail;”

#96

Post by kbenson »

kllrnohj wrote: post #31
gravypod wrote: post #2

This seems like it could have been avoided by people using braces around every block. Omitting braces in this case leads to a lot of problems.

People will make mistakes. Policy does not prevent that. Tools do.

Tools won't prevent it without a policy to enforce. It's still ultimately up to us to determine the rules the tools follow.

Re: GCC 6: -Wmisleading-indentation vs. “goto fail;”

#97

Post by slizard »

cmrdporcupine wrote: post #38
pavlov wrote: post #20

Earlier quoted context omitted.

Single-line ifs are pretty useful with traditional-style C libraries that expect all checks to be done at call site: if (ptr) call_oldschool_thingy(ptr);

Was just discussing this at work. A good compromise would be to allow statements outside of of block-parens only when they are on the same line as the control statement. IMHO there should be a -W to enforce this so those of us with -Werror on can catch it and burn it with fire. Here at Google the style guide requires block-parens always.

In the project I work on our style also requires block-parens. Sometimes it feels unnecessary, but it does make up in terms of consistency: it's easy to glance through the code and inspect the conditions only.

I got used to this quite a bit and these days if I write code outside the project I work on, I d sometimes omit the block-parens, but I always add extra indentation to ensure the condition is visually well-separated, e.g.:

  if (condition1 || condition2)    execute_foo1(with_bar);
  if (condition3)                  exectute_foo2();

Re: GCC 6: -Wmisleading-indentation vs. “goto fail;”

#98

Post by delecti »

ilek wrote: post #86
strommen wrote: post #13

Making braces optional in single-statement if/else/while/for clauses is one of the biggest anti-features in C. It's frustrating that it was ported forward to more modern languages like Java, JavaScript, C#, etc. I'm glad Python (with semantic whitespace) and Go (with gofmt) solve this problem.

I don't find something like the below frustrating really if (a) ... else ... But for some reason I find the below _very_ frustrating. It feels misleading and I find it to be very, very ugly. if (a) ... else { /* Multi line block */ }

I've actually never seen anyone do either of those.

I've seen

if (a) thing;

but never with an else, and certainly never with an else that has a multi-line block. That's definitely somethign I'd call out in a CR.

Re: GCC 6: -Wmisleading-indentation vs. “goto fail;”

#99

Post by GolDDranks »

KMag wrote: post #50
pavlov wrote: post #20

Earlier quoted context omitted.

Single-line ifs are pretty useful with traditional-style C libraries that expect all checks to be done at call site: if (ptr) call_oldschool_thingy(ptr);

Both Rust and Golang have optional parens and mandatory braces, so for the same number of keystrokes one would have something more like: if ptr { call_oldschool_thingy(ptr) } (Keystroke count isn't an important metric for me, but apparently very important to some people.)

I love this style. Braceless style always breaks when refactoring or adding/removing debug logging – so it makes sense to make the braces mandatory. And then, because you have a delimiting if and the starting brace, you don't need to have the parenthesis. Great!

Now if only Rust supported the elision of ; ... (Yeah, I know that they have a reason to not do that, but I don't buy it.)

Re: GCC 6: -Wmisleading-indentation vs. “goto fail;”

#100

Post by stephenr »

lmm wrote: post #37
gravypod wrote: post #2

This seems like it could have been avoided by people using braces around every block. Omitting braces in this case leads to a lot of problems.

Extra braces add visual clutter and reduce readability, especially when they mean a function no longer fits on one screen. So if there's a way to eliminate that kind of bug without having to add more braces then I'm all in favour of it. (Personally my preference would be a linter that automatically runs on checkin, and refuses commits that do not conform to the style guide)

> when they mean a function no longer fits on one screen

What screen size? What resolution? What ide/editor window size? What font face & size? With or without soft line wrapping?

Honestly arguments about how "pretty" code is are fucking ridiculous. Despite what someone said, the purpose of source code is not to be "read" with "running" as a secondary task. That literally only applies to code written purely for educational purposes.

The purpose of code is to achieve the goals of the software as efficiently as possible. Efficiency is not just about speed - a fast but unreliable program is not efficient.

Post reply on HN