Every FOSS project I know has rules against trailing whitespace in code. But I think it's very natural to continue the current indentation on the next line:
int main() { ....int a = 42; .... ....return a; }
But git for instance throws warnings anyway. So my question is: Why are those tabs inside the current indentation bad?
I'm not looking for answers like "It's always done this way". Let's assume indentation is done consistently in the whole project in question.
Whitespace is any character or series of characters which creates space on a page but does not display a visible mark. Common whitespace characters include tabs and spaces. Indentation is a type of horizontal whitespace strategically used to enhance the readability of our code.
In computer programming languages, indentation is used to format program source code to improve readability. Indentation is generally only of use to programmers; compilers and interpreters rarely care how much whitespace is present in between programming statements.
Indentation, the much-maligned formatting technique, provides readers with a sense of continuity. Indentations signal to the reader that she is about to dive into another topic or start a new section of a novel. They help present content in a logical fashion.
Indentation refers to the spaces at the beginning of a code line. Where in other programming languages the indentation in code is for readability only, the indentation in Python is very important. Python uses indentation to indicate a block of code.
It is probably because merging patches with useless whitespace is harder than it should be.
diff(1)
and patch(1)
treat spaces and tabs as important content. (Ask any Makefile
or .py
source file -- they are important!) And if your "blank line" has four spaces on it, and my "blank line" has eight spaces on it, any attempt to share patches between us will fail for very trivial reasons.
Granted, if you wholesale change the indentation of a block of code, you'll have to go to some work to make patches apply anyway. But trying to track down merge failures on lines that look blank is painful. (I've wasted too much of my life doing just that. Yes, vim
listchars
can help, but reading code with listchars
on all the time is also annoying.)
So people standardize on no trailing whitespace. It might not really make sense to worry about a dozen lost bytes here or there from a storage standpoint, but it really makes merging patches easier. We could probably just as well standardize on adding trailing whitespace, exactly as you have suggested, and be just as happy, but we might as well standardize on the approach that is as parsimonious as possible.
This can also be rude to vi users who are accustomed to using paragraph navigation to jump around through code. Sometimes I do this when vi and it's quite surprising when I skip several functions because invisible characters said this is actually part of the previous paragraph.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With