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