This is so useful, i wonder why it wasnt there before. Especially when copy-pasting code with different indentation levels / tabs etc.
GCC 6: -Wmisleading-indentation vs. “goto fail;”
51–60 of 168 posts
Re: GCC 6: -Wmisleading-indentation vs. “goto fail;”
#52Making 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.
Single-line ifs are pretty useful with traditional-style C libraries that expect all checks to be done at call site: if (ptr) call_oldschool_thingy(ptr);
Does this outweigh the disadvantages? I don't think so.
Re: GCC 6: -Wmisleading-indentation vs. “goto fail;”
#53Earlier quoted context omitted.
Wouldn't it make sense to update that as you change the code? If you edit an if statement, you should add the braces in. It would make sure that no new errors are introduced due to this.
That's a good policy for code reviews, but again it's hard to do it correctly in a tool. The compiler would need to require braces in new code, but allow brace-free style in old code; you'd need to integrate it with the source control system so it knows what code is new. Doable, but tricky.
I've found improving style checks file-by-file to be a reasonable approach:
- all new files are checked
- old files are put in a whitelist for the style checker, the submitter is supposed to remove the file from the whitelist when signifcant changes are made
Re: GCC 6: -Wmisleading-indentation vs. “goto fail;”
#54Earlier quoted context omitted.
Single-line ifs are pretty useful with traditional-style C libraries that expect all checks to be done at call site: if (ptr) call_oldschool_thingy(ptr);
I'm not sure that expanding your statement to multiple lines is any less "useful". I suppose in certain cases it can make code much more verbose, as one line effectively becomes 3-4, which can make it harder to navigate.
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);
window = foo_window_create();
data = foo_buffer_create(1, 2, 3);
label = foo_label_create(window);
image = foo_image_create(window);Re: GCC 6: -Wmisleading-indentation vs. “goto fail;”
#55Making 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.
Single-line ifs are pretty useful with traditional-style C libraries that expect all checks to be done at call site: if (ptr) call_oldschool_thingy(ptr);
I've never met a C or C++ debugger that handled this case nicely, unfortunately. Totally ridiculous, of course, because they could! They just never seem to.
Meeting snippets of code like that when debugging is a constant source of frustration for me, because I have to stop what I was doing, edit the code, rebuild, then get back to where I was. Particularly galling when the code in question is in a commonly-included header, and the subsequent build takes several minutes, and I was on a particularly productive-looking trail.
(The last project I worked on solved (?) this problem by performing so shamefully poorly in an unoptimised build that it effectively didn't work. So you had to debug the optimised build. And so single-stepping at the source level just didn't work properly anyway.)
Re: GCC 6: -Wmisleading-indentation vs. “goto fail;”
#56The 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 }
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.
Re: GCC 6: -Wmisleading-indentation vs. “goto fail;”
#57Earlier quoted context omitted.
No. That is not what I mean. If you look at my response to iainmerric you will see that I don't feel you should change code that is working. This type of bug is largely introduced from someone who is going in and changing a section of code. My philosophy is that if you are editing a section of code, you should update the braces in that section along with your current patch. Over time you see a larger and larger drop…
That seems like a somewhat different case, though. Your approach will help prevent new bugs like this from being introduced, but won't help you against existing examples of it in areas you're not currently working on. And just because it's been around a long time doesn't mean it's "working." Goto fail showed that the bugs can be subtle and easily missed for a long time.
Yes, but from what I understand this bug is more commonly introduced in code that is being updated.
Notice that I said "avoided", not "fixed". That is because I am rather focused on making code that is maintainable.
I posted this original comment to have a dialogue about something I include in my programming practices. I wanted to see how other people viewed this as a development technique.
Re: GCC 6: -Wmisleading-indentation vs. “goto fail;”
#58Earlier quoted context omitted.
That's a good policy for code reviews, but again it's hard to do it correctly in a tool. The compiler would need to require braces in new code, but allow brace-free style in old code; you'd need to integrate it with the source control system so it knows what code is new. Doable, but tricky.
I've found improving style checks file-by-file to be a reasonable approach: - all new files are checked - old files are put in a whitelist for the style checker, the submitter is supposed to remove the file from the whitelist when signifcant changes are made
I'm very glad to see that I'm not the only one who does this. I wanted to see if others felt that this process worked.
It is good to hear others are doing it.
Re: GCC 6: -Wmisleading-indentation vs. “goto fail;”
#59Earlier 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.
Agreed, but i m talking about moving the cursor there.
Re: GCC 6: -Wmisleading-indentation vs. “goto fail;”
#60Semi-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 to mentally picture the control flow.
if(condition_a && condition_b){
do_thing_a();
} else if(condition_b){
do_thing_b();
} else {
do_something_else();
}
if(condition_a){
if(condition_b){
do_thing_a();
} else {
do_thing_b();
}
} else {
do_something_else();
}