[OT] Spaces/tabs (Was: simple display (from: GUI library for D))

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Wed Apr 13 14:44:20 PDT 2011


On 4/13/11 4:17 PM, "Jérôme M. Berger" wrote:
> Nick Sabalausky wrote:
>> ""J�r�me M. Berger""<jeberger at free.fr>  wrote in message
>> news:io4sng$1p9b$1 at digitalmars.com...
>>> Nick Sabalausky wrote:
>>>> ""J?r?me M. Berger""<jeberger at free.fr>  wrote in message
>>>> news:io230l$1ldc$3 at digitalmars.com...
>>>>> Well, I have worked in both environments, and I have seen a lot
>>>>> more mess ups with tabs than with spaces... Other than that (and the
>>>>> fact that almost *no* editors are able to do it properly), I would
>>>>> really prefer "tabs for indent, spaces for align".
>>>> I prefer "tabs for indent, tabs for align, spaces for separation", but
>>>> that
>>>> requires elastic tabstops. And at least one of the biggest code-edit
>>>> controls out there (the one I use), Scintilla, doesn't support them :(
>>>>
>>>>
>>> That depends what you mean by "align". I agree that for the
>>> following, elastic tab stops would be best:
>>>
>>> int      a;
>>> SomeType b;
>>>
>>> However, for this, I think that spaces are better:
>>>
>>> doSomething (someLongParameterThatJustifiesBreakingTheLine,
>>>              someOtherLongParameterJustInCase);
>>
>> I guess we disagree on that. Like I said in another branch, I used to do
>> that, but then I found that mixing tabs/spaces before the first
>> non-whitespace on a line is just asking for trouble.
>>
> 	Yes, that is the main reason why I use spaces for indenting...
>
>> I'd rather do it like this (assuming elastic tabstops):
>>
>> doSomething(->someLongParameterThatJustifiesBreakingTheLine,
>> ->             someOtherLongParameterJustInCase);
>>
>> Of course, that does demonstrate that I've never liked putting any
>> whitespace between a function name (or if/while/etc.) and the opening paren.
>> YMMV.
>>
> 	Well, standard (printed) typographic practices put spaces outside
> the parenthesis and none inside. And as opposed to a lot of
> typographic rules, that one is a constant across languages and variants.

Math typography rules also preclude inserting a space between a 
function's name and the opening brace. That's why I consistently go with 
no space after the opening paren or before the closing paren. Also, 
that's why there's no need to make if (condition) and func(args) 
consistent with regard to space before opening paren. In the first case 
the paren is pure punctuation; in the latter it is an organic part of 
the function invocation syntax. So one should never leave a space 
between function name and opening paren, and decide independently 
regarding the existence of a space between if/while etc. and the opening 
paren.


Andrei


More information about the Digitalmars-d mailing list