indent style for D

[Iain Buclaw]

On 29 January 2012 18:11, Denis Shelomovskij
<verylonglogin.reg at gmail.com> wrote:
> 29.01.2012 18:09, Iain Buclaw пишет:
>>
>> On 29 January 2012 14:04, Denis Shelomovskij
>> <verylonglogin.reg at gmail.com>  wrote:
>>>
>>> 29.01.2012 15:21, Alex Rønne Petersen пишет:
>>>
>>>
>>>> On 29-01-2012 10:15, Gour wrote:
>>>>>
>>>>>
>>>>> Hello!
>>>>>
>>>>> It was mentioned in #D that gdc will probably adapt its code to GNU
>>>>> code
>>>>> style and I wonder, seeing no recemmendation in
>>>>> http://www.d-programming-language.org/dstyle.html in regard to
>>>>> indent-style, can someone shed some light what is recommended practice
>>>>> for it within D community?
>>>>>
>>>>>
>>>>> Sincerely,
>>>>> Gour
>>>>>
>>>>
>>>> Phobos generally uses 4-space indentation.
>>>>
>>>
>>> I don't think there is the best coding style (personally I like both K&R
>>> and
>>> Allman styles). IMHO things are different with indention. Why does Phobos
>>> use 4-space indentation?
>>>
>>> The following article (IMHO) completely covers tabs vs spaces problem:
>>> http://www.emacswiki.org/cgi-bin/wiki/TabsAreEvil
>>>
>>> It shows that tabs (in spite of the article title) are really good and
>>> should be used always (and only) for indention. Looks like Allman style
>>> doesn't prevent this (if it does, what is the reason?). So:
>>> * Such tab using shows respect to a programmer allowing him to configure
>>> tab
>>> size as he prefer.
>>> * Sometimes indention should be changed for a particular using.
>>> * Worst of all, sometimes same code is used in different places where
>>> different indention levels are expected.
>>> * Using spaces guarantee that code will look same in every editor but it
>>> is
>>> the simplest and not the most convenient way, the code should look _good
>>> for
>>> every editor user_, not _same_, so it tears down our community.
>>> * It's less comfortable to use spaces for indention in every editor I use
>>> (at least because spaces allows caret position in the middle of indention
>>> and pressing<one of delete one char keys>  deletes one space instead of
>>> the
>>> indention level, so it's easy to accidentally broke indention and use,
>>> e.g.
>>> 7 instead of 8 spaces).
>>>
>>> And this isn't only a theory. In practice:
>>> * I've never liked 8-chars indention, so I feels myself bad in d-p-l.org
>>> sources. Probably I'm not the only one.
>>> * I accidentally brake spaces indention sometimes. Probably I'm not the
>>> less-trained-in-printing one.
>>> * Some time ago a ebook version of d-p-l.org has been created. Walter had
>>> to
>>> change every 4-spaces indention in examples to 2-spaces indention for
>>> convenience reading on small PPC screen.
>>> * Now everyone see 2-spaces indented examples in d-p-l.org instead of
>>> his,
>>> probably, preferred 4-spaces indented.
>>>
>>> Am I mistaken? If no, am I missing some major spaces advantages? If no,
>>> lets
>>> use tabs. Perhaps, there is no tool that will convert (convert right, not
>>> somehow, see article) tabs<->spaces in D code.
>>
>>
>> The problem is lines with mixed tabs and spaces, and different users
>> set their text editors see tabs differently. ie: is your tab-width set
>> to 2, 3, 4, or 8?
>>
>
> Example, please.
>
> P.S.
> Have you read the article? (I'm asking that just because I can't imagine an
> example or I don't clearly understand what do you mean)

eg:

{
...->test1();
->test2();
..->test3();
}

If someone has their tabs aligned to 4 characters or higher, they will
see the above as if they are indented to the same offset, any less,
and things get interesting:

tabstop=4;'
{
    test();
    test2();
    test3();
}

tabstop=3;
{
      test1();
   test2();
   test3();
}

tabstop=2;
{
    test1();
  test2();
    test3();
}

tabstop=1;
{
    test1();
 test2();
   test3();
}


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';