www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Coding Standards

reply bearophile <bearophileHUGS lycos.com> writes:
Mark Chu-Carroll is a first class programmer and more. He's leaving Google and
writes about what's good in it. Here he explains in a very simple way why
coding standards are good:
http://scientopia.org/blogs/goodmath/2011/07/14/stuff-everyone-should-do-part-2-coding-standards/

He talks just about the coding standards of one firm, so he forgets to talk
about a related but in my opinion equally important point. If I take a look at
Delphi code, C code, C++ code, I see everything, every coding style, naming
convention, and many other differences, that make me harder to read and
understand their code.

If I take a look at Python code written by ten different people I see much more
uniformity. This uniformity is part of the Python culture, its PEP8
http://www.python.org/dev/peps/pep-0008/ ) is a coding standard that instead of
being just Google-wide is language-wide. This allows me to understand Python
code in less time, to copy and use functions, classes, modules, packages and

is intermediate. I see more uniformity compared to C++ code, but less than
Python code).

Go language even comes with a source code formatter that is used often to
format code. I think they have learnt well that Google lesson :-)

Even Scala seems about to do something similar:
http://drdobbs.com/article/print?articleId=231001802&siteSectionName=

Bye,
bearophile
Jul 14 2011
next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
I'm fine with any coding standard. As long as it tells everyone
else to follow my lead :)
Jul 14 2011
prev sibling next sibling parent Caligo <iteronvexor gmail.com> writes:
On Thu, Jul 14, 2011 at 6:11 PM, bearophile <bearophileHUGS lycos.com> wrot=
e:

 Mark Chu-Carroll is a first class programmer and more. He's leaving Googl=


e and writes about what's good in it. Here he explains in a very simple way=
 why coding standards are good:

 http://scientopia.org/blogs/goodmath/2011/07/14/stuff-everyone-should-do-=


part-2-coding-standards/

 He talks just about the coding standards of one firm, so he forgets to ta=


lk about a related but in my opinion equally important point. If I take a l=
ook at Delphi code, C code, C++ code, I see everything, every coding style,=
 naming convention, and many other differences, that make me harder to read=
 and understand their code.

 If I take a look at Python code written by ten different people I see muc=


h more uniformity. This uniformity is part of the Python culture, its PEP8 =
http://www.python.org/dev/peps/pep-0008/ ) is a coding standard that instea=
d of being just Google-wide is language-wide. This allows me to understand =
Python code in less time, to copy and use functions, classes, modules, pack=

he situation is intermediate. I see more uniformity compared to C++ code, b=
ut less than Python code).

 Go language even comes with a source code formatter that is used often to=


 format code. I think they have learnt well that Google lesson :-)

 Even Scala seems about to do something similar:
 http://drdobbs.com/article/print?articleId=3D231001802&siteSectionName=3D

 Bye,
 bearophile



I definitely agree.  I like the uniformity in Python code, and I wish
we had coding standards for D.  Maybe we could formalize one?
Jul 14 2011
prev sibling next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On 2011-07-14 16:11, bearophile wrote:

 Mark Chu-Carroll is a first class programmer and more. He's leaving Google
 and writes about what's good in it. Here he explains in a very simple way
 why coding standards are good:
 http://scientopia.org/blogs/goodmath/2011/07/14/stuff-everyone-should-do-p
 art-2-coding-standards/
 
 He talks just about the coding standards of one firm, so he forgets to talk
 about a related but in my opinion equally important point. If I take a
 look at Delphi code, C code, C++ code, I see everything, every coding
 style, naming convention, and many other differences, that make me harder
 to read and understand their code.
 
 If I take a look at Python code written by ten different people I see much
 more uniformity. This uniformity is part of the Python culture, its PEP8
 http://www.python.org/dev/peps/pep-0008/ ) is a coding standard that
 instead of being just Google-wide is language-wide. This allows me to
 understand Python code in less time, to copy and use functions, classes,
 modules, packages and libraries written by other people and use them in my

 to C++ code, but less than Python code).
 
 Go language even comes with a source code formatter that is used often to
 format code. I think they have learnt well that Google lesson :-)
 
 Even Scala seems about to do something similar:
 http://drdobbs.com/article/print?articleId=231001802&siteSectionName=


We have a basic coding standard up on the site (which does need some 
updating), but it primarily covers stuff like naming conventions. There is _no 
way_ that you're going to get even the Phobos developers to completely agree 
on a coding standard if you want to start requiring stuff like whether there 
are spaces around parens or not. About the only requirement that we have along 
those lines is that braces should be on their own line (aside from stuff like 
lambdas). There was enough arguing over line length limit (we finall settled 
on a hard limit of 120 with a soft limit of 80). No one wants to be forced to 
format their code in a certain way. Phobos is reasonably uniform as far as 
general formatting goes, but even it has a fair bit of variance in the exact 
formatting.

I keep meaning to update the standard online to match what we're actually 
doing in Phobos (and include separately the small number of items which are 
specific to Phobos but would not be a general standard - e.g. the line length 
limit). And D could should generally follow that, but it's primarily a naming 
standard, not a formatting standard.

Personally, I do _not_ want to see any kind of official coding standard which 
tries to regulate formatting. Invariably, it comes down to personal 
preference, and no one can agree. Python manages such uniformity at least in 
part because the language rules with regards to whitespace are inflexible 
enough that you _can't_ do it any other way. D is not that inflexible, and I 
do not want to be forced to write code in someone else's style. As long as 
people don't do completely crazy stuff with formatting, it's generally easy 
enough to read code such that the formatting really shouldn't be an issue.

- Jonathan M Davis
Jul 14 2011
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/14/2011 6:33 PM, Jonathan M Davis wrote:

 Personally, I do _not_ want to see any kind of official coding standard which
 tries to regulate formatting.


http://digitalmars.com/d/2.0/dstyle.html

The idea of the current D style guide is not to force anything on anyone, it's 
more of a default to fill in the vacuum when people look for a style guide, 
who'd prefer to use an existing one rather than invent one.
Jul 14 2011
parent Russel Winder <russel russel.org.uk> writes:
On Thu, 2011-07-14 at 18:56 -0700, Walter Bright wrote:

 On 7/14/2011 6:33 PM, Jonathan M Davis wrote:

 Personally, I do _not_ want to see any kind of official coding standard=




 which

 tries to regulate formatting.


=20
 http://digitalmars.com/d/2.0/dstyle.html
=20
 The idea of the current D style guide is not to force anything on anyone,=


 it's=20

 more of a default to fill in the vacuum when people look for a style guid=


e,=20

 who'd prefer to use an existing one rather than invent one.


Which is exactly what PEP-8 is for Python -- it is the default style
guide that people can fall back on if there is no agreed style for a
given project by the people working on that project.  The power of a
sensible default is strong.

But as someone said in another post, Python is special compared to the
curly bracket languages due to the block formatting rules.

--=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
Jul 14 2011
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Jonathan M Davis:


 do not want to be forced to write code in someone else's style. As long as 
 people don't do completely crazy stuff with formatting, it's generally easy 
 enough to read code such that the formatting really shouldn't be an issue.


But Mark Chu-Carroll is very smart and expert, he's always worth listening to.

The Scala coding standard:
http://davetron5000.github.com/scala-style/index.html

I presume other D programmers share your opinion. But not using a standard with
a bit more energy will be one of the faults of D.

Bye,
bearophile
Jul 14 2011
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday 14 July 2011 22:07:03 bearophile wrote:

 Jonathan M Davis:

 do not want to be forced to write code in someone else's style. As long
 as people don't do completely crazy stuff with formatting, it's
 generally easy enough to read code such that the formatting really
 shouldn't be an issue.


 
 But Mark Chu-Carroll is very smart and expert, he's always worth listening
 to.
 
 The Scala coding standard:
 http://davetron5000.github.com/scala-style/index.html
 
 I presume other D programmers share your opinion. But not using a standard
 with a bit more energy will be one of the faults of D.


Being forced to code to someone else's standard is highly unpleasant. I've 
worked with places that had strict standards and those which didn't. It's 
always been more pleasant to code without a strict standard. Sure, some code 
might be somewhat harder to read, because it uses a style that I'm not used 
to, but as long as the programmer wasn't totally crazy, it's still readable, 
and the pain of having to read their code is _far_ smaller than the pain of 
having to conform to a standard that goes against how I want to code. I 
program for a living, and I want programming to be pleasant. Having to format 
code to a particular coding standard is _not_ pleasant.

Sure, Mark Chu-Caroll may be a smart guy, but i don't agree with him. He's 
talking about his personal experience and what he found to work for him. 
That's fine. That's what works for him. It's _not_ what I want to deal with.

- Jonathan M Davis
Jul 14 2011
prev sibling next sibling parent reply KennyTM~ <kennytm gmail.com> writes:
On Jul 15, 11 10:07, bearophile wrote:

 Jonathan M Davis:


 do not want to be forced to write code in someone else's style. As long as
 people don't do completely crazy stuff with formatting, it's generally easy
 enough to read code such that the formatting really shouldn't be an issue.


 But Mark Chu-Carroll is very smart and expert, he's always worth listening to.


http://en.wikipedia.org/wiki/Appeal_to_authority ;) A coding standard is 
good, but a it is often enforced only within one organization, not 
necessarily for the whole language.

Anyway, D has http://d-programming-language.org/dstyle.html, which is 
applied to Phobos, at least. I think it is already up-to-date, except 
the [80, 120] maximum line width and '{' on its own line rules? This has 
been discussed several times already.

(Speaking of which, druntime should also follow this style convention. I 
cringe when adopting my code to the original style 
(`f(<space>param<space>)`) of core.demangle.)

Let's make a bugzilla listing out all lacking (or over-restrictive) 
recommendations in dstyle.html.


 The Scala coding standard:
 http://davetron5000.github.com/scala-style/index.html

 I presume other D programmers share your opinion. But not using a standard
with a bit more energy will be one of the faults of D.

 Bye,
 bearophile
Jul 15 2011
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday 15 July 2011 15:36:45 KennyTM~ wrote:

 On Jul 15, 11 10:07, bearophile wrote:

 Jonathan M Davis:

 do not want to be forced to write code in someone else's style. As=







 long as people don't do completely crazy stuff with formatting, it=






's

 generally easy enough to read code such that the formatting really=







 shouldn't be an issue.


=20
 But Mark Chu-Carroll is very smart and expert, he's always worth
 listening to.


=20
 http://en.wikipedia.org/wiki/Appeal_to_authority ;) A coding standard=


 is

 good, but a it is often enforced only within one organization, not
 necessarily for the whole language.
=20
 Anyway, D has http://d-programming-language.org/dstyle.html, which is=



 applied to Phobos, at least. I think it is already up-to-date, except=



 the [80, 120] maximum line width and '{' on its own line rules? This =


has

 been discussed several times already.
=20
 (Speaking of which, druntime should also follow this style convention=


. I

 cringe when adopting my code to the original style
 (`f(<space>param<space>)`) of core.demangle.)
=20
 Let's make a bugzilla listing out all lacking (or over-restrictive)
 recommendations in dstyle.html.


It's mostly correct. The main items that needs to be removed are

* Op=C2=ADer=C2=ADa=C2=ADtors are sep=C2=ADa=C2=ADrated by sin=C2=ADgle=
 spaces from their operands.

* Two blank lines sep=C2=ADa=C2=ADrat=C2=ADing func=C2=ADtion bod=C2=AD=
ies.

* One blank line sep=C2=ADa=C2=ADrat=C2=ADing vari=C2=ADable de=C2=ADc=C2=
=ADla=C2=ADra=C2=ADtions from state=C2=ADments in=20
func=C2=ADtion bod=C2=ADies.

These are not necessarily held to in Phobos, and I know that Andrei in=20=

particular doesn't like the "two blank lines separating function bodies=
," so=20
we're not requiring any of these.

The brace on its own line and the line length limit need to be added as=
 notes=20
for Phobos, but I'm not sure that they really need to be put in the sty=
le=20
guide as if we were recommending them for the language at large. Other =
than=20
that, it might need a few minor tweaks (like making it clear that const=
ants=20
should generally be camelcased just like other variables), but glancing=
 over=20
it, I believe that it's essentially correct (except for what I mentione=
d=20
above). I keep meaning to create a pull request for the fixes to it, bu=
t I=20
haven't gotten around to it yet.

- Jonathan M Davis
Jul 15 2011
parent reply Trass3r <un known.com> writes:
Am 15.07.2011, 09:53 Uhr, schrieb Jonathan M Davis <jmdavisProg gmx.com>:

 The brace on its own line and the line length limit need to be added as  
 notes for Phobos, but I'm not sure that they really need to be put in  
 the guide


Brace on its own line really should be put there.
It adds a lot to the readability of nested code.

And there's lots of D code using that awkward
if () {
}

style. Gross!
Jul 15 2011
next sibling parent reply Russel Winder <russel russel.org.uk> writes:
On Fri, 2011-07-15 at 16:25 +0200, Trass3r wrote:

 Am 15.07.2011, 09:53 Uhr, schrieb Jonathan M Davis <jmdavisProg gmx.com>:

 The brace on its own line and the line length limit need to be added as=




 =20

 notes for Phobos, but I'm not sure that they really need to be put in =




=20

 the guide


=20
 Brace on its own line really should be put there.
 It adds a lot to the readability of nested code.
=20
 And there's lots of D code using that awkward
 if () {
 }
=20
 style. Gross!


Actually I think that the above is the only acceptable style of brace
placement, especially compared to

if ( )
{
}

which is anathema, no code should ever be allowed to use it.

(If you read this as a troll, then you have missed the point of
moralization by satire.)=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
Jul 15 2011
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 7/15/11 10:09 AM, Russel Winder wrote:

 On Fri, 2011-07-15 at 16:25 +0200, Trass3r wrote:

 Am 15.07.2011, 09:53 Uhr, schrieb Jonathan M Davis<jmdavisProg gmx.com>:

 The brace on its own line and the line length limit need to be added as
 notes for Phobos, but I'm not sure that they really need to be put in
 the guide


 Brace on its own line really should be put there.
 It adds a lot to the readability of nested code.

 And there's lots of D code using that awkward
 if () {
 }

 style. Gross!


 Actually I think that the above is the only acceptable style of brace
 placement, especially compared to

 if ( )
 {
 }

 which is anathema, no code should ever be allowed to use it.

 (If you read this as a troll, then you have missed the point of
 moralization by satire.)


(long sigh of relief after reading the last paragraph)

Andrei
Jul 15 2011
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Friday 15 July 2011 16:09:06 Russel Winder wrote:

 On Fri, 2011-07-15 at 16:25 +0200, Trass3r wrote:

 Am 15.07.2011, 09:53 Uhr, schrieb Jonathan M Davis <jmdavisProg gmx.com>:

 The brace on its own line and the line length limit need to be added
 as
 notes for Phobos, but I'm not sure that they really need to be put
 in
 the guide


 
 Brace on its own line really should be put there.
 It adds a lot to the readability of nested code.
 
 And there's lots of D code using that awkward
 if () {
 }
 
 style. Gross!


 
 Actually I think that the above is the only acceptable style of brace
 placement, especially compared to
 
 if ( )
 {
 }
 
 which is anathema, no code should ever be allowed to use it.
 
 (If you read this as a troll, then you have missed the point of
 moralization by satire.)


LOL. Whereas I would argue that that is exactly the style of bracing which 
should be used. This is exactly why we shouldn't be trying to push any kind of 
global standard for D with regards to formatting. You will never get everyone 
to agree on it even within a relatively small group.

The current style guide primarily covers naming conventions, which actually 
affect APIs and are far more important.

Incidentally, bracing on its own line is one of the few formatting rules that 
Phobos requires (primarily because braces is one of the few areas of 
formatting which causes code to get really ugly if it varies all over the 
place).

- Jonathan M Davis
Jul 15 2011
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/15/2011 7:25 AM, Trass3r wrote:

 And there's lots of D code using that awkward
 if () {
 }

 style. Gross!


I don't particularly like that style, either, but it's used in the ebook
because 
display size is extremely limited and it's more compact.
Jul 15 2011
next sibling parent Andrew Wiley <wiley.andrew.j gmail.com> writes:
On Fri, Jul 15, 2011 at 9:46 AM, Walter Bright
<newshound2 digitalmars.com>wrote:


 On 7/15/2011 7:25 AM, Trass3r wrote:


 And there's lots of D code using that awkward
 if () {
 }

 style. Gross!


 I don't particularly like that style, either, but it's used in the ebook
 because display size is extremely limited and it's more compact.


I'm very much used to this style, but that's probably because it's the
standard in the Java world. I'm debating whether it's worth it to retrain
myself.
Jul 16 2011
prev sibling next sibling parent reply Roman Ivanov <isroman.DEL ETE.km.ru> writes:
On 7/15/2011 12:46 PM, Walter Bright wrote:

 On 7/15/2011 7:25 AM, Trass3r wrote:

 And there's lots of D code using that awkward
 if () {
 }

 style. Gross!


 
 I don't particularly like that style, either, but it's used in the ebook
 because display size is extremely limited and it's more compact.


I find this a strong, objective argument in its favor. Stylistics
preferences are one thing, but when you're stuck coding on a 15-inch
widescreen laptop, those extra newlines become a real pain, because you
see less code at the same time, which results in lots of scrolling.
Jul 16 2011
parent =?UTF-8?B?IkrDqXLDtG1lIE0uIEJlcmdlciI=?= <jeberger free.fr> writes:
Roman Ivanov wrote:

 On 7/15/2011 12:46 PM, Walter Bright wrote:

 On 7/15/2011 7:25 AM, Trass3r wrote:

 And there's lots of D code using that awkward
 if () {
 }

 style. Gross!


 I don't particularly like that style, either, but it's used in the ebo=




ok

 because display size is extremely limited and it's more compact.


=20
 I find this a strong, objective argument in its favor. Stylistics
 preferences are one thing, but when you're stuck coding on a 15-inch
 widescreen laptop, those extra newlines become a real pain, because you=



 see less code at the same time, which results in lots of scrolling.


	This is the main reason why I prefer this style...

		Jerome
--=20
mailto:jeberger free.fr
http://jeberger.free.fr
Jabber: jeberger jabber.fr
Jul 18 2011
prev sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 7/15/11, Walter Bright <newshound2 digitalmars.com> wrote:

 On 7/15/2011 7:25 AM, Trass3r wrote:

 And there's lots of D code using that awkward
 if () {
 }

 style. Gross!


 I don't particularly like that style, either, but it's used in the ebook
 because
 display size is extremely limited and it's more compact.


Hey Walter, you have a really kinky coding style!!:

if()
{ yayStatement();
}

LOL. :P
Jul 17 2011
parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/17/2011 2:09 PM, Andrej Mitrovic wrote:

 Hey Walter, you have a really kinky coding style!!:

 if()
 { yayStatement();
 }


That was born of the days of programming using 24 line tty's.
Jul 17 2011
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 7/14/2011 7:07 PM, bearophile wrote:

 But not using a standard with a bit more energy will be one of the faults of D.


There is a D style guide. I really don't understand what you're complaining
about.
Jul 15 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-07-15 12:55, Walter Bright wrote:

 On 7/14/2011 7:07 PM, bearophile wrote:

 But not using a standard with a bit more energy will be one of the
 faults of D.


 There is a D style guide. I really don't understand what you're
 complaining about.


Probably that not enough people is using it and it's not strict enough.

-- 
/Jacob Carlborg
Jul 15 2011
prev sibling next sibling parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Fri, 15 Jul 2011 01:11:18 +0200, bearophile <bearophileHUGS lycos.com>  
wrote:


 Mark Chu-Carroll is a first class programmer and more. He's leaving  
 Google and writes about what's good in it. Here he explains in a very  
 simple way why coding standards are good:
 http://scientopia.org/blogs/goodmath/2011/07/14/stuff-everyone-should-do-part-2-coding-standards/

 He talks just about the coding standards of one firm, so he forgets to  
 talk about a related but in my opinion equally important point. If I  
 take a look at Delphi code, C code, C++ code, I see everything, every  
 coding style, naming convention, and many other differences, that make  
 me harder to read and understand their code.

 If I take a look at Python code written by ten different people I see  
 much more uniformity. This uniformity is part of the Python culture, its  
 PEP8 http://www.python.org/dev/peps/pep-0008/ ) is a coding standard  
 that instead of being just Google-wide is language-wide. This allows me  
 to understand Python code in less time, to copy and use functions,  
 classes, modules, packages and libraries written by other people and use  

 uniformity compared to C++ code, but less than Python code).

 Go language even comes with a source code formatter that is used often  
 to format code. I think they have learnt well that Google lesson :-)

 Even Scala seems about to do something similar:
 http://drdobbs.com/article/print?articleId=231001802&siteSectionName=


Gods, not this again. Short version: No.



-- 
   Simen
Jul 15 2011
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 15.07.2011 16:13, Simen Kjaeraas wrote:

 On Fri, 15 Jul 2011 01:11:18 +0200, bearophile 
 <bearophileHUGS lycos.com> wrote:


 Mark Chu-Carroll is a first class programmer and more. He's leaving 
 Google and writes about what's good in it. Here he explains in a very 
 simple way why coding standards are good:
 http://scientopia.org/blogs/goodmath/2011/07/14/stuff-everyone-should-do-part
2-coding-standards/ 


 He talks just about the coding standards of one firm, so he forgets 
 to talk about a related but in my opinion equally important point. If 
 I take a look at Delphi code, C code, C++ code, I see everything, 
 every coding style, naming convention, and many other differences, 
 that make me harder to read and understand their code.

 If I take a look at Python code written by ten different people I see 
 much more uniformity. This uniformity is part of the Python culture, 
 its PEP8 http://www.python.org/dev/peps/pep-0008/ ) is a coding 
 standard that instead of being just Google-wide is language-wide. 
 This allows me to understand Python code in less time, to copy and 
 use functions, classes, modules, packages and libraries written by 

 intermediate. I see more uniformity compared to C++ code, but less 
 than Python code).

 Go language even comes with a source code formatter that is used 
 often to format code. I think they have learnt well that Google 
 lesson :-)

 Even Scala seems about to do something similar:
 http://drdobbs.com/article/print?articleId=231001802&siteSectionName=


 Gods, not this again. Short version: No.


+1

-- 
Dmitry Olshansky
Jul 15 2011
prev sibling parent reply bearophile <bearophileHUGS lycos.com> writes:
Walter:


 bearophile:

 But not using a standard with a bit more energy will be one of the faults of D.


 There is a D style guide. I really don't understand what you're complaining
about.


This blog post is about Gofix, a Go standard library tool, it seems one
possible answer:
http://blog.golang.org/2011/04/introducing-gofix.html


Gofix is a new tool that reduces the amount of effort it takes to update
existing code. It reads a program from a source file, looks for uses of old
APIs, rewrites them to use the current API, and writes the program back to the
file. Not all API changes preserve all the functionality of an old API, so
gofix cannot always do a perfect job. When gofix cannot rewrite a use of an old
API, it prints a warning giving the file name and line number of the use, so
that a developer can examine and rewrite the code. Gofix takes care of the
easy, repetitive, tedious changes, so that a developer can focus on the ones
that truly merit attention.<



Gofix is possible because Go has support in its standard libraries for parsing
Go source files into syntax trees and also for printing those syntax trees back
to Go source code. Importantly, the Go printing library prints a program in the
official format (typically enforced via the gofmt tool), allowing gofix to make
mechanical changes to Go programs without causing spurious formatting changes.
In fact, one of the key motivations for creating gofmt—perhaps second only to
avoiding debates about where a particular brace belongs—was to simplify the
creation of tools that rewrite Go programs, as gofix does.<


Bye,
bearophile
Jul 17 2011
parent Johann MacDonagh <johann.macdonagh.no spam.gmail.com> writes:
On 7/17/2011 4:53 PM, bearophile wrote:

 Walter:


 bearophile:

 But not using a standard with a bit more energy will be one of the faults of D.


 There is a D style guide. I really don't understand what you're complaining
about.


 This blog post is about Gofix, a Go standard library tool, it seems one
possible answer:
 http://blog.golang.org/2011/04/introducing-gofix.html


 Gofix is a new tool that reduces the amount of effort it takes to update
existing code. It reads a program from a source file, looks for uses of old
APIs, rewrites them to use the current API, and writes the program back to the
file. Not all API changes preserve all the functionality of an old API, so
gofix cannot always do a perfect job. When gofix cannot rewrite a use of an old
API, it prints a warning giving the file name and line number of the use, so
that a developer can examine and rewrite the code. Gofix takes care of the
easy, repetitive, tedious changes, so that a developer can focus on the ones
that truly merit attention.<



 Gofix is possible because Go has support in its standard libraries for parsing
Go source files into syntax trees and also for printing those syntax trees back
to Go source code. Importantly, the Go printing library prints a program in the
official format (typically enforced via the gofmt tool), allowing gofix to make
mechanical changes to Go programs without causing spurious formatting changes.
In fact, one of the key motivations for creating gofmt—perhaps second only to
avoiding debates about where a particular brace belongs—was to simplify the
creation of tools that rewrite Go programs, as gofix does.<


 Bye,
 bearophile



So you're saying a style guide would help to create a tool like DFix?

Wouldn't it be better to have a lexer and parser to do this for you (btw 
I'm working on std.lang.d.lexer).
Jul 17 2011