Tab indentions on different platforms?
steve at REMOVE-THIS-cybersource.com.au
Tue Jan 1 16:03:11 CET 2008
On Mon, 31 Dec 2007 12:36:11 +1100, Ben Finney wrote:
> Steven D'Aprano <steve at REMOVE-THIS-cybersource.com.au> writes:
>> On Sun, 30 Dec 2007 20:41:09 +0000, Thorsten Kampe wrote:
>> > Anyway: the consequence of your well done argumentation is that
>> > someone editing Python code has to use a specialised editor to
>> > prevent screwing up tab indented code - and that's bad.
>> You just need to use an editor that inserts tab characters when the tab
>> key is pressed, just like you use an editor that inserts s characters
>> when the s key is pressed.
> No, that's not all you need to do. You also need to keep your code away
> from the majority of programmers, who use their default editor in its
> default settings
I question that. On my system at least (Fedora 7), here are the default
settings on the editors I have available:
vi default is tab character
emacs default is tab character
gedit default is tab character
nano default is tab character
joe default is tab character
kedit always uses tab character
kwrite default is tab character
kate default is tab character
scribes default is tab character
eclipse default is tab character
With every Linux distro being slightly different, your mileage may vary,
but with not even a single editor on my system defaulting to spaces, I
hope you can excuse my skepticism.
And if you extend your view to the 90% of the computing world that
doesn't use a Unix-like operating system, we can consider:
VisualStudio default is tab character
Epsilon default is tab character
Notepad always uses tab character
Wordpad always uses tab character
No doubt there are a hundred other Windows text editors, but I'm not
familiar with them. Nor am I familiar with OS X based text editors,
although back in the 1990s Apple Mac text editors invariably inserted a
tab when you pressed the tab key.
> and who expect that horizontal whitespace is produced
> by the U+0020 space character (even if they don't know the specifics of
> the character coding).
> Saying that the tabs-only argument and the spaces-only argument are of
> equal value is philosophically true, but practically worthless. They're
> of equal value *only* in isolated environments where you can control the
> expectations of *every* programmer who will *ever* edit the file.
Ah, and now we're getting somewhere! It's not so much that tabs are
intrinsically harmful (as people like Thorsten keep insisting), but that
in a world supposedly dominated by people who indent with spaces, using
tabs might lead to inconsiderate programmers ignoring your project's
coding standards and inserting spaces into your code base.
Yes, I can see that is a problem. I believe it is best solved by refusing
contributions from such inconsiderate programmers. After all, if they're
going to ignore your project's code standards in one aspect, they're
invariably going to ignore others as well.
Ben, I'm surprised that you of all people should take such a pragmatic
view that "tabs are bad because the majority use spaces". By that
reasoning, you should be driving a SUV (much safer than riding a bike!),
sending HTML-only emails written in Outlook (with Word as your editor
naturally) and publishing data solely in proprietary binary formats
like .doc. Everybody else does it, why buck the trend?
There's a very good reason to buck the trend whenever practical: tabs
have the considerable benefit that they decouple the presentation of the
code from the structure of the code.
When you use tabs to indent code, the reader can place their tab stops
where ever they wish, according to their own needs and preferences: every
eight spaces, or four, or three, or twenty-seven spaces if they want. One
tab means one indent level (structure), and the width of that indent
(presentation) is up to the reader.
But when you use spaces, you are essentially forcing your presentation
onto all your readers, whatever their wishes. Sure, some editors let you
re-indent code at the press of a button, and some of them might even get
it right more often than not -- but for Python at least, if you want to
contribute code back to the project, you can't afford to do that. You're
stuck using whatever presentation the project manager chooses.
Using spaces is fundamentally broken because it turns a structural single
level of indentation into a presentational four spaces -- or eight, or
two, or five, whatever the project's coding standard insists on.
> To form an indentation policy based only on hypothetical
> fully-controlled isolated environments is foolish, to say the least.
Just say I'm tilting at windmills.
More information about the Python-list