Live data from Hacker News

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

developerblog.redhat.com

121–130 of 168 posts

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

#121
post #72
post #54

Earlier quoted context omitted.

Fairly often there's a whole sequence of this type of calls. For example cleanup of multiple objects: if (image) foo_release(image); if (label) foo_release(label); if (data) foo_buffer_destroy(data); if (window) foo_window_destroy(window); It's easier to see that all objects are being cleaned up when each occupies just one line, as that typically matches the look of the initialization: window = foo_window_create(); d…

Those if statement should be written using the ternary operator. In my subjective opinion, putting the expression in the same line as the if statement is awful. Objectively it is worse because you create a possibility of certain types of errors, like a hanging statement or similar. Ternary operator doesn't have those. The second example is missing error checking. So the real code isn't that nice. My point is that C s…

How would you use the ternary operator there? Like this?

    image ? foo_release(image) : 0;

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

#122
post #40
post #30

The argument for significant white space in Python goes as follows: You need indentation for humans to understand the structure. Why do you also need braces for the parser to understand the structure when the parser can use the same information that your eyes use? You therefore avoid the possibility of the two signals contradicting each other.

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

Lack for jumping to the end of the current indent block is a missing-feature/bug in vi then. There is nothing technologically harder about finding the end of a block based on indentation than based on braces.

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

#123
post #30

The argument for significant white space in Python goes as follows: You need indentation for humans to understand the structure. Why do you also need braces for the parser to understand the structure when the parser can use the same information that your eyes use? You therefore avoid the possibility of the two signals contradicting each other.

Because, by having both, you can have your editor auto-indent and then you get a visual indication of where implementation does not equal intention.

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.

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

#124
post #72

Earlier quoted context omitted.

Those if statement should be written using the ternary operator. In my subjective opinion, putting the expression in the same line as the if statement is awful. Objectively it is worse because you create a possibility of certain types of errors, like a hanging statement or similar. Ternary operator doesn't have those. The second example is missing error checking. So the real code isn't that nice. My point is that C s…

How would you use the ternary operator there? Like this? image ? foo_release(image) : 0;

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.

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

#125
post #11

Nice. These sorts of warnings are why it's worth investing the extra effort to enable -Werror in your codebase if you can.

No, I've never seen a real use case for -Werror. What's the difference if compilation stops at the warning? You'll (or your team, or whoever) fix it anyway, and if you won't, you have a people problem, that must be solved at the policy (or HR) level. Solving people problems at the tooling level is a certain way to get unintended consequences and alienate the good people that weren't part of the problem. Of course, yo…

In a large build, people will not notice warnings scrolling past. -Werror gives everyone the people of mind that you will notice warnings.

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

#126
post #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.

> like any other tool it's up to who is using it to use it in the right way.

And mandatory seat belt use is foolish, bike helmets are for wimps, and blade guards on saws are a waste of space and money.

Just use those tools responsibly :P

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

#127
post #112

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.

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.

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

#129

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.

I agree. But your last example won't compile anyway. Though this would: if (true) foo(); else bar(); baz(); But I have to admit if you ever actually do that, you have failed to fundamentally understand how your code is executed. No braces means one statement. Period. In these cases languages which are auto formatted (C#, go-fmt, etc) likely have an advantage where these problems stick out more obviously.

But I have to admit if you ever actually do that, you have failed to fundamentally understand how your code is executed

I would say I have a pretty good understanding of how C & my code in general works, I'm currently trying to create a threadpool with support for co-routines/yielding to other threads in userspace. Nothing super fancy, but not something you can do without understanding how code is actually executed ;)

But I still lost an hours work last week because I hadn't put a brace after an if statement and when I came back to it, I didn't notice the lack of braces and put an extra statement behind it. This is why I usually stick to putting braces around everything.

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

#130
Why not give to your developers an immediate way to reformat the whole source tree before each commit/pullrequest, using dedicated tools, like uncrustify, bcpp or AStyle? Just store the configuration file in the repository, hook the reformat pass to the beginning of your build, and you're done.

We've been doing this at work for several years ; and we found that this solved nearly every style-related issue (diffs, arguments over which code is 'prettier', artificial merge conflicts). It turns out the style becomes a lot less important issue once you can rely on a tool to apply it for you. And it also solves the misleading indentation issue (probably by preventing it to happen in the first place by causing a merge conflict).

Post reply on HN