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

61–70 of 168 posts

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

#61

Post by _0ffh »

hacker_9 wrote: post #27
_0ffh wrote: post #24

Earlier quoted context omitted.

In cases where I have only one statement I often drop the braces, but I also drop the newline. if (true) foo(); else bar(); Not much room for a confused baz() here, or so I hope.

This is actually a worse solution. When speed reading code having control statements on their own lines is far more beneficial as you can at a glance, using the indentation, easily see what the flow of execution is.

You might find it worse, I don't. You might not be able to parse this quickly, I am.

No holy wars about style please! I was just offering an alternative that works well for me.

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

#63

Post by bpicolo »

return0 wrote: post #43
bryanlarsen wrote: post #34

Earlier quoted context omitted.

Braces don't prevent you from using single-line if: if (ptr) { call_oldschool_thingy(ptr); }

many people use specific styles for where to place { and } (e.g in a line by itself) so this might look 'ugly'

Meshes perfectly fine with one true brace style

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

#64

Post by ktRolster »

to3m wrote: post #55
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);

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)

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

#65

Post by jjuhl »

iainmerrick wrote: post #12
gravypod wrote: post #7

Earlier quoted context omitted.

Wouldn't it make sense to update that as you change the code? If you edit an if statement, you should add the braces in. It would make sure that no new errors are introduced due to this.

That's a good policy for code reviews, but again it's hard to do it correctly in a tool. The compiler would need to require braces in new code, but allow brace-free style in old code; you'd need to integrate it with the source control system so it knows what code is new. Doable, but tricky.

Ever heard of clang-format?

http://clang.llvm.org/docs/ClangFormat.html

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

#66

Post by asadjb »

nathanielc wrote: post #42
deweerdt wrote: post #36

Earlier quoted context omitted.

I think that gofmt is particularly innovative, in the sense that it acknowledges that formatting is integral part of the language. In the sense that a programming language is not only made to be parsed by a computer, but also read back by a human.

Yes, and that the nuances of how things are formatted are really not that important, but rather having a standard which provides a consistent reading experience is the important aspect.

I agree completely with this. After fighting over code formatting for so long (often starting those fights myself), I have thankfully come to realize that what format you use almost never matters, only that you use some standardized format.

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

#67

Post by aikah »

deweerdt wrote: post #36
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 think that gofmt is particularly innovative, in the sense that it acknowledges that formatting is integral part of the language. In the sense that a programming language is not only made to be parsed by a computer, but also read back by a human.

> I think that gofmt is particularly innovative, in the sense that it acknowledges that formatting is integral part of the language.

gofmt is still optional. Python significant white spaces are not.

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

#68

Post by _0ffh »

asendra wrote: post #29
AdmiralAsshat wrote: post #6

Earlier quoted context omitted.

I'm in favor of braces around everything, but to be honest even I will occasionally use the indent if I only expect one action. e.g. if (true) foo(); else bar(); This looks prettier to my eyes than if(true){ foo(); } else { bar(); } However, I might not be the last person to touch the code. My coworker might come later and add: if (true) foo(); else bar(); baz(); And hence the indent problem.

How about this one (true) ? foo() : bar();

They will send the Inquisition after you for that one! :)

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

#69

Post by ktRolster »

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'm glad Python (with semantic whitespace)... solve this problem.
Python solved it....then added the problem of making things you can't even see semantically significant. If you write Python, it's helpful to have an editor that makes the difference between tabs and spaces visible....

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

#70

Post by jahewson »

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…

I don't think there's a general statement to be made about this. I have no problem reading both examples and actually prefer the first. But it depends on the what the specific logic is - some conditions are easy to understand, despite their size, others are small but subtly complex. I certainly wouldn't want to mandate writing code like your second example without considering the use case first - YMMV.
Post reply on HN