www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - indent style for D

reply Gour <gour atmarama.net> writes:
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

--=20
What is night for all beings is the time of awakening=20
for the self-controlled; and the time of awakening for=20
all beings is night for the introspective sage.

http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Jan 29 2012
next sibling parent reply =?ISO-8859-1?Q?Alex_R=F8nne_Petersen?= <xtzgzorex gmail.com> writes:
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. -- - Alex
Jan 29 2012
next sibling parent reply Gour <gour atmarama.net> writes:
On Sun, 29 Jan 2012 12:21:35 +0100
Alex R=C3=B8nne 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...? Sincerely, Gour --=20 The working senses are superior to dull matter; mind is higher=20 than the senses; intelligence is still higher than the mind;=20 and he [the soul] is even higher than the intelligence. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810
Jan 29 2012
next sibling parent Trass3r <un known.com> writes:
Am 29.01.2012, 12:34 Uhr, schrieb Gour <gour atmarama.net>:

 On Sun, 29 Jan 2012 12:21:35 +0100
 Alex R=C3=B8nne 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...?
Some people seem to use that godawful BSD KNF style. But I've also seen lots of Allman (ANSI)-style code.
Jan 29 2012
prev sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, January 29, 2012 12:34:22 Gour wrote:
 On Sun, 29 Jan 2012 12:21:35 +0100
=20
 Alex R=C3=B8nne Petersen <xtzgzorex gmail.com> wrote:
 Phobos generally uses 4-space indentation.
=20 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_st= yle But everyone is free to format their code how they like. Personally, I'= ve=20 never understood how anyone can stand anything other than Allman, but t= o each=20 their own, I suppose. - Jonathan M Davis
Jan 29 2012
next sibling parent reply "Trass3r" <un known.com> writes:
 Personally, I've never understood how anyone can stand anything 
 other than Allman.
Totally agree.
Jan 29 2012
parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 01/29/2012 06:54 AM, Trass3r wrote:
 Personally, I've never understood how anyone can stand anything other
 than Allman.
Totally agree.
Well, people adapt and values change. :) I've always used Allman style (although learning its name just now), until I started to work at my current job more than 4 years ago. We use a modified 1TBS by adding an extra empty line before the else: if (x < 0) { puts("Negative"); negative(x); // <-- added } else { puts("Non-negative"); nonnegative(x); } I know there isn't one perfect style, but to me, that's the most recognizable one. Of course I can rationalize it too. :) Ali
Jan 29 2012
prev sibling parent "Marco Leise" <Marco.Leise gmx.de> writes:
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=C3=B8nne 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 spac= e. = Otherwise I like that style and use it for top-level struct/class = declarations.
Jan 29 2012
prev sibling parent reply Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
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.
Jan 29 2012
next sibling parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On 29 January 2012 14:04, Denis Shelomovskij
<verylonglogin.reg gmail.com> wrote:
 29.01.2012 15:21, Alex R=C3=B8nne Petersen =D0=BF=D0=B8=D1=88=D0=B5=D1=82=
:
 On 29-01-2012 10:15, Gour wrote:
 Hello!

 It was mentioned in #D that gdc will probably adapt its code to GNU cod=
e
 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 t=
he
 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, l=
ets
 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? --=20 Iain Buclaw *(p < e ? p++ : p) =3D (c & 0x0f) + '0';
Jan 29 2012
parent reply Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
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)
Jan 29 2012
parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On 29 January 2012 18:11, Denis Shelomovskij
<verylonglogin.reg gmail.com> wrote:
 29.01.2012 18:09, Iain Buclaw =D0=BF=D0=B8=D1=88=D0=B5=D1=82:
 On 29 January 2012 14:04, Denis Shelomovskij
 <verylonglogin.reg gmail.com> =C2=A0wrote:
 29.01.2012 15:21, Alex R=C3=B8nne Petersen =D0=BF=D0=B8=D1=88=D0=B5=D1=
=82:
 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 practic=
e
 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 Phob=
os
 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 configur=
e
 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 i=
t
 is
 the simplest and not the most convenient way, the code should look _goo=
d
 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 u=
se
 (at least because spaces allows caret position in the middle of indenti=
on
 and pressing<one of delete one char keys> =C2=A0deletes one space inste=
ad 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.or=
g
 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 h=
ad
 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, n=
ot
 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=3D4;' { test(); test2(); test3(); } tabstop=3D3; { test1(); test2(); test3(); } tabstop=3D2; { test1(); test2(); test3(); } tabstop=3D1; { test1(); test2(); test3(); } --=20 Iain Buclaw *(p < e ? p++ : p) =3D (c & 0x0f) + '0';
Jan 29 2012
parent Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
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"?
Jan 29 2012
prev sibling next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Denis Shelomovskij:

 Am I mistaken? If no, am I missing some major spaces advantages? If no, 
 lets use tabs.
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. Bye, bearophile
Jan 29 2012
next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 29/01/2012 14:17, bearophile wrote:
 Denis Shelomovskij:

 Am I mistaken? If no, am I missing some major spaces advantages? If no,
 lets use tabs.
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 do you mean by the "D2 front-end"? The compiler front-end, or some IDE? If you're talking about the compiler, how will it determine what font was set in the program used to edit the file? Are you planning to make this work even if the file has been edited in more than one editor and/or font over the course of time? If you mean an IDE, what use would a compiler switch be? Just set up the font selection UI to allow only monospaced fonts to be selected. In Windows at least, the font common dialog has a flag to do this. Stewart.
Jan 29 2012
parent reply bearophile <bearophileHUGS lycos.com> writes:
Stewart Gordon:

 What do you mean by the "D2 front-end"?
It was one of my first attempts at humor :-) Bye and sorry, bearophile
Jan 29 2012
next sibling parent Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
29.01.2012 20:48, bearophile ïèøåò:
 Stewart Gordon:

 What do you mean by the "D2 front-end"?
It was one of my first attempts at humor :-) Bye and sorry, bearophile
Thanks for explicitly defining that! You just saved a lot of my time. )
Jan 29 2012
prev sibling parent "Jesse Phillips" <jessekphillips+D gmail.com> writes:
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.
Jan 29 2012
prev sibling next sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
On 29/01/2012 14:17, bearophile wrote:
 Denis Shelomovskij:

 Am I mistaken? If no, am I missing some major spaces advantages? If no,
 lets use tabs.
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 do you mean by the "D2 front-end"? The compiler front-end, or some IDE? If you're talking about the compiler, how will it determine what font was set in the program used to edit the file? Are you planning to make this work even if the file has been edited in more than one editor and/or font over the course of time? If you mean an IDE, what use would a compiler switch be? Just set up the font selection UI to allow only monospaced fonts to be selected. In Windows at least, the font common dialog has a flag to do this. Stewart.
Jan 29 2012
prev sibling next sibling parent Russel Winder <russel russel.org.uk> writes:
On Sun, 2012-01-29 at 09:17 -0500, bearophile wrote:
 Denis Shelomovskij:
=20
 Am I mistaken? If no, am I missing some major spaces advantages? If no,=
=20
 lets use tabs.
=20 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. Surely this is a level of fascism too far (*). Using monospace fonts is just so 1960s, the era of typewriters and 80x25 terminals. Personally I am living in an era where monitors deal with proportional fonts which every experiment done shows are easier to read. Why do so many programmers hanker for the 1960s and the necessity of monospace fonts, it seems irrational. (*) Go imposes these sorts of rules, well at least brace placement and indentation levels, and it really irritates. =20 --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Jan 29 2012
prev sibling next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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?
Jan 29 2012
next sibling parent Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
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).
Jan 29 2012
prev sibling next sibling parent Mantis <mail.mantis.88 gmail.com> writes:
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
Jan 29 2012
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter:

 What? How could the compiler possibly know what font was used in your editor?
Sorry Walter, this time I wasn't serious :-) Bye, bearophile
Jan 29 2012
parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/29/2012 2:44 PM, bearophile wrote:
 Walter:
 What? How could the compiler possibly know what font was used in your editor?
Sorry Walter, this time I wasn't serious :-)
All I can say is, I'm glad. That was a heluva WTF!
Jan 29 2012
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Jan 29, 2012 at 05:33:39PM +0000, Russel Winder wrote:
 On Sun, 2012-01-29 at 09:17 -0500, 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.
Surely this is a level of fascism too far (*). Using monospace fonts is just so 1960s, the era of typewriters and 80x25 terminals.
I always code with tab stops set to 8 and line wrapping set to 80 columns.
 Personally I am living in an era where monitors deal with proportional
 fonts which every experiment done shows are easier to read.
*Text* is easier to read with proportional fonts. Code is not the same as text.
 Why do so many programmers hanker for the 1960s and the necessity of
 monospace fonts, it seems irrational.
I am irrational. ;-) T -- I am a consultant. My job is to make your job redundant. -- Mr Tom
Jan 29 2012
next sibling parent "Kagamin" <spam here.lot> writes:
On Sunday, 29 January 2012 at 22:25:57 UTC, H. S. Teoh wrote:
 *Text* is easier to read with proportional fonts. Code is not 
 the same
 as text.
Tried many monospaced fonts, none is more readable than verdana.
Jan 29 2012
prev sibling parent =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 01/29/2012 02:27 PM, H. S. Teoh wrote:

 Why do so many programmers hanker for the 1960s and the necessity of
 monospace fonts, it seems irrational.
I am irrational. ;-)
Proudly, me too! I want to look at monospaced code with to tabs anywhere in it; and since I like what came out of the 1960s, 80 columns for me! :) Ali
Jan 29 2012
prev sibling next sibling parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On 29 January 2012 14:17, bearophile <bearophileHUGS lycos.com> wrote:
 Denis Shelomovskij:

 Am I mistaken? If no, am I missing some major spaces advantages? If no,
 lets use tabs.
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. Bye, bearophile
I think D should go even further than that and drop those horrid curly braces, handling all code blocks by indentation. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Jan 29 2012
parent reply Sean Cavanaugh <WorksOnMyMachine gmail.com> writes:
On 1/29/2012 5:03 PM, Iain Buclaw wrote:
 On 29 January 2012 14:17, bearophile<bearophileHUGS lycos.com>  wrote:
 Denis Shelomovskij:

 Am I mistaken? If no, am I missing some major spaces advantages? If no,
 lets use tabs.
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. Bye, bearophile
I think D should go even further than that and drop those horrid curly braces, handling all code blocks by indentation.
There are huge swaths of unused unicode values, including a rather large chunk reserved for custom user-implementation. Clearly we need to redesign the language to use custom symbols that make sense, instead of the archaic typesetting symbols we use now and have a unique set of programmer symbols. We can even solve the space vs tab problem once and for all, by making a whitespace key and removing the obsolete buttons to make room for all the new ones (which would be tab, spacebar, and enter).
Jan 29 2012
next sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
On 30/01/2012 01:13, Sean Cavanaugh wrote:
<snip>
 Clearly we need to redesign the language to use custom symbols that make
sense, instead of
 the archaic typesetting symbols we use now and have a unique set of programmer
symbols.
It's already been tried (APL). OK, so maybe the "that make sense" aspect doesn't apply there.
 We can even solve the space vs tab problem once and for all, by making a
whitespace key
 and removing the obsolete buttons to make room for all the new ones (which
would be tab,
 spacebar, and enter).
Having to switch keyboards might have been another reason people hated APL. Stewart.
Jan 29 2012
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Jan 29, 2012 at 07:13:14PM -0600, Sean Cavanaugh wrote:
[...]
 There are huge swaths of unused unicode values, including a rather
 large chunk reserved for custom user-implementation.
 
 Clearly we need to redesign the language to use custom symbols that
 make sense, instead of the archaic typesetting symbols we use now and
 have a unique set of programmer symbols.
[...] Why bother with custom symbols? Unicode already gives us entire ranges of mathematical and technical symbols that we could use to our hearts' content. For example, I would love to have new matching pairs of delimiters, such as «» that we could use for, say, template parameters, instead of uglinessess like !. And I'd love to have my integer set class be able to use ∪ and ∩ instead of verbose operations like x.union(y) and x.intersection(y). For that matter, most function names can be reduced to single symbols like ⌹. And we can rename D2 to APL2. ;-) T -- Tell me and I forget. Teach me and I remember. Involve me and I understand. -- Benjamin Franklin
Jan 29 2012
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 30/01/2012 02:24, H. S. Teoh wrote:
<snip>
 And I'd love to have my integer set class
 be able to use ∪ and ∩ instead of verbose operations like x.union(y) and
 x.intersection(y).
<snip> My utility library uses | and &. Think of the possible values of the type you're creating a set of as being like the bits of a number, and then it makes sense. Stewart.
Jan 30 2012
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Jan 31, 2012 at 02:43:57AM +0000, Stewart Gordon wrote:
 On 30/01/2012 02:24, H. S. Teoh wrote:
 <snip>
And I'd love to have my integer set class
be able to use ∪ and ∩ instead of verbose operations like x.union(y) and
x.intersection(y).
<snip> My utility library uses | and &. Think of the possible values of the type you're creating a set of as being like the bits of a number, and then it makes sense.
[...] Funny you should mention that; my integer set class represents set members as bits, and set operations are implemented as bitwise operations. :) Still, though, it'd be nice to have actual set notation. But I was only being half-serious. T -- BREAKFAST.COM halted...Cereal Port Not Responding. -- YHL
Jan 30 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Jan 29, 2012 at 11:03:54PM +0000, Iain Buclaw wrote:
[...]
 I think D should go even further than that and drop those horrid curly
 braces, handling all code blocks by indentation.
[...] Yeah, that way D will have much less competition to succeed (only have to beat Python instead of out-competing thousands of other languages). ;-) T -- One reason that few people are aware there are programs running the internet is that they never crash in any significant way: the free software underlying the internet is reliable to the point of invisibility. -- Glyn Moody, from the article "Giving it all away"
Jan 29 2012
prev sibling parent Artur Skawina <art.08.09 gmail.com> writes:
On 01/30/12 00:03, Iain Buclaw wrote:
 On 29 January 2012 14:17, bearophile <bearophileHUGS lycos.com> wrote:
 Denis Shelomovskij:

 Am I mistaken? If no, am I missing some major spaces advantages? If no,
 lets use tabs.
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. Bye, bearophile
I think D should go even further than that and drop those horrid curly braces, handling all code blocks by indentation.
http://delight.sourceforge.net/ I was going to suggest making the compiler enforce using black-on-white, instead of white-on-black, for all D soure code, but was afraid somebody would still not get it... :) artur
Jan 29 2012
prev sibling next sibling parent reply "Daniel Murphy" <yebblies nospamgmail.com> writes:
http://media.comicvine.com/uploads/6/67698/1595201-oh_look_its_this_th
ead_again_super.jpg 
Jan 29 2012
parent "a" <a a.com> writes:
On Sunday, 29 January 2012 at 14:42:16 UTC, Daniel Murphy wrote:
 http://media.comicvine.com/uploads/6/67698/1595201-oh_look_its_this_thread_again_super.jpg
That's nothing. If you want to see a truly great bikeshedding thread, go there: http://www.reddit.com/r/programming/comments/p1j1c/tabs_vs_spaces_vs_both/
Jan 29 2012
prev sibling next sibling parent reply "Trass3r" <un known.com> writes:
 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. An ever better solution is elastic tabstops, but unfortunately no major editor supports that.
Jan 29 2012
next sibling parent reply David <d dav1d.de> writes:
Am 29.01.2012 16:23, schrieb Trass3r:
 But people are dumb and many project leaders "take no risks" and require
 spaces everywhere instead of doing it properly.

 An ever better solution is elastic tabstops, but unfortunately no major
 editor supports that.
Where's the problem, you can configure most editors to insert N-spaces when pressing the tab-key. Some editors are so smart enough to handle the N-spaces still as tabs but save them as spaces.
Jan 29 2012
next sibling parent deadalnix <deadalnix gmail.com> writes:
Le 29/01/2012 16:39, David a écrit :
 Am 29.01.2012 16:23, schrieb Trass3r:
 But people are dumb and many project leaders "take no risks" and require
 spaces everywhere instead of doing it properly.

 An ever better solution is elastic tabstops, but unfortunately no major
 editor supports that.
Where's the problem, you can configure most editors to insert N-spaces when pressing the tab-key. Some editors are so smart enough to handle the N-spaces still as tabs but save them as spaces.
So, the point is saving spaces and programing many many tricks in the editor to make spaces behave like tabs. I don't see the point of it. It is just like you were asking for a 4 wheeled motobike with a roof and 5 sits because you don't want a car.
Jan 29 2012
prev sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
On 29/01/2012 15:39, David wrote:
 Am 29.01.2012 16:23, schrieb Trass3r:
 But people are dumb and many project leaders "take no risks" and require
 spaces everywhere instead of doing it properly.

 An ever better solution is elastic tabstops, but unfortunately no major
 editor supports that.
Where's the problem, you can configure most editors to insert N-spaces when pressing the tab-key. Some editors are so smart enough to handle the N-spaces still as tabs but save them as spaces.
Some editors (Notepad++ included), when configured to do tabs as spaces, only insert _new_ tabs as spaces and leave existing tabs as they are. And when configured do to tabs as tabs, leave existing space indentation alone. And sometimes even more annoyingly, convert spaces to tabs when you block indent/outdent or start a new line. This leads to files that multiple people have worked on being indented with a mishmash of tabs and spaces. Much better would be to: - Preserve the sequence of spaces and tabs when you block indent/outdent - When you insert a line break, copy the sequence of spaces and tabs onto the new line - When you type a tab preceded by only tabs, insert a tab - When you type a tab preceded by characters other than tabs, insert spaces - Attempt to detect the indentation style when opening a file and then follow it - Provide commands to convert tabs to/from spaces separately from block indent/outdent Stewart.
Jan 29 2012
prev sibling parent reply "Marco Leise" <Marco.Leise gmx.de> writes:
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.
Jan 29 2012
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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.
Jan 29 2012
next sibling parent "Marco Leise" <Marco.Leise gmx.de> writes:
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.
Jan 29 2012
prev sibling parent Zardoz <luis.panadero gmail.com> writes:
On Sun, 29 Jan 2012 21:20:01 +0100, Timon Gehr wrote:

 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.
So a butterfly. -- Yep, I'm afraid that I have a blog : zardoz.es
Jan 31 2012
prev sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
On 29/01/2012 19:26, Marco Leise wrote:
<snip>
 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.
But when alignment spaces begin at the beginning of the line, or immediately after the indentation tabs, they can easily be mistaken by editors for indentation and changed to tabs. It depends on how intelligent the software is. void qwert(int yuiop, string asdfg, immutable(int)[] hjkl, Object zxcvb) Here, the lines of parameters are aligned. However, a naive editor might mistake the alignment spaces for indentation spaces and turn them into tabs. void qwert(int yuiop, string asdfg, immutable(int)[] hjkl, Object zxcvb) Here, there is a fixed indentation. But one possibility for editors is to work on the principle that it's an indentation tab/run of spaces iff the syntactic structure ({}, control statements with a single statement as body, possibility [] used for array initialisers) dictates that there should be an indentation tab there. While not perfect, it would still IMO be better than the current mess many editors are in. Stewart.
Jan 29 2012
prev sibling next sibling parent reply Russel Winder <russel russel.org.uk> writes:
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. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Jan 29 2012
next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
On 29/01/2012 17:29, Russel Winder wrote:
 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.
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.
Jan 29 2012
next sibling parent Russel Winder <russel russel.org.uk> writes:
On Sun, 2012-01-29 at 18:07 +0000, Stewart Gordon wrote:
[...]
 It is.  But mishmashing tab and space indentation causes far worse confli=
ct. Agreed -- homogeneity of the character used for spacing, especially indentation, is critical . I think this is why Emacs (*) has a way of converting all leading whitespace to either tabs or spaces. (*) The only one true editor (and kitchen sink). --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Jan 29 2012
prev sibling parent reply Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
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"?
Jan 29 2012
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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 -- Без труда не выловишь и рыбку из пруда.
Jan 29 2012
prev sibling parent reply Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
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).
Jan 29 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Jan 29 2012
next sibling parent Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
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.
Jan 29 2012
prev sibling parent reply "Kagamin" <spam here.lot> writes:
On Sunday, 29 January 2012 at 20:53:51 UTC, Walter Bright wrote:
   tolf
AFAIK, only windows notepad can't handle lf nowadays. That's it?
Jan 29 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/29/2012 2:41 PM, Kagamin wrote:
 On Sunday, 29 January 2012 at 20:53:51 UTC, Walter Bright wrote:
 tolf
AFAIK, only windows notepad can't handle lf nowadays. That's it?
So far, I've seen no issues with standardizing on LF line endings.
Jan 29 2012
parent "Kagamin" <spam here.lot> writes:
On Monday, 30 January 2012 at 01:45:40 UTC, Walter Bright wrote:
 On 1/29/2012 2:41 PM, Kagamin wrote:
 On Sunday, 29 January 2012 at 20:53:51 UTC, Walter Bright 
 wrote:
 tolf
AFAIK, only windows notepad can't handle lf nowadays. That's it?
So far, I've seen no issues with standardizing on LF line endings.
Ermm... I mean, if you use tolf, then your editor uses something else? I guessed what is this editor.
Jan 29 2012
prev sibling next sibling parent reply Derek <ddparnell bigpond.com> writes:
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
Jan 29 2012
parent "Marco Leise" <Marco.Leise gmx.de> writes:
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
Jan 29 2012
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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).
Jan 29 2012
parent reply Denis Shelomovskij <verylonglogin.reg gmail.com> writes:
30.01.2012 0:49, Walter Bright пишет:
 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).
OK, the major advantage of spaces is because my approach (tabs for indention, spaces for alignment) isn't testable by a tool that doesn't know D semantics. More than that, my approach isn't a full solution too. It's outdated like spaces because of elastic tabstops. By the way, elastic tabstops looks easy auto-testable too so once we will just migrate to it (I hope). But the current situation is still unpleasant because: * There are no suggestions of using some tools for developers to automate conversion, so there is already a wasting of our time (developers and commit reviewers/mergers). * Look's like nobody ever tested Phobos files for tabs. P.S. I started this thread because of wasting my time for conversion/checking and inconsistent situation: druntime/Phobos have both spaces/tabs now (yes, there are significantly more spaces, but it doesn't reduce the problem), e.g. you just broke formatting in std/stream.d: https://github.com/D-Programming-Language/phobos/commit/f3aa58592faed9a418e347090cd614670947fef4
Jan 30 2012
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/30/2012 2:16 AM, Denis Shelomovskij wrote:
 P.S.
 I started this thread because of wasting my time for conversion/checking and
 inconsistent situation: druntime/Phobos have both spaces/tabs now (yes, there
 are significantly more spaces, but it doesn't reduce the problem), e.g. you
just
 broke formatting in std/stream.d:
 https://github.com/D-Programming-Language/phobos/commit/f3aa58592faed9a418e347090cd614670947fef4
Problems crop up when people check in stuff with tabs in it. I run everything I check in through detab.
Jan 30 2012
prev sibling parent "Kagamin" <spam here.lot> writes:
On Monday, 30 January 2012 at 10:16:36 UTC, Denis Shelomovskij 
wrote:
 I started this thread
Poor topicstarter. His topic is hijacked and buried if flame, and he himself is sent to oblivion.
Jan 30 2012
prev sibling next sibling parent reply Trass3r <un known.com> writes:
 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.
Jan 29 2012
next sibling parent reply deadalnix <deadalnix gmail.com> writes:
Le 29/01/2012 12:36, Trass3r a écrit :
 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.
I would say that the most important is to be consistent accros a project or a code base. The style in itself, execpt for some special tricky case doesn't change a lot.
Jan 29 2012
parent reply Manfred Nowak <svv1999 hotmail.com> writes:
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
Jan 29 2012
next sibling parent Mirko Pilger <mirko.pilger gmail.com> writes:
 Ever heard of any one having such a tool?
http://golang.org/cmd/gofmt/
Jan 29 2012
prev sibling parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Manfred Nowak wrote:
 deadalnix wrote:
=20
 I would say that the most important is to be consistent accros a
 project=20
=20 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=20
 her/his indiviuell style, if she/he cannot cope with that style.
=20
 Ever heard of any one having such a tool?
=20
 -manfred
http://uncrustify.sourceforge.net/ It even supports D... Jerome --=20 mailto:jeberger free.fr http://jeberger.free.fr Jabber: jeberger jabber.fr
Jan 29 2012
prev sibling next sibling parent reply Sean Cavanaugh <WorksOnMyMachine gmail.com> writes:
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, and until all of them do it, spaces is the only thing that makes sense to me, since they are never 'wrong'. 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 . . .)
Jan 29 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
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).
Jan 29 2012
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Jan 29, 2012 at 12:36:18PM +0100, 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.
You know, I'm starting to take seriously bearophile's (I think it was him?) half-joking proposal that all code must be written on a single line, and whatever editor/IDE/what-have-you that you use to code will pretty-print everything for you. That way, everyone will see the code in their own favorite style, and nobody will have pointless flamewars over this subject ever again (thereby giving more time for more important things, such as vim vs. emacs flamewars :P). I mean, if you think about it, at the most fundamental level, whether you use spaces or tabs or what-not, it's all *visual formatting* done in a format that's essentially conveying *semantic information* to the compiler. It's just like the <font> tag in HTML (that we finally got rid of after years of pain). And let's face it. A space character is intended to represent an inter-word space. It's not supposed to represent *indentation*. That privilege is reserved for the tab character. But unfortunately there is no consensus on how wide a tab is supposed to be. But all of this is missing the point. Code is essentially a tree-structured thing, consisting of nested blocks. Why should we use ill-suited representations as tabs and spaces for nesting blocks? There should be a dedicated code-editor (or vim/emacs mode, or IDE configuration, or whatever), that parses the damn code and displays the nesting structure in whatever way the user wants to see it. Whether you want to see your blocks like this: if (a < b) { a = b; } else { b = a; } or if (a < b) { a = b; } else { b = a; } or even if (a < b) { a = b; } else { b = a } or worse: if (a < b) { a = b; } else { b = a; } (I kid you not, I know at least one person who actually writes code like that) ... really shouldn't require painful reformatting of the entire source code. You should be able to load a "style sheet" into your editor that automatically parses the code and pretty-prints (or ugly-prints) it in your favorite style. And not only so, when you type, it automatically formats blocks for you with no further effort. You type "if(a<b){" and it automatically inserts newlines and indents, AND if you hit backspace, it doesn't "erase the tab character" or such nonsense; it removes the current block and moves your cursor back to the end of the "if(a<b)" line. Plus, it automatically inserts spaces after the "if" and around the "<" if your stylesheet specifies so. IOW, you should be able to type your code with absolutely no spaces except where necessary to separate tokens, and the editor should format it appropriately. It should be *impossible* to do any manual formatting whatsoever. The editor should take full responsibility for that. AND if you send your code to somebody else, they will always see it in their own favorite style. Furthermore, moving formatting to the editor will FINALLY let you handle side-by-side comments in a sane way. The editor can display code in two columns, one for code, and one for comments associated with each line of code. You can collapse/expand comments as necessary, or change the widths of the columns, and the editor automatically positions everything correctly (including line-wrapping and paragraph formatting for long comments). The editor takes full responsibility for how to represent comments in the file. There will be dedicated keys for moving between code/comment columns, so that you can edit code freely and have the associated comments automatically flow around it. T -- "Uhh, I'm still not here." -- KD, while "away" on ICQ.
Jan 29 2012
next sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
H. S. Teoh:

 You know, I'm starting to take seriously bearophile's (I think it was
 him?) half-joking proposal that all code must be written on a single
 line,
It wasn't me. Bye, bearophile
Jan 29 2012
next sibling parent Matej Nanut <matejnanut gmail.com> writes:
I like the look of 8-space indents, but I don't see how I could pull
it off if I use object-oriented features. I use 8-space indents if I
code C, and it seems to work really well. But when you have a class,
and then maybe even an inner class, you practically start with 2
levels of indentation, and that's where half your "page" (screen) is
blank space!

What is a solution to this, apart from using 4-space indentation? To
not indent class declarations is kinda one.
Jan 29 2012
prev sibling parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On 29 January 2012 23:30, Matej Nanut <matejnanut gmail.com> wrote:
 I like the look of 8-space indents, but I don't see how I could pull
 it off if I use object-oriented features. I use 8-space indents if I
 code C, and it seems to work really well. But when you have a class,
 and then maybe even an inner class, you practically start with 2
 levels of indentation, and that's where half your "page" (screen) is
 blank space!

 What is a solution to this, apart from using 4-space indentation? To
 not indent class declarations is kinda one.
The answer to that is that if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program. :o) -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Jan 29 2012
parent deadalnix <deadalnix gmail.com> writes:
Le 30/01/2012 00:44, Iain Buclaw a écrit :
 On 29 January 2012 23:30, Matej Nanut<matejnanut gmail.com>  wrote:
 I like the look of 8-space indents, but I don't see how I could pull
 it off if I use object-oriented features. I use 8-space indents if I
 code C, and it seems to work really well. But when you have a class,
 and then maybe even an inner class, you practically start with 2
 levels of indentation, and that's where half your "page" (screen) is
 blank space!

 What is a solution to this, apart from using 4-space indentation? To
 not indent class declarations is kinda one.
The answer to that is that if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program. :o)
Well, not to mention that this sentence first apply to C. Because if you apply that in some programming languages, you'll be screwed up pretty quickly (even in D even if it isn't the worse at this game).
Jan 29 2012
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
More practical than requiring all source files to be saved without 
formatting:

- Upon opening a file, the editor looks for a style sheet in the same 
directory. If there is no such style sheet, it automatically deduces the 
style from the code, falling back to the local preferences.

- Then it acts as you propose.

- And when saving, it automatically formats the source code in the 
deduced format.
Jan 29 2012
next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Jan 30, 2012 at 01:57:43AM +0100, Timon Gehr wrote:
 More practical than requiring all source files to be saved without
 formatting:
 
 - Upon opening a file, the editor looks for a style sheet in the
 same directory. If there is no such style sheet, it automatically
 deduces the style from the code, falling back to the local
 preferences.
 
 - Then it acts as you propose.
 
 - And when saving, it automatically formats the source code in the
 deduced format.
The problem with autoformatting on save is that it interacts badly with revision control systems. You could end up with lots of noisy diffs mostly involving changes in whitespace. By enforcing a fixed formatting, whether it's everything-on-a-line or delete all unnecessary whitespace but leave newlines intact, you ensure that diffs generated by the revision control system will not include whitespace noise. T -- Debian GNU/Linux: Cray on your desktop.
Jan 29 2012
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 30 January 2012 03:27, H. S. Teoh <hsteoh quickfur.ath.cx> wrote:
 On Mon, Jan 30, 2012 at 01:57:43AM +0100, Timon Gehr wrote:
 More practical than requiring all source files to be saved without
 formatting:

 - Upon opening a file, the editor looks for a style sheet in the
 same directory. If there is no such style sheet, it automatically
 deduces the style from the code, falling back to the local
 preferences.

 - Then it acts as you propose.

 - And when saving, it automatically formats the source code in the
 deduced format.
The problem with autoformatting on save is that it interacts badly with revision control systems. You could end up with lots of noisy diffs mostly involving changes in whitespace. By enforcing a fixed formatting, whether it's everything-on-a-line or delete all unnecessary whitespace but leave newlines intact, you ensure that diffs generated by the revision control system will not include whitespace noise.
The flip side is that if you put everything on one line, no one will be able to understand the commits you make. :) -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Jan 29 2012
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Jan 30, 2012 at 03:35:03AM +0000, Iain Buclaw wrote:
 On 30 January 2012 03:27, H. S. Teoh <hsteoh quickfur.ath.cx> wrote:
 On Mon, Jan 30, 2012 at 01:57:43AM +0100, Timon Gehr wrote:
[...]
 - And when saving, it automatically formats the source code in the
 deduced format.
The problem with autoformatting on save is that it interacts badly with revision control systems. You could end up with lots of noisy diffs mostly involving changes in whitespace. By enforcing a fixed formatting, whether it's everything-on-a-line or delete all unnecessary whitespace but leave newlines intact, you ensure that diffs generated by the revision control system will not include whitespace noise.
The flip side is that if you put everything on one line, no one will be able to understand the commits you make. :)
[...] Well, that's no fault of mine; it's a relic of holding on to visually-formatted plaintext format. ;-) If all code was auto-formatted, you won't have this kind of problem, since the diff utility would compare syntax trees instead of lines, and would show you what *actually* changed syntactically. As opposed to diffs where inserting a new function with a similar body to the following adjacent function causes the diff to be a messy interlacing of lines from both functions, 'cos it's "shorter" than a diff which simply inserts the new function. (Which happens a lot with code that has lots of boilerplate. But boilerplates are another issue. :-)) T -- My program has no bugs! Only unintentional features...
Jan 29 2012
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, January 29, 2012 14:27:29 H. S. Teoh wrote:
 On Sun, Jan 29, 2012 at 05:33:39PM +0000, Russel Winder wrote:
 On Sun, 2012-01-29 at 09:17 -0500, 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.
Surely this is a level of fascism too far (*). Using monospace fonts is just so 1960s, the era of typewriters and 80x25 terminals.
I always code with tab stops set to 8 and line wrapping set to 80 columns.
That's not going to work very well with D. You tend to get far too many levels of indentation for that to fly. With static if (and potentiall multiple layers of static if), classes, templates, etc. all on top of the normal if statements and while loops and the like, and it can very quickly reach 3 - 4 indentation levels on simple code, let alone what more complex code has. It's that much worse when you use much in the way of functional-style programming and chain function calls, since then not are the lines indented a fair ways, but they tend to get long. I suspect that you'll find 8 character tabs and 80 character columns to be a frustrating combination, but you can do whatever you want. Phobos uses 4 character tabs with a soft limit of 80 characters (on average, a line should fit within 80 characters, but it doesn't have to) and a hard limit of 120 characters (a line should _never_ exceed 120 characters). And that seems to be working fairly well for us. - Jonathan M Davis
Jan 29 2012
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sun, Jan 29, 2012 at 02:32:48PM -0800, Jonathan M Davis wrote:
 On Sunday, January 29, 2012 14:27:29 H. S. Teoh wrote:
[...]
 I always code with tab stops set to 8 and line wrapping set to 80
 columns.
That's not going to work very well with D. You tend to get far too many levels of indentation for that to fly. With static if (and potentiall multiple layers of static if), classes, templates, etc. all on top of the normal if statements and while loops and the like, and it can very quickly reach 3 - 4 indentation levels on simple code, let alone what more complex code has. It's that much worse when you use much in the way of functional-style programming and chain function calls, since then not are the lines indented a fair ways, but they tend to get long. I suspect that you'll find 8 character tabs and 80 character columns to be a frustrating combination, but you can do whatever you want.
I used to use 2-space indentation for this very reason. I've written Perl code with 16 levels of nesting complete with chained maps{} and other such fun stuff. But I've since changed my mind, and have come to believe that if a function requires more than 3-4 levels of nesting, there is a fundamental design problem with it, and it should be split into smaller functions. This also helps you refactor code more easily as well as give you a reason to think about how to better express what you're trying to do, instead of just going on auto-pilot and using 8 levels of nesting just because. Optimizing compilers like gdc will auto-inline single-use functions anyway, so this shouldn't be a problem even on the premature optimization side. ;-) Besides, one of the things I really love about D is closures... with careful use of closures, almost any code can be reduced to 3-4 indents at the most, usually only 2-3.
 Phobos uses 4 character tabs with a soft limit of 80 characters (on
 average, a line should fit within 80 characters, but it doesn't have
 to) and a hard limit of 120 characters (a line should _never_ exceed
 120 characters). And that seems to be working fairly well for us.
[...] Well, having worked in many different projects under different managers with different coding styles at my full-time jobs, I've come to accept that when writing code for a particular project, one should simply follow whatever conventions existing code in that project uses, however ugly it may seem. For my own projects, though, I use 8-space tabs and 80-column wrapping. T -- 2+2=4. 2*2=4. 2^2=4. Therefore, +, *, and ^ are the same operation.
Jan 29 2012
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday, January 29, 2012 23:44:25 Iain Buclaw wrote:
 On 29 January 2012 23:30, Matej Nanut <matejnanut gmail.com> wrote:
 I like the look of 8-space indents, but I don't see how I could pull
 it off if I use object-oriented features. I use 8-space indents if I
 code C, and it seems to work really well. But when you have a class,
 and then maybe even an inner class, you practically start with 2
 levels of indentation, and that's where half your "page" (screen) is
 blank space!
 
 What is a solution to this, apart from using 4-space indentation? To
 not indent class declarations is kinda one.
The answer to that is that if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program. :o)
That doesn't hold for D. There are too many ways to legitimately end up with several levels of indentation. Templates, static ifs, version blocks, struct/class declarations, if/else, while, etc. 3 or 4 levels of indentation is not necessarily uncommon at all. C has so few things that result in new blocks to indent, that the 3 levels of indentation rule has some merit there. But in OO languages (and especially in D with its additional conditional compilation features), that just doesn't fly. - Jonathan M Davis
Jan 29 2012