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

141–150 of 168 posts

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

#141

Post by stephenr »

ConceptJunkie wrote: post #117
stephenr wrote: post #100

Earlier quoted context omitted.

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

I didn't say readability doesn't matter.

I'm talking about people who skip braces on single statements, skip semicolons in JavaScript, etc because it "looks prettier" without them

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

#142

Post by stephenr »

lmm wrote: post #116
stephenr wrote: post #100

Earlier quoted context omitted.

> 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, th…

As I said in the other thread I'm not talking about readability.

The exact term used was pretty.

> There will be a point at which an extra line makes the difference

So why not remove all blank lines too. They're less important for reducing issues that single line/braceless flow control blocks can cause.

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

#143

Post by ajross »

strommen wrote: post #131
ajross wrote: post #71

Earlier quoted context omitted.

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

Good point, there's plenty of bad stuff about C. But optional braces are perhaps the most pointless anti-feature in C. The only benefit is a minor (and subjective) improvement in aesthetics.

Your point being that... aesthetics in a technology (a "programming language") whose whole existence derives from making computer programs easier to write, read and reason about is... unimportant?

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

#144

Post by heinrich5991 »

ktRolster wrote: post #69
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....

This is only a problem in Python 2.

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

#145

Post by dcvuob »

TorKlingberg wrote: post #133
dcvuob wrote: post #124

Earlier quoted context omitted.

Yes. And cast that 0 to (void), so the compiler won't complain over an unused expression. Any C programmer will recognize what (void)0 means, do nothing.

Sure, but I find it strange to use the ternary operator and discarding the value. It's not wrong, but I think most C programmers prefer a simple if statement.

I was giving an replacement for the if statement presented above, where both expressions are on the same line.

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

#146

Post by Macha »

Nemo157 wrote: post #140
lmm wrote: post #116

Earlier quoted context omitted.

> 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, th…

> And particularly with modern screen shapes, vertical space is at much more of a premium than horizontal space. What? Modern 10:16 screens give more lines than 3:4. 900x1440 gets like 70 lines with 100 columns at a decent font size, better than around 60 lines with 110 columns with 960x1280.

Good luck using your laptop vertically.

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

#147

Post by steveklabnik »

Coding_Cat wrote: post #120
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.

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.

We also have 'rustfmt' in development, which goes even further than the built-in lints.

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

#148

Post by acdha »

nisse72 wrote: post #139
Coding_Cat wrote: post #123

Earlier quoted context omitted.

If you don't have braces like in Python, then you always have the same visual feedback don't you? If you were to add braces to Python and auto-indent you'd end up with the same look as you would with python with only whitespace, only now there are superfluous brackets.

Rearranging code, refactoring, moving blocks, inserting conditionals etc would be easier and could be auto-indented if there were braces. Instead you need to carefully ensure that everything aligns correctly with the intended meaning at the new location. Also, a closing brace is a nice signal to the editor that it's time to "outdent". Finally, people seem to forget that python already has an opening brace, except it'…

You don't need advanced auto-indenting when the existing code is already correctly indented. Any decent programmers editor will automatically change the starting indentation point when you paste a block.

Your other points could be debated but really, is coding so keyboard-limited that saving a single keystroke is a major issue? Python has focused on comprehensibility, which I think is the right balance given how frequently people need to understand code versus write it.

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

#149

Post by lmm »

stephenr wrote: post #142
lmm wrote: post #116

Earlier quoted context omitted.

> 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, th…

As I said in the other thread I'm not talking about readability. The exact term used was pretty. > There will be a point at which an extra line makes the difference So why not remove all blank lines too. They're less important for reducing issues that single line/braceless flow control blocks can cause.

> So why not remove all blank lines too. They're less important for reducing issues that single line/braceless flow control blocks can cause.

By and large I do. But I don't think what you say is actually true. Given the choice between:

    stepa1
    if(something)
      stepa2
    stepa3

    stepb1
    stepb2
    stepb3
and

    stepa1
    if(something) {
      stepa2
    }
    stepa3
    stepb1
    stepb2
    stepb3
(same number of lines), I think the former is often more readable - stepa2 is visually separated in either case.

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

#150

Post by Aeolos »

serge2k wrote: post #127
Merad wrote: post #112

Earlier quoted context omitted.

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;`

> Personally I'm a fan of braces everywhere (though I prefer Allman style) you monster. So much wasted vertical space. We use that at work and I am not at all a fan.

That's why smart programmers use 2x monitors in portrait mode.

Try it once. You'll never go back.

Post reply on HN