* Thu 2007-10-18 Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx>
* Message-Id: 200710180031.54819.dmitry.torokhov@xxxxxxxxx
> On Wednesday 17 October 2007, Jari Aalto wrote:
>
>> - 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
