[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[pygame] Spaces And Tabs Pointlessly Time-Wasting Religious Schism
On May 20, 2009, at 4:24 AM, don@xxxxxxxxxxxxxxxxx wrote:
Both, tabs and spaces, work. mixing them doesn't. So you must make
sure you only use one. which one you choose is more or less a matter
of taste as Chris wrote.
However, since mixing spaces and tabs is a bad idea it would be good
if all (python) programmers could agree on one or the other. I
believe that's why there is the python style guide I linked to
earlier. It sets a precedent/convention.
You can of course say you don't care and follow your own style but
it will make it harder and more annoying for others.
Therefore I would urge you to use spaces in python programs.
With no disrespect to either my exceedingly learned colleagues from
Lilliput who use spaces, or my sublimely enlightened colleagues from
Blefuscu who use tabs[1], this is Yet Another Pointlessly Time-Wasting
Religious Schism.[2]
The only problem is that our computers, which can be so lightning-fast
at replacing characters, cannot seem, even at this late date in their
evolution, to figure out when two lines are similarly indented and
therefore execute our code without complaint. Their text-editing
programs are only confounding the matter.
My meager solution has been to turn on an option that displays a faint
glyph representing each tab. Therefore, when I open a file, I somewhat
subliminally see which lines have an indenting problem, and I fix them.
Perhaps a better solution would be to agree on a spaces-tabs exchange
rates, but this, also has its zealots. Some people use a tab to mean
eight spaces, some four, and some two.
Is there some unix magic cookie format to explicate this exchange
rate? If so, then the battle is mostly won, and we "merely" have to
convince the myriad text editors to publish, honor, and obey the
cookies, silently sorting out the indentations and replacing whichever
with whatever.
If not, we "just" have to add the cookie format to Python's spec.
[1] cf. http://en.wikipedia.org/wiki/Endianness#Etymology
[2] See also Endianness, above, Emacs versus vi, "brackets on new
lines," etc.