3 ms·

> You still get errors caused by mis-indented statements which are almost just as hard to check (if the indent continues for 10-15 lines and is nested etc). I

> You still get errors caused by mis-indented statements which are almost just as hard to check (if the indent continues for 10-15 lines and is nested etc). I find wrong indents miles easier to see than unbalanced brackets/braces though. A single bracket/brace is only one symbol so it's hard to spot but it completely changes the semantics (see Apple's goto fail error). > I think go had the best idea in this with gofmt: all code should be auto-formatted absolutely the same -- then it becomes trivial to read. Yes, I like this. There's so many pointless arguments about things to do with naming conventions and tabs vs spaces...just make it part of the language so people can argue about more important topics.

krapp 9y ago
goto fail was caused by a failure to use braces at all - ironically, it seems, for the same aesthetic reasons that significant whitespace is used, because it seems "cleaner." Had braces been used, the error might have been easier to spot or might not have happened at all.
- seanwilson 9y ago
  Significant whitespace forces the look of the code and the meaning of the code together to prevent mistakes like that though. It's really silly that indenting code within a condition is a universal code formatting convention but it's not enforced by the compiler. I can't think of any exceptions where you wouldn't want to indent code like that and it's obvious badly indented code can be misleading so I don't see why a compiler shouldn't pick that up for you.
  - krapp 9y ago
    The conventions around whitespace and code formatting are not universal, and the problem is once the compiler has to care about whitespace, it's no longer whitespace, it's code. Code has to be correct in ways whitespace doesn't. Some people use tabs, some people use spaces. Some people even use both. In terms of whitespace, it doesn't really matter. But, if your language cares which of the visually indistinguishable but otherwise incompatible kinds of non-printing characters you're formatting your code with, then it can still fail while visually communicating the correct information to the reader.
    - seanwilson 9y ago
      > The conventions around whitespace and code formatting are not universal How is it not though? For every mainstream language it's standard convention to indent conditions and functions. > But, if your language cares which of the visually indistinguishable but otherwise incompatible kinds of non-printing characters you're formatting your code with, then it can still fail while visually communicating the correct information to the reader. This a complete non-issue to me. The pros of significant whitespace vastly overshadow any possible benefit of letting people choose tabs vs spaces and the latter issue is easily solved with IDEs anyway. I don't see people having any issues with this using Python either. Personally, I think even naming conventions should be enforced by the language as well so people can stop wasting time debating insignificant details and in code reviews.
- coldtea 9y ago
  >goto fail was caused by a failure to use braces at all - ironically, it seems, for the same aesthetic reasons that significant whitespace is used, because it seems "cleaner." In Python's case it's not just an aesthetic -- the whitespace is also functional, so that mistake can't happen just for aesthetics.

krapp 9y ago

goto fail was caused by a failure to use braces at all - ironically, it seems, for the same aesthetic reasons that significant whitespace is used, because it seems "cleaner." Had braces been used, the error might have been easier to spot or might not have happened at all.

seanwilson 9y ago
Significant whitespace forces the look of the code and the meaning of the code together to prevent mistakes like that though. It's really silly that indenting code within a condition is a universal code formatting convention but it's not enforced by the compiler. I can't think of any exceptions where you wouldn't want to indent code like that and it's obvious badly indented code can be misleading so I don't see why a compiler shouldn't pick that up for you.
- krapp 9y ago
  The conventions around whitespace and code formatting are not universal, and the problem is once the compiler has to care about whitespace, it's no longer whitespace, it's code. Code has to be correct in ways whitespace doesn't. Some people use tabs, some people use spaces. Some people even use both. In terms of whitespace, it doesn't really matter. But, if your language cares which of the visually indistinguishable but otherwise incompatible kinds of non-printing characters you're formatting your code with, then it can still fail while visually communicating the correct information to the reader.
  - seanwilson 9y ago
    > The conventions around whitespace and code formatting are not universal How is it not though? For every mainstream language it's standard convention to indent conditions and functions. > But, if your language cares which of the visually indistinguishable but otherwise incompatible kinds of non-printing characters you're formatting your code with, then it can still fail while visually communicating the correct information to the reader. This a complete non-issue to me. The pros of significant whitespace vastly overshadow any possible benefit of letting people choose tabs vs spaces and the latter issue is easily solved with IDEs anyway. I don't see people having any issues with this using Python either. Personally, I think even naming conventions should be enforced by the language as well so people can stop wasting time debating insignificant details and in code reviews.
coldtea 9y ago
>goto fail was caused by a failure to use braces at all - ironically, it seems, for the same aesthetic reasons that significant whitespace is used, because it seems "cleaner." In Python's case it's not just an aesthetic -- the whitespace is also functional, so that mistake can't happen just for aesthetics.