January 29, 2012
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.
Khm... Will it be in tab's favour if I rewrite the reason as "mixed spaces and tabs is bad"?
January 29, 2012
On Sunday, 29 January 2012 at 16:48:18 UTC, bearophile wrote:
> Stewart Gordon:
>
>> What do you mean by the "D2 front-end"?
>
> It was one of my first attempts at humor :-)
>
> Bye and sorry,
> bearophile

Don't worry I had a good laugh.
January 29, 2012
29.01.2012 21:29, Russel Winder пишет:
> On Sun, 2012-01-29 at 14:09 +0000, Iain Buclaw wrote:
> [...]
>> 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?
>
> Isn't that the whole point:  using spaces causes conflict over
> indentation, using tabs, 1 per indent level, allows individuals to
> choose their indent level.
>

No, it isn't. Spaces aren't comfortable to use in existed editors. In spite of the fact that they provide a lot of support for N spaces to behave like a tab. And it unnecessary complicates editors (they can implement something more useful instead, like elastic tabstops from Trass3r's post).
January 29, 2012
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();
}


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';
January 29, 2012
Am 29.01.2012, 12:43 Uhr, schrieb Jonathan M Davis <jmdavisProg@gmx.com>:

> On Sunday, January 29, 2012 12:34:22 Gour wrote:
>> On Sun, 29 Jan 2012 12:21:35 +0100
>>
>> Alex Rønne Petersen <xtzgzorex@gmail.com> wrote:
>> > Phobos generally uses 4-space indentation.
>>
>> That is mentioned in the style-guide, but I'm curious about bracing,
>> iow, GNUstyle, K&R, ANSI...?
>
> Phobos uses Allman: http://en.wikipedia.org/wiki/Indent_style#Allman_style
>
> But everyone is free to format their code how they like. Personally, I've
> never understood how anyone can stand anything other than Allman, but to each
> their own, I suppose.
>
> - Jonathan M Davis

I have 31 visible lines of code in Eclipse, I need to conserve some space. Otherwise I like that style and use it for top-level struct/class declarations.
January 29, 2012
Manfred Nowak wrote:
> deadalnix wrote:
> 
>> I would say that the most important is to be consistent accros a project
> 
> If it is indead important, then the project shoud have a tool that can enforce that style. And every coder should have a tool that enforces her/his indiviuell style, if she/he cannot cope with that style.
> 
> Ever heard of any one having such a tool?
> 
> -manfred

	http://uncrustify.sourceforge.net/

	It even supports D...

		Jerome
-- 
mailto:jeberger@free.fr
http://jeberger.free.fr
Jabber: jeberger@jabber.fr



January 29, 2012
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.
January 29, 2012
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.

-- 
Derek Parnell
Melbourne, Australia
January 29, 2012
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.
January 29, 2012
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?