GCC 6: -Wmisleading-indentation vs. “goto fail;” • Hacker News Board

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

#161

Post by nisse72 » Sat, Feb 27, 2016, 12:30 AM UTC

acdha wrote: post #148

nisse72 wrote: post #139

Earlier quoted context omitted.

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

If you move a block of code to a place just after e.g. a loop, it isn't clear whether it should be inside or outside the loop, your editor cannot guess this. You still need to tell it at what level the new code should be inserted. And if the end of the loop happens to be nested further, the ambiguity is exacerbated.

I switch between C and Python quite frequently. With C, I just type the code, and let my editor manage the indentation, which it can do perfectly without any help from me. With Python, I find that I spend a lot more time thinking about the formatting itself, especially at the end of block, because it's up to me to get it right.

I fail to see how the _lack_ of a closing brace _improves_ comprehensibility. What Python has done is removed a helpful indicator, and put more of the responsibility on the programmer.

I'm happy to type that extra character in C, because it helps lower my cognitive workload so I can focus more on the problem I'm trying to solve. The closing brace doesn't mean anarchy, or make the code harder to understand later.

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

#162

Post by acdha » Sat, Feb 27, 2016, 1:15 AM UTC

nisse72 wrote: post #161

acdha wrote: post #148

Earlier quoted context omitted.

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

If you move a block of code to a place just after e.g. a loop, it isn't clear whether it should be inside or outside the loop, your editor cannot guess this. You still need to tell it at what level the new code should be inserted. And if the end of the loop happens to be nested further, the ambiguity is exacerbated. I switch between C and Python quite frequently. With C, I just type the code, and let my editor manage…

> If you move a block of code to a place just after e.g. a loop, it isn't clear whether it should be inside or outside the loop, your editor cannot guess this. You still need to tell it at what level the new code should be inserted. And if the end of the loop happens to be nested further, the ambiguity is exacerbated.

1. Move the cursor to wherever you want to put the block 2. Hit paste 3. Your editor adjusts the indentation so the entire pasted block is inserted as if you just keyed it in

It's simple and reliable and as a bonus it's portable across any language where the code is indented correctly.

> The closing brace doesn't mean anarchy, or make the code harder to understand later.

It's true that well-written C code can be almost exactly the same but the difference is that the world is full of sloppy C code where someone hammered out a bunch of changes, decided it was too much work to format it so the visual display matched the actual parsed structure, and left a trap for the next developer who touches that code. Yes, hopefully they'll review & test carefully but, as with e.g. memory management, we have decades of proof that depending on programmers to consistently follow desirable practice is a losing battle unless it's enforced by tools.

The point isn't that braces are bad and that whitespace is good but that Python will refuse to execute one class of sloppy code. Imagine if GCC made this flag mandatory or Clang refused to compile anything which didn't pass cleanly through clang-tidy – the benefit wouldn't be due to the braces but from the fact that one category of error would simply no longer be possible and every C developer on the planet would spend less time on cosmetic differences when reading other people's code.

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

#163

Post by KMag » Sat, Feb 27, 2016, 4:06 AM UTC

to3m wrote: post #91

ktRolster wrote: post #64

Earlier quoted context omitted.

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

That's likely because with C#, the debugger can use deoptimization and on-stack replacement to get expressions evaluated in the order they happen in the code, as long as the instruction re-ordering happens only in the bytecode to native code compilation. Even though the debugging symbols just have line numbers, the debugger could potentially regenerate they bytecode to figure out which operations correspond to which expressions.

In C++ optimized builds, you might be jumping back and forth between lines due to the compiler re-ordering instructions, and there isn't an easy way to get back code that's in-order.

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

#164

Post by wdr1 » Sat, Feb 27, 2016, 4:40 AM UTC

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.

> Making braces optional in single-statement if/else/while/for clauses is one of the biggest anti-features in C.

What's frustrating is that K&R still has a lot of example code like that as well. It would be wonderful to see a 3rd edition even if it do nothing but change its code to use braces.

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

#165

Post by Piskvorrr » Sat, Feb 27, 2016, 3:11 PM UTC

Grue3 wrote: post #41

Piskvorrr wrote: post #16

Earlier quoted context omitted.

Prettier but potentially dangerous? That's the core of the problem, I believe.

Everything is potentially dangerous. I mean, pointers, anyone? So many things that can go wrong with those. And besides, code is for humans to read and only incidentally for computers to execute. Might as well optimize for prettiness.

This is the poster case for "code is for humans to read, so it shouldn't be easy to mis-read." Braceless misindented ifs are everything except easy to read.

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

#166

Post by nisse72 » Sat, Feb 27, 2016, 6:17 PM UTC

acdha wrote: post #162

nisse72 wrote: post #161

Earlier quoted context omitted.

If you move a block of code to a place just after e.g. a loop, it isn't clear whether it should be inside or outside the loop, your editor cannot guess this. You still need to tell it at what level the new code should be inserted. And if the end of the loop happens to be nested further, the ambiguity is exacerbated. I switch between C and Python quite frequently. With C, I just type the code, and let my editor manage…

> If you move a block of code to a place just after e.g. a loop, it isn't clear whether it should be inside or outside the loop, your editor cannot guess this. You still need to tell it at what level the new code should be inserted. And if the end of the loop happens to be nested further, the ambiguity is exacerbated. 1. Move the cursor to wherever you want to put the block 2. Hit paste 3. Your editor adjusts the ind…

I hear what you are saying, and really I don't mind that the formatting is required by the language, I'm not arguing against that.

But... we could have had both! Absolutely require the formatting, but also keep the magic symbols that help your tools help you!

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

#167

Post by derefr » Sun, Feb 28, 2016, 7:23 PM UTC

ajross wrote: post #143

strommen wrote: post #131

Earlier quoted context omitted.

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?

There's probably a word that the parent was looking for; it wasn't quite aesthetics, at least as you've defined it.

Sometimes you can write code that looks "prettier", at the expensive of the ability to read and reason about it. Optional braces are frequently used for this effect. Yes, optional braces allow you to fit more code on the screen with less noise—and therefore could be thought to enhance some kind of readability. But at the same time, they require you to think harder about the grouping of the code around them. Unless you've got a reformatting linter, you could have code like this:

    if(foo)
      bar; baz;
    quux;

and optional braces require an extra subroutine to be constantly running in your head, looking for those mis-arranged `baz`es that will get executed anyway. That cognitive load detracts from your ability to read and reason about the code.

(What'd be really interesting, in my opinion, would be to make C's braceless blocks, and only braceless blocks, have semantic-whitespace. Then the above would be able to be easily reasoned through: `baz` is part of the conditional, because it's on the same line. But this breaks a lot of rather old and inflexible assumptions about how C is parsed, that macro-writers et al depend on.)

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

#168

Post by wting » Wed, Mar 09, 2016, 3:26 AM UTC

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…

Kinda late but I want to point out these snippets have different behaviors:

    if A and B:
        ..
    elif B:
        ..

vs

    if A and B:
       ..
    elif A and not B:
       ..

I prefer flattening because enumeration makes it obvious what's different between the branches despite the code duplication.

For example, three boolean conditions has 2^3 = 8 possible combinations. When nested this complexity is hidden but obviously apparent as a code smell when flattened.

It also echoes Python's ethos that flat is better than nested.