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.
People will make mistakes. Policy does not prevent that. Tools do.
GCC 6: -Wmisleading-indentation vs. “goto fail;”
31–40 of 168 posts
Re: GCC 6: -Wmisleading-indentation vs. “goto fail;”
#32I wonder if it would be feasible to add a -allow-python-style option, which would allow the use of some Python syntax in C++, like significant whitespace or `if a:` instead of `if (a)`
Cython is already something sort of like this.
Re: GCC 6: -Wmisleading-indentation vs. “goto fail;”
#33Earlier 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.
Prettier but potentially dangerous? That's the core of the problem, I believe.
I agree. I don't care much about if something looks good, but rather if it works well.
Re: GCC 6: -Wmisleading-indentation vs. “goto fail;”
#34Making 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);
Braces don't prevent you from using single-line if:
if (ptr) { call_oldschool_thingy(ptr); }Re: GCC 6: -Wmisleading-indentation vs. “goto fail;”
#35The 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.
Re: GCC 6: -Wmisleading-indentation vs. “goto fail;”
#36Making 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.
Re: GCC 6: -Wmisleading-indentation vs. “goto fail;”
#37This 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.
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)
Re: GCC 6: -Wmisleading-indentation vs. “goto fail;”
#38Making 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);
Was just discussing this at work. A good compromise would be to allow statements outside of of block-parens only when they are on the same line as the control statement.
IMHO there should be a -W to enforce this so those of us with -Werror on can catch it and burn it with fire.
Here at Google the style guide requires block-parens always.
Re: GCC 6: -Wmisleading-indentation vs. “goto fail;”
#39This 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 remember doing this mistake back in college. Was required to program and demo the B-Tree backend for a mini database. Things were very well tested for tons of random sets of data but while waiting for the my turn to demo, added one line of debug print on an "if" statement which caused the now dangling statement to be always executed. This caused a subtle bug that the professor caught in his testing. Sucked because I had everything correct up to that point. Learned my lesson about last might changes and coding style at that point.
Re: GCC 6: -Wmisleading-indentation vs. “goto fail;”
#40The 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 }