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
libraries written by other people and use them in my code (in C# the situation
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=



 why coding standards are good:

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




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



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=



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=
ages and libraries written by other people and use them in my code (in C# t=
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=




 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
 code (in C# the situation 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=



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 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
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 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
next sibling 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 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 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:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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!










 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.



	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 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 next sibling parent 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=










 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=




 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 =




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




 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
prev sibling next 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 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
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 next sibling parent Russel Winder <russel russel.org.uk> writes:
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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.
=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
prev sibling next sibling parent Andrew Wiley <wiley.andrew.j gmail.com> writes:
--0016e68e91963a063504a82a7c80
Content-Type: text/plain; charset=ISO-8859-1

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.

--0016e68e91963a063504a82a7c80
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Fri, Jul 15, 2011 at 9:46 AM, Walter Bright <=
span dir=3D"ltr">&lt;<a href=3D"mailto:newshound2 digitalmars.com">newshoun=
d2 digitalmars.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"=



<div class=3D"im">On 7/15/2011 7:25 AM, Trass3r wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
And there&#39;s lots of D code using that awkward<br>
if () {<br>
}<br>
<br>
style. Gross!<br>
</blockquote>
<br></div>
I don&#39;t particularly like that style, either, but it&#39;s used in the =
ebook because display size is extremely limited and it&#39;s more compact.<=
br>
</blockquote></div><br><div>I&#39;m very much used to this style, but that&=
#39;s probably because it&#39;s the standard in the Java world. I&#39;m deb=
ating whether it&#39;s worth it to retrain myself.</div>

--0016e68e91963a063504a82a7c80--



 Jul 16 2011



prev sibling  parent  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



prev sibling 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  Russel Winder <russel russel.org.uk>  writes:


Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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=







 tries to regulate formatting.



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




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




 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 "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  
 them in my code (in C# the situation 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=



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 
 other people and use them in my code (in C# the situation 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=



 Gods, not this again. Short version: No.




-- 
Dmitry Olshansky



 Jul 15 2011