Live data from Hacker News

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

developerblog.redhat.com

101–110 of 168 posts

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

#101

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.

Haskell's solution to this problem is also excellent and needs to be better known and copied into newer languages. The language has curly braces around the bodies of 'let', 'case', 'where', and 'do' constructs, and also the bodies of modules, and semicolons between the constituents of those constructs -- but when the compiler demands a '{' and doesn't see one, it uses indentation to insert them in the obvious places. If your indentation is incorrect, you're likely to get an implicit ';' or '}' put in the wrong place, and you go fix it.

The scheme works so well that people will often go months into their Haskell education before they encounter code with explicit braces and semicolons.

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

#102
post #86

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 */ }

Why is that an issue? You would use something like that extensively in Go or JS for example, where you need to perform a check on the returned (Go) or passed (JS callback) error value.

The else is executed if there is no error, in my style at least, so naturally it will contain more logic.

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

#104
post #80

Earlier quoted context omitted.

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();…

The more lines that are visible on your screen, the less you have to keep in your working memory.

Sure if you only saw a few lines at a time, then this might be a problem. But you can see 51 on a laptop. This is enough for almost all cases. And you can scroll if you need to look up something. If you stumble upon a case of multiple if statement that span several screens then no style is going to help you see it in full. In that rare case you might see a little more, at the expense of all code ever becoming less readable (if we assume Allman is more readable for the sake of this argument of course).

If for some reason your code has more than, let's say >50% cases where something spans multiple screens and needs to be seen as a whole (code which should be refactored, but let's ignore that), then you might have an argument to use your style, in all other cases you're doing premature optimization of your coding style, so to speak.

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

#105

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.

Haskell's solution to this problem is also excellent and needs to be better known and copied into newer languages. The language has curly braces around the bodies of 'let', 'case', 'where', and 'do' constructs, and also the bodies of modules, and semicolons between the constituents of those constructs -- but when the compiler demands a '{' and doesn't see one, it uses indentation to insert them in the obvious places.…

I've actually never seen production code with braces or semicolons. The only place it's semi-common is when people write complicated expressions and need to put them on one line for the REPL (GHCi).

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

#106
post #102
post #86

Earlier quoted context omitted.

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 */ }

Why is that an issue? You would use something like that extensively in Go or JS for example, where you need to perform a check on the returned (Go) or passed (JS callback) error value. The else is executed if there is no error, in my style at least, so naturally it will contain more logic.

I just have a problem with the mixing of braces on an if/else chain I guess. I don't know how to explain it clearly, it just rubs me the wrong way?

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

#107

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 like Python forcing you to use a particular identation. And in my opinion optional braces are not an anti-feature, "with great powers come great responsibilities": like any other tool it's up to who is using it to use it in the right way.

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

#108

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.

Actually for C there has always been GNU indent, which serves a similar function as gofmt.

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

#109
post #98
post #86

Earlier quoted context omitted.

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.

I call it out in CRs when I see it and I've been fixing any of these I come across in code at work.

I'd rather a compiler forces me to put braces around everything than let people have the opportunity to do something like the latter from my original comment.

Post reply on HN