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

111–120 of 168 posts

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

#111

Post by abjorn »

GTP wrote: post #107
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 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.

I would disagree that optional braces are a "great power." I feel like it's a really nothing feature.

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

#112

Post by Merad »

AdmiralAsshat wrote: post #6
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.

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.

Personally I'm a fan of braces everywhere (though I prefer Allman style), but the one area where I've given up is precondition checks at the start of a function.

Any style with braces looks like a cluttered mess compared to

    if (foo)
      throw ...
    if (bar)
      throw ...
    if (baz)
      throw ...
But I strictly limit that to the beginning of a function, and only `if (x) [throw|return] y;`

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

#113

Post by ConceptJunkie »

monk_e_boy wrote: post #56
return0 wrote: post #40

Earlier quoted context omitted.

Agreed, but with braces, i can press % over a '{' in vi and find the matching }

There is an argument that if you can't scan the code with your eye and spot the } then your code needs refactoring to make it easier to read.

That's easy to say until you're dealing with 2 million lines of code like that.

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

#114

Post by ConceptJunkie »

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.

I've done this for as many years as I can remember. Unfortunately, almost no one else I work with does.

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

#115

Post by MereInterest »

aikah wrote: post #67
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.

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

I thought that the go compiler would throw an error of your code is not in the format produced by gofmt. You don't need to use the tool, but you need to have your code in the same format that the tool would produce.

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

#116

Post by lmm »

stephenr wrote: post #100
lmm wrote: post #37

Earlier quoted context omitted.

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 educa…

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

Does it matter? There will be a point at which an extra line makes the difference. And particularly with modern screen shapes, vertical space is at much more of a premium than horizontal space.

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

The ability to understand software is vital to real-world usefulness though. Requirements change all the time, and so the ability to make changes to software is vital - and to effect desired changes to code you must first understand it.

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

#117

Post by ConceptJunkie »

stephenr wrote: post #100
lmm wrote: post #37

Earlier quoted context omitted.

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 educa…

If the code can't be read, then it really doesn't matter how it runs because no one will understand it well. Trust me. Some of the code I work with has this problem. I fix it when I can, but there's just too much to fix it all.

The only code where readability isn't as important as functionality is finished code, and we all know that code is never finished.

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

#118

Post by neilc »

MereInterest wrote: post #115
aikah wrote: post #67

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. gofmt is still optional. Python significant white spaces are not.

I thought that the go compiler would throw an error of your code is not in the format produced by gofmt. You don't need to use the tool, but you need to have your code in the same format that the tool would produce.

> I thought that the go compiler would throw an error of your code is not in the format produced by gofmt.

This is not the case.

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

#119

Post by to3m »

ajross wrote: post #71
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.

> one of the biggest anti-features in C Please. I'm as big a C apologist as you'll find and even I can think of six or nine thing objectively worse about the language. This issue is merely a great bike shed because it allows all of us rabble to join in on a discussion about "compiler" technology. Look: it's a good warning. People should clearly use it. It probably should have been written long ago, and probably would…

And now we've got the warning, we can go back to leaving the braces out more often ;)

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

#120

Post by Coding_Cat »

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.

Rust does something similar. It doesn't allow for brace-less clauses and it also bitches and moans at you about 'miss-using' camelCase, snake_case, etc. Which is great because it means that by default all project will follow a similar mark-up.
Post reply on HN