Tab indentions on different platforms?

[Steven D'Aprano]

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.



-- 
Steven