38 ms·
I like how python’s indentation scheme makes code look nearer, but I find it scary in the following case: for i in range(0, m): for j in range(0, n):
by wallscratch 5y ago
I like how python’s indentation scheme makes code look nearer, but I find it scary in the following case:
for i in range(0, m):
for j in range(0, n):
doInner()
doOuter()
A single tab here in the 4th line produces syntactically correct but logically incorrect code. I find this scary.
I guess it would be easy to just write your own preprocessor that requires curly braces everywhere and removes them for the python interpreter, but eh.
- qsort 5y agoYeah, I don't like Python's approach in re syntax either. In addition to your example, it backfires for things like multiline formulas (need to add parentheses or escapes) or lambdas. Braces (or even 'end' like ruby) would be much more practical.
- dan-robertson 5y agoAlso you need white space diffs to be turned on to spot this change in code review, and this is particularly bad if indentation changed for another reason.
- lolinder 5y agoTo be fair, you probably always want whitespace diffs turned on if reviewing Python, since indentation is meaningful.
- Jcowell 5y agoWon’t there be an indentation error on line 3?
- xigoi 5y agoIs this really different from braces? If you have for i in range(0, n) { for i in range(0, n) { doInner() } doOuter() } and you accidentally move the first closing brace below the next line, precisely the same will happen.
- MauranKilom 5y agoIf you do that, the indentation will be clearly wrong/mismatched and a compiler (or linter) can bark about it. No such possibility in python.
- akersten 5y agoMore likely the IDE just auto-indents the errant line and the programmer is still none-the-wiser.
- Jyaif 5y agoIn Python the mistake involves using the wrong invisible characters. It's totally bonkers.
- xigoi 5y agoSpaces are visible, unless they're at the end of a line.
- duped 5y agoThis example seems contrived. I used to swear by clean demarcations of expressions because of this logic, but in practice the return values of nested expressions are so rarely the same, and always reviewed before merge, with at least some kind of test or that would make this obvious, it would be almost unnoticeable. For example : for i in range(0, m) : for j in range(0, n) : ... inner ... ... outer ... If `...inner...` is dedented then you will almost certainly get a compilation error since it is referencing `j`. If `j` is not referenced at all, you'll get a linter error saying "unused variable, j". Additionally, you probably wouldn't want to write nested for-loops anyway, but something like flattening the inner loop into a return value.
- dragonwriter 5y ago> If `...inner...` is dedented The problem usually isn’t …inner… being dedented, but …outer… being indented. Which usually won’t produce an error, since anything that could be in …outer… could also be in …inner… without error. > Additionally, you probably wouldn’t want to write nested for-loops anyway, but something like flattening the inner loop into a return value. Nested for-loops aren’t uncommon in real-world code. And, I…am not sure what you are saying here. Loops are imperative constructs, not return values.
- brandmeyer 5y agoSince Python scopes lexical variables to the function instead of the block, `j` is in scope for every line of `... outer ...`. So de-denting the last line of inner doesn't trigger a NameError, even for new bindings which were introduced within `... inner ...`.