On 29 January 2012 18:11, Denis Shelomovskij <verylonglogin....@gmail.com> wrote: > 29.01.2012 18:09, Iain Buclaw пишет: >> >> On 29 January 2012 14:04, Denis Shelomovskij >> <verylonglogin....@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';