January 29, 2012
On 1/29/2012 6:04 AM, Denis Shelomovskij wrote:
> Why does Phobos use 4-space indentation?

Because it works, changing it would be a vast waste of time for a non-existent benefit, and it would become a nuisance to do diffs of source code that cross the re-whitespace boundary.

The style for Phobos is 4 space indentation, no tab characters anywhere, and LF line endings (to make github happy).
January 29, 2012
On 1/29/2012 10:53 AM, Denis Shelomovskij wrote:
> No, it isn't. Spaces aren't comfortable to use in existed editors.

Right, and I use tabs in my editor.

I also run all files through the tools:

   detab

to convert my tabs to spaces and:

   tolf

to convert to LF line endings before checkin. Works like a champ.
January 29, 2012
29.01.2012 23:02, Iain Buclaw пишет:
> On 29 January 2012 18:11, Denis Shelomovskij
> <verylonglogin.reg@gmail.com>  wrote:
>> 29.01.2012 18:09, Iain Buclaw пишет:
>>>
>>> On 29 January 2012 14:04, Denis Shelomovskij
>>> <verylonglogin.reg@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();
> }
>
>

Even worse, it still depends on editor - it can just add N to current position instead of moving to the next tab stop.

But in spite of everything I will quote my post:
>Looks the reason against tabs is: mixed tabs and spaces is bad. So we >should use spaces.
>Khm... Will it be in tab's favour if I rewrite the reason as "mixed >spaces and tabs is bad"?
January 29, 2012
On 01/29/2012 06:52 PM, Sean Cavanaugh wrote:
> On 1/29/2012 5:36 AM, Trass3r wrote:
>>> 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?
>>
>> Everyone thinks his way is the best.
>
> Thats because it is :)
>
>
>
> curley braces on the same line as conditionals is a refactoring landmine
> IMO
>
> I've never seen an editor that would enforce only leading characters on
> a line as tabs,

makefile-mode in GNU emacs highlights leading spaces and points out their existence on saving. But that is not the right behavior for all languages:

void main(){
\t  auto x = ["abcd",
\t  .........."defg",
\t  .......... ...
\t  .........];
}

> and until all of them do it, spaces is the only thing
> that makes sense to me, since they are never 'wrong'.
>

You mean invisibly wrong for some tab-settings.

void main(){
.int i;
..int j = 2;
...for(;i<j;i++){}
....return 0;
}

> The codebase I use at work is full of tabs and I can tolerate them, but
> not knowing how many times to hit backspace on some chunk of code
> containing whitespace in the middle of it is really annoying. Yes there
> is undo but it starts infringing on my flow (replacing zen with anger,
> the emperor would be pleased . . .)
>

That is an editor-specific problem. In my editor, hitting backspace always deletes one character (and converts the remaining portion of a tab to spaces).
January 29, 2012
30.01.2012 0:42, Walter Bright пишет:
> On 1/29/2012 6:17 AM, bearophile wrote:
>> D2 style guide should *require* D2 to be edited using a mono-spaced
>> font, and
>> the D2 front-end should enforce this with a "-ms" compiler switch.
>
> What? How could the compiler possibly know what font was used in your
> editor?

It's your compiler, Walter!

You should be more sensible and keep silence while people praise you instead of acknowledging your own feebleness.

More than that, people can use some piratical or even terrorist font to program in D and in our bright future you will answer in law (some modified SOPA, "Genuine Patriot Act" or smth. another).
January 29, 2012
29.01.2012 22:42, Walter Bright пишет:
> On 1/29/2012 6:17 AM, bearophile wrote:
>> D2 style guide should *require* D2 to be edited using a mono-spaced font, and
>> the D2 front-end should enforce this with a "-ms" compiler switch.
>
> What? How could the compiler possibly know what font was used in your editor?
>
This can be passed by user as a compiler switch, something like:
dmd -ms -font=Courier-i-swear srcfile.d
January 29, 2012
30.01.2012 0:53, Walter Bright пишет:
> On 1/29/2012 10:53 AM, Denis Shelomovskij wrote:
>> No, it isn't. Spaces aren't comfortable to use in existed editors.
>
> Right, and I use tabs in my editor.
>
> I also run all files through the tools:
>
> detab
>
> to convert my tabs to spaces
> ...
> Works like a champ.

I will be happy once I will find a working tool for reverse operation.

But yes, partially working one is enough for manual editing in the case everything will be converted to spaces at commit.

Thanks, an easy partial solution sometimes isn't obvious.
January 29, 2012
Am 29.01.2012, 21:20 Uhr, schrieb Timon Gehr <timon.gehr@gmx.ch>:

> On 01/29/2012 08:26 PM, Marco Leise wrote:
>> Am 29.01.2012, 16:23 Uhr, schrieb Trass3r <un@known.com>:
>>
>>>> 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.
>>>
>>> There wouldn't be any problem if people were able to use tabs for
>>> indentation and spaces for alignment, i.e. in cases like
>>> if (cond1 &&
>>> cond2)
>>>
>>> But people are dumb and many project leaders "take no risks" and
>>> require spaces everywhere instead of doing it properly.
>>
>> If it cheers you up, I use that style. Once you get used to 'smart tabs'
>> it is like using spaces. Just now and then I catch myself using tabs on
>> the alignment for local variable comments:
>>
>> int foo; // does something (tabs)
>> int bar; // something else (spaces)
>>
>> Then again "tabs for indentation only" is a simple rule, that would have
>> turned the tabs into spaces in this example - if editors supported it.
>
> *Real* editors can be configured to support smart tabs.

I sense a hint to some obscure Unix tool like vim or emacs.
January 29, 2012
Am 29.01.2012, 20:32 Uhr, schrieb Derek <ddparnell@bigpond.com>:

> On Mon, 30 Jan 2012 01:04:43 +1100, Denis Shelomovskij <verylonglogin.reg@gmail.com> wrote:
>
>> * Such tab using shows respect to a programmer allowing him to configure tab size as he prefer.
>
> This works ok for editors, but I can't work out how to configure my browser's tab-stops or the console's or printer's either for that matter. The issue is how to /display/ code in a reader-friendly manner.

If you are the web-master, you use the corresponding CSS3 attribute http://www.w3.org/TR/css3-text/#tab-size and make it configurable.
If you are the user, create a .css file with the following line, replacing 99 with the width in spaces you prefer:
* { -moz-tab-size: 99; -o-tab-size: 99; tab-size: 99; }

In Opera:
- Press Ctrl+F12 to open the settings dialog
- Select the 'Advanced' tab
- Click on 'Content' in the list to the left
- Click on the 'Style Options...' button
- Under 'My style sheet' browse to and select your .css file

FireFox:
http://www.tweakguides.com/Firefox_12.html

Chrome:
http://darcyclarke.me/design/skin-your-chrome-inspector/

Use some website like this one as a test: http://www.didihome.de/html/txt-tab.htm
January 29, 2012
On Sun, Jan 29, 2012 at 10:47:55PM +0400, Denis Shelomovskij wrote:
> 29.01.2012 22:07, Stewart Gordon пишет:
> >It is. But mishmashing tab and space indentation causes far worse conflict.
> >
> >Iain - I take it you meant that mishmashing, combined with users having different tab size settings, causes a problem. Correct?
> >
> >Stewart.
> 
> Looks the reason against tabs is: mixed tabs and spaces is bad. So we should use spaces.
[...]

My opinion is that there is no problem if you indent with tabs, with spaces only added to the end of the run of tabs if necessary. Comments and code never mix on the same line.  This way, no matter what how wide you set your tab stops to, things will always line up correctly.

(Sadly I don't follow this rule 100% of the time...)


T

-- 
Без труда не выловишь и рыбку из пруда.