Re: On Tabs and Spaces

* Thu 2007-10-18 Dmitry Torokhov [off-list ref]
* Message-Id: 200710180031.54819.dmitry.torokhov@gmail.com

On Wednesday 17 October 2007, Jari Aalto wrote:

quoted

- Any editor will display the text written in "all spaces"
  100 % the same. Regradless of any viewer or editor used.

But the same is not true with text that uses tabs (because you
really can't know what options the editor is preset / user set /
regarding the treatment of tabs).

The score is 1 - 0 for "all spaces" in this contest.

How about this - I like tabs because when you removing it you
need to hit Backspace just once and don't have to strain your
eyes figuring out "Did I delete enough? Does it line up now?"

First I must say that you're right. From user's perspective some things
are convenient and some things not so convenient; it depends:

 a) select an editor where these are no-issues
 b) use an editor that can be configured so that these are no-issues
 c) use the current editor and live by its limitations

I do not speak for any particular project here, just from a general
perspective[1]:

    A project policy QA enforces standards so that everybody can expect
    things to work the same way. The common denominator from view
    perspective (person A, B, C, D ... loads the text into a editor) is
    "all spaces". Similarly if code is post processed, all tools can
    expect that there are no surprises (it's all spaces, no combination
    of spaces and tabs).

The effect of a project policy in general is to enforce standards that
may not necessary match everybody's preferences[2].

Jari

[1] 99 % of the projects do not use Kernel's 8-wide indentation
convention. In all seriously taken editors, the TAB-key is configurable
to move to specific positions; so called "tab stops". Therefore "hit
TAB-key to insert tab character" does not usually apply in coding
context. In coding, the TAB-key is used to control the indentation
level, which is a measure defined in Project policy (coding style).

[2]
The tabs vs spaces issue is simular to those of:

- Starting curly brace placement policy: at EOL, or at separate line
- Identifier naming policy: camelCase vs. dash_names

-- 
Welcome to FOSS revolution: we fix and modify until it shines