4 ms·

> Python encodes structure in only one way, using indentation. There is no redundant signal that can be checked for a discrepancy that could indicate a problem.

> Python encodes structure in only one way, using indentation. There is no redundant signal that can be checked for a discrepancy that could indicate a problem. GCC and Clang can diagnose when indentation is "misleading" because it doesn't match what the braces are saying. I've seen both misplaced braces (akin to mis-indenting blocks in Python), indentation not matching braces and other problems of the same sort in non-Python code. Readers of the code would misunderstand the code when badly indented, and might introduce bad braces as well (not everybody uses automatic formatters and linters either, esp as they will sometimes "quickly" edit code in their non-usual dev environment). Not to mention that some "braced" languages allow having single-line blocks without braces. It's also not true that this is the only way Python encodes structure: new blocks generally only start with a ":", and you've got control flow keywords that allow for new blocks to start. One could argue that's a great feature disallowing you from introducing confusing spacing without actually having a new block started. While I am fond of applying many of double-entry-accounting principles in programming to increase trust in what we write, I believe that's much better done with unit-tests, which can more clearly demonstrate the expectations for any code and read more like documentation. Do you think all syntax in programming languages should have some sort of extra validation built-in? Eg. you should type in a constant twice (declare it as `const int a = 5` and then you have to set the value later as `a = 5` or you get an error?)? As I said above, people will always find an "objective" excuse why their preference is better. But I've seen bad-block-boundaries in Python as much as I've seen it in other languages which use explicit block boundaries like braces (and I've done more Python over the last ~20 years). I've heard this argument a gazillion times, but hundreds of bugs due to that have simply failed to materialize while working on large projects with tens and hundreds of people. Getting indentation right is _really_ not that hard, just like getting braces right is not that hard. I've yet to find someone who prefers their code to not be indented at all, and only rely on braces — at least not in a team setting where you can't simply reformat all of it.

kazinator 2y ago
> But I've seen bad-block-boundaries in Python as much as I've seen it in other languages You have to consider ones you have not seen: the ones that are valid syntax, and thus invisible. > (declare it as `const int a = 5` and then you have to set the value later as `a = 5` or you get an error?)? For that, it would be more like assert (a == 5). It's not commonly done for constants. Neither the definition nor assertion are perturbed by significant whitespace, so it isn't the same. If the constant only exists for clarity and not configuration (so the code cannot conceivably work with any other value), then the assertion would be warranted: assert(a == 5); // Did you read the comment about not changing a?
- necovek 2y ago
  > You have to consider ones you have not seen: the ones that are valid syntax, and thus invisible. Sure, that's a fair point, but the same holds true for braces. One of those bugs I found in non-Python code was there for a couple of years (badly placed braces). For the other topic, you were specifically praising the duality of braces and indentation to understand block boundaries. It's hard to come up with an example where everyone does the non-obligatory thing anyways (indentation in {} languages), since obligatory thing is, well, obligatory.
zzo38computer 2y ago
I prefer using braces to delimit blocks (although the code will be indented, too), and semicolons to separate lines (the "automatic semicolon insertion" is, in my opinion, one of the worst features of JavaScript). Sometimes I will deliberately indent code in an unusual way, e.g. temporary debugging code might be not indented at all (although such things are not usually present in the final code; they will usually be quickly removed after being added, and such temporary debugging code is often are not committed to the version control system). The ability for GCC and Clang to diagnose misleading indentation can be helpful; some programmers may wish to use it (and others may prefer to disable it). However, apparently it treats a tab as a number of spaces; I think that it should not do that, and using tabs on some lines and spaces on other lines to measure indentation within the same block, should always be considered misleading indentation (so if -Wmisleading-indentation is enabled, then it should always display a warning message in that case).
- necovek 2y ago
  Do you deliberately "misindent" the code or is it mostly because it's hard to reindent and then back the change out? If the latter, that's obviously a different use case and one can use syntax tricks to achieve the same with Python if you don't want to have your editor help with that for whatever reason.
  - zzo38computer 2y ago
    Deliberately, both in order to mark it in a special way to stand out clearly, as well as to avoid having to add indentation for such a code where it is unnecessary and not helpful. That line of code will soon be deleted anyways, so it does not matter much if other people dislike it.
    - necovek 2y ago
      Can you share an example where you non-temporarily add braces around a code block but then keep the indentation the same level as before the block? What do your collaborators think of it?
  - 2y ago

kazinator 2y ago

> But I've seen bad-block-boundaries in Python as much as I've seen it in other languages You have to consider ones you have not seen: the ones that are valid syntax, and thus invisible. > (declare it as `const int a = 5` and then you have to set the value later as `a = 5` or you get an error?)? For that, it would be more like assert (a == 5). It's not commonly done for constants. Neither the definition nor assertion are perturbed by significant whitespace, so it isn't the same. If the constant only exists for clarity and not configuration (so the code cannot conceivably work with any other value), then the assertion would be warranted: assert(a == 5); // Did you read the comment about not changing a?

necovek 2y ago
> You have to consider ones you have not seen: the ones that are valid syntax, and thus invisible. Sure, that's a fair point, but the same holds true for braces. One of those bugs I found in non-Python code was there for a couple of years (badly placed braces). For the other topic, you were specifically praising the duality of braces and indentation to understand block boundaries. It's hard to come up with an example where everyone does the non-obligatory thing anyways (indentation in {} languages), since obligatory thing is, well, obligatory.

zzo38computer 2y ago

I prefer using braces to delimit blocks (although the code will be indented, too), and semicolons to separate lines (the "automatic semicolon insertion" is, in my opinion, one of the worst features of JavaScript). Sometimes I will deliberately indent code in an unusual way, e.g. temporary debugging code might be not indented at all (although such things are not usually present in the final code; they will usually be quickly removed after being added, and such temporary debugging code is often are not committed to the version control system). The ability for GCC and Clang to diagnose misleading indentation can be helpful; some programmers may wish to use it (and others may prefer to disable it). However, apparently it treats a tab as a number of spaces; I think that it should not do that, and using tabs on some lines and spaces on other lines to measure indentation within the same block, should always be considered misleading indentation (so if -Wmisleading-indentation is enabled, then it should always display a warning message in that case).

necovek 2y ago
Do you deliberately "misindent" the code or is it mostly because it's hard to reindent and then back the change out? If the latter, that's obviously a different use case and one can use syntax tricks to achieve the same with Python if you don't want to have your editor help with that for whatever reason.
- zzo38computer 2y ago
  Deliberately, both in order to mark it in a special way to stand out clearly, as well as to avoid having to add indentation for such a code where it is unnecessary and not helpful. That line of code will soon be deleted anyways, so it does not matter much if other people dislike it.
  - necovek 2y ago
    Can you share an example where you non-temporarily add braces around a code block but then keep the indentation the same level as before the block? What do your collaborators think of it?
- 2y ago