www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Basic coding style

reply bearophile <bearophileHUGS lycos.com> writes:
From what I'm seeing in D.learn there is a problem in the D community: some
people seem irrationally attached to the idea they are free to write D code as
they like. I have four or five times tried to explain why coding standards are
important for the development of the D community, but it seems not everybody is
understanding it.

So I suggest everyone that understands this problem to assume a more rigid and
strict attitude toward this problem, because the D2 language community is just
starting to develop now, and you don't want it to become the mess the C/C++
world it. I am talking about cases of struct/class names, cases of function
names, and few other things.

If I import a module written by another person, I don't want to look in the
docs every time to know if the names start with upper case or lower case, and I
don't want a module of mine that uses three modules written by other people to
look like a patchwork of different styles (because half of it uses an API with
a style and half of it with another API and some bits written in a third way).

If you don't act now, adopting less tolerance, this will lead to a mess.

Bye,
bearophile
Nov 22 2010
next sibling parent so <so so.do> writes:
 If I import a module written by another person, I don't want to look in  
 the docs every time to know if the names start with upper case or lower  
 case, and I don't want a module of mine that uses three modules written  
 by other people to look like a patchwork of different styles (because  
 half of it uses an API with a style and half of it with another API and  
 some bits written in a third way).

 If you don't act now, adopting less tolerance, this will lead to a mess.

 Bye,
 bearophile


Having a coding scheme for standard library is a great idea and enforcing  
it quite possible,
all the standard libraries including D does this and it works alright.

Indeed, having an explicit coding style is a good thing but a language  
should not be eager to enforce syntactical issues IMHO.
For example, NO one can make me write "C" before a class name. Even though  
some people think it is a great idea, it is just retarded.

On the other hand "someCode" was ugly to me at the beginning and i now  
started to think/get it can be better than "some_code".

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
Nov 22 2010
prev sibling next sibling parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
On 22.11.2010 15:29, bearophile wrote:

  From what I'm seeing in D.learn there is a problem in the D community: some
people seem irrationally attached to the idea they are free to write D code as
they like. I have four or five times tried to explain why coding standards are
important for the development of the D community, but it seems not everybody is
understanding it.


I see no problem in any style, as long as it's consistent.

 So I suggest everyone that understands this problem to assume a more rigid and
strict attitude toward this problem, because the D2 language community is just
starting to develop now, and you don't want it to become the mess the C/C++
world it. I am talking about cases of struct/class names, cases of function
names, and few other things.

 If I import a module written by another person, I don't want to look in the
docs every time to know if the names start with upper case or lower case, and I
don't want a module of mine that uses three modules written by other people to
look like a patchwork of different styles (because half of it uses an API with
a style and half of it with another API and some bits written in a third way).


Usually I'd always check the docs before using functions/classes, and 
not because of name alone.
In the end if you dislike theirs naming scheme so much, just make 
aliases/wrappers,
which are often times needed anyways.
They may just as well adopt a classic C-like interface (like zlib for 
instance) and
what if you dislike it and like classes/generics/ranges ?
Shoot them all, huh?

 If you don't act now, adopting less tolerance, this will lead to a mess.

 Bye,
 bearophile



-- 
Dmitry Olshansky
Nov 22 2010
prev sibling next sibling parent Kagamin <spam here.lot> writes:
bearophile Wrote:


 If you don't act now, adopting less tolerance, this will lead to a mess.


If your standard loses then it's a bad standard and it *should* lose. And
earlier is better than later.
Nov 22 2010
prev sibling next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On 11/22/2010 9:29 PM, bearophile wrote:

  From what I'm seeing in D.learn there is a problem in the D community: some
people seem irrationally attached to the idea they are free to write D code as
they like. I have four or five times tried to explain why coding standards are
important for the development of the D community, but it seems not everybody is
understanding it.

 So I suggest everyone that understands this problem to assume a more rigid and
strict attitude toward this problem, because the D2 language community is just
starting to develop now, and you don't want it to become the mess the C/C++
world it. I am talking about cases of struct/class names, cases of function
names, and few other things.

 If I import a module written by another person, I don't want to look in the
docs every time to know if the names start with upper case or lower case, and I
don't want a module of mine that uses three modules written by other people to
look like a patchwork of different styles (because half of it uses an API with
a style and half of it with another API and some bits written in a third way).

 If you don't act now, adopting less tolerance, this will lead to a mess.


People are absolutely free to write D code in any style they please. 
Only if they are contributing to the standard library should they be 
*required* to stick to the specific convention outlined in the docs. 
Otherwise, it's a matter of choice. I certainly don't want anyone 
dictating style to me on any projects I might make publicly available.
Nov 22 2010
parent reply "Yao G." <yao.gomez spam.gmail.com> writes:
On Mon, 22 Nov 2010 08:22:43 -0600, Mike Parker <aldacron gmail.com> wrote:


 People are absolutely free to write D code in any style they please.  
 Only if they are contributing to the standard library should they be  
 *required* to stick to the specific convention outlined in the docs.  
 Otherwise, it's a matter of choice. I certainly don't want anyone  
 dictating style to me on any projects I might make publicly available.


This. Style should be enforced only when you are contributing to a project  
where there's a previously one defined, like the standard library. And I  
think bearophile should stop being rude with people at the D.learn  
newsgroup.

-- 
Yao G.
Nov 22 2010
parent reply bearophile <bearophileHUGS lycos.com> writes:
Dmitry Olshansky:


 Usually I'd always check the docs before using functions/classes, and not
because of name alone.


Right, but a standard naming scheme allows you to tell apart different kinds of
things just from the look of their, this helps you speed up your coding a
little, etc, and makes the visual look of the code less noisy, because it
decreases unecessary randomness inside the listings. This is why when you have
a little training in using Pascal-like languages you write all names in the
same case and style, because otherwise you add unnecessary noise.



 In the end if you dislike theirs naming scheme so much, just make
aliases/wrappers,


The point of the discussion is not what I like. I don't even like the standard
D naming conventions.



 They may just as well adopt a classic C-like interface (like zlib for
instance) and
 what if you dislike it and like classes/generics/ranges ?
 Shoot them all, huh?


I think this is beside the point.

------------------------

Kagamin:


 If your standard loses then it's a bad standard and it *should* lose. And
earlier is better than later.


Right :-) Yet there are advantages of having one standard. Sometimes even a
suboptimal standard is better than no standard :-)

------------------------

Mike Parker:


 People are absolutely free to write D code in any style they please.


I don't agree, and I think this is bad and will lead to a mess. This doesn't
lead to a good ecosystem of D modules that you may find online and integrate in
your code.



 I certainly don't want anyone
 dictating style to me on any projects I might make publicly available.



people will surely tell you that your coding style is bad, if you don't follow
their basic coding styles.

------------------------

Yao G.


 And I think bearophile should stop being rude with people at the D.learn
newsgroup.


I am not sorry for the things I have said about this topic in various threads.

------------------------

It seems most people here don't see the risk I am talking about. Maybe most
people here are used to C/C++ languages that don't have a basic coding style,
and they think they have a God-given right to do the same in D and help create
a messy ecosystem of modules for D too. So I will keep my muzzle shut. It's a
lost opportunity to create a better ecosystem.

Bye,
bearophile
Nov 22 2010
next sibling parent reply Rainer Deyke <rainerd eldwood.com> writes:
On 11/22/2010 11:03, bearophile wrote:


 then people will surely tell you that your coding style is bad, if
 you don't follow their basic coding styles.


Python is a bad example to mention, methinks.  Even C++ has a more
consistent style.


-- 
Rainer Deyke - rainerd eldwood.com
Nov 22 2010
parent reply spir <denis.spir gmail.com> writes:
On Mon, 22 Nov 2010 11:24:20 -0700
Rainer Deyke <rainerd eldwood.com> wrote:


 On 11/22/2010 11:03, bearophile wrote:


 then people will surely tell you that your coding style is bad, if
 you don't follow their basic coding styles.


=20
 Python is a bad example to mention, methinks.  Even C++ has a more
 consistent style.


???

[What is such a wild judgement supposed to mean, Rainer? Python certainly h=
as one of the most sensible and consistent coding styles in practice: http:=
//www.python.org/dev/peps/pep-0008/. I do _not_ agree with half of it ;-) b=
ut it is consistent and sensible (and I used it for all published code.)]


Denis
-- -- -- -- -- -- --
vit esse estrany =E2=98=A3

spir.wikidot.com
Nov 22 2010
parent reply Rainer Deyke <rainerd eldwood.com> writes:
On 11/22/2010 13:25, spir wrote:

 On Mon, 22 Nov 2010 11:24:20 -0700 Rainer Deyke <rainerd eldwood.com>
 wrote:
 

 On 11/22/2010 11:03, bearophile wrote:


 use, then people will surely tell you that your coding style is
 bad, if you don't follow their basic coding styles.


 
 Python is a bad example to mention, methinks.  Even C++ has a more 
 consistent style.


 
 ???
 
 [What is such a wild judgement supposed to mean, Rainer? Python
 certainly has one of the most sensible and consistent coding styles
 in practice: http://www.python.org/dev/peps/pep-0008/. I do _not_
 agree with half of it ;-) but it is consistent and sensible (and I
 used it for all published code.)]


I'm talking about naming conventions, which I think is the most
important part of a coding style.  The indentation level of a third
party library doesn't affect my own code, so I don't care about it.  I
Do care about naming conventions, because the naming convention used in
third party libraries affects my own code.

The C++ standard library has a fairly consistent naming convention.  All
words are lower case, usually separated by underscores, sometimes
prefixed or postfixed with individual letters carrying additional meaning.

In Python, the general rule is that classes use CaptializedWords,
constants use UPPER_CASE (with underscores), and everything else uses
lowercase (usually without underscores).  However, these rules are
broken all the time by Python's own standard library.  For example:
  - Almost all built-in classes use lowercase.  In some cases this is
for historical reasons because the name was originally used for a
function.  However, even new built-in classes tend to use lowercase.
  - Built-in constants 'None', 'True', 'False'.
  - Some functions (e.g. 'raw_input') use underscores while most don't.
 This is allowed by the style guide, but it's still an inconsistency.


-- 
Rainer Deyke - rainerd eldwood.com
Nov 22 2010
parent spir <denis.spir gmail.com> writes:
On Mon, 22 Nov 2010 13:50:44 -0700
Rainer Deyke <rainerd eldwood.com> wrote:


 On 11/22/2010 13:25, spir wrote:

 On Mon, 22 Nov 2010 11:24:20 -0700 Rainer Deyke <rainerd eldwood.com>
 wrote:
=20

 On 11/22/2010 11:03, bearophile wrote:


 use, then people will surely tell you that your coding style is
 bad, if you don't follow their basic coding styles.


=20
 Python is a bad example to mention, methinks.  Even C++ has a more=20
 consistent style.


=20
 ???
=20
 [What is such a wild judgement supposed to mean, Rainer? Python
 certainly has one of the most sensible and consistent coding styles
 in practice: http://www.python.org/dev/peps/pep-0008/. I do _not_
 agree with half of it ;-) but it is consistent and sensible (and I
 used it for all published code.)]


=20
 I'm talking about naming conventions, which I think is the most
 important part of a coding style.  The indentation level of a third
 party library doesn't affect my own code, so I don't care about it.  I
 Do care about naming conventions, because the naming convention used in
 third party libraries affects my own code.
=20
 The C++ standard library has a fairly consistent naming convention.  All
 words are lower case, usually separated by underscores, sometimes
 prefixed or postfixed with individual letters carrying additional meaning.
=20
 In Python, the general rule is that classes use CaptializedWords,
 constants use UPPER_CASE (with underscores), and everything else uses
 lowercase (usually without underscores).  However, these rules are
 broken all the time by Python's own standard library.  For example:
   - Almost all built-in classes use lowercase.  In some cases this is
 for historical reasons because the name was originally used for a
 function.  However, even new built-in classes tend to use lowercase.
   - Built-in constants 'None', 'True', 'False'.
   - Some functions (e.g. 'raw_input') use underscores while most don't.
  This is allowed by the style guide, but it's still an inconsistency.


All right, I understand better. Seems you're actually talking of python bui=
ltin names breaking its own standard, not of the standard itself.
The same applies to D (see my post) on the topic. I also find this _bad_, i=
n any language.=20

Denis
-- -- -- -- -- -- --
vit esse estrany =E2=98=A3

spir.wikidot.com
Nov 23 2010
prev sibling next sibling parent so <so so.do> writes:
 It seems most people here don't see the risk I am talking about. Maybe  
 most people here are used to C/C++ languages that don't have a basic  
 coding style, and they think they have a God-given right to do the same  
 in D and help create a messy ecosystem of modules for D too. So I will  
 keep my muzzle shut. It's a lost opportunity to create a better  
 ecosystem.


That may as well be the case but it also might be that you are the one  
that doesn't want to see the picture.
There have been and will be attempts to do what you say in several  
languages, failed attempts.
How is that having the ability to write the way you like is a bad thing?

If you want to populate a style, do it in standard library and enforce it  
(Like we already have.),
This is the most you can expect. More than that is just (cocky?).

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
Nov 22 2010
prev sibling parent so <so so.do> writes:

It might have some nifty features here and there ok, but it is a gui  
language which is belong to a company.
What does it mean? It means you are coding for that specific OS, using  
libraries that again belongs to them, what do you think you would use for  
coding style?
Eh.. their style maybe?

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
Nov 22 2010
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On Mon, 22 Nov 2010 07:29:24 -0500
bearophile <bearophileHUGS lycos.com> wrote:


 From what I'm seeing in D.learn there is a problem in the D community: so=


me people seem irrationally attached to the idea they are free to write D c=
ode as they like. I have four or five times tried to explain why coding sta=
ndards are important for the development of the D community, but it seems n=
ot everybody is understanding it.

=20
 So I suggest everyone that understands this problem to assume a more rigi=


d and strict attitude toward this problem, because the D2 language communit=
y is just starting to develop now, and you don't want it to become the mess=
 the C/C++ world it. I am talking about cases of struct/class names, cases =
of function names, and few other things.

=20
 If I import a module written by another person, I don't want to look in t=


he docs every time to know if the names start with upper case or lower case=
, and I don't want a module of mine that uses three modules written by othe=
r people to look like a patchwork of different styles (because half of it u=
ses an API with a style and half of it with another API and some bits writt=
en in a third way).

=20
 If you don't act now, adopting less tolerance, this will lead to a mess.
=20
 Bye,
 bearophile



I heartfully agree with the big picture. A shared culture is very important=
 in a programming community. But it's hard to achieve, probably impossible.=
 Three notes.



Having a sensible and consistent naming norm would first require updating t=
he language's own builtin names, mainly C legacy. Below a short set of _exa=
mples_ (I don't mean at all these names are good -- just an example):
uint, int, float, bool, char, string, true, false, null
Natural, Int(eger), Real, Logical, Char(acter), Text, TRUE, FALSE, NULL



Whitespace, an important part of code aspect, can hardly be normalised. For=
 instance, it seems that many D coders follow this bracing scheme:

void func(string[] strings)
{
    string[] result;
    foreach (auto s ; strings)
    {
        if (s !=3D "")
        {
            writefln("found: %s", s);
            result ~=3D s;
        }
    }
}

My preferred style would be:

void func(string[] strings) {
    string[] result;
    foreach (auto s ; strings) {
        if (s !=3D "") {
            writefln("found: %s", s);
            result ~=3D s; }}}

maybe because I have coded in Lisp for some time, mainly because I do not l=
ike losing 2 lines of valuable vertical space per block. Indentation is for=
 me what marks a block, braces are just noise required by the parser. In an=
 attempt for a compromise, I use in fact:

void func(string[] strings) {
    string[] result;
    foreach (auto s ; strings) {
        if (s !=3D "") {
            writefln("found: %s", s);
            result ~=3D s;
        }
    }
}

which saves one line per block. But I'm not happy with it. Such considerati=
ons are very personal. There is about 0.0% chance to convince anyone else (=
don't try to convince me, it time lost ;-).



Finally, for any reason I cannot guess, D docs are placed _before_ what the=
y comment instead of _inside_ (except for modules, indeed). You will never =
make me do that: this way eats half of vertical space with doc comments. I =
want docs of elements (funcs, structs, classes) irrelevant to what I'm pres=
ently dealing with to be folded with the code. Only relevant elements remai=
n visible, unfolded. Docs should appear only for presently relevant element=
s. That's my way, fitting my view and coding practice; you won't make me ch=
ange on that ;-)


Denis
-- -- -- -- -- -- --
vit esse estrany =E2=98=A3

spir.wikidot.com
Nov 22 2010
prev sibling next sibling parent reply Eric Poggel <dnewsgroup2 yage3d.net> writes:
On 11/22/2010 7:29 AM, bearophile wrote:

  From what I'm seeing in D.learn there is a problem in the D community: some
people seem irrationally attached to the idea they are free to write D code as
they like. I have four or five times tried to explain why coding standards are
important for the development of the D community, but it seems not everybody is
understanding it.

 So I suggest everyone that understands this problem to assume a more rigid and
strict attitude toward this problem, because the D2 language community is just
starting to develop now, and you don't want it to become the mess the C/C++
world it. I am talking about cases of struct/class names, cases of function
names, and few other things.

 If I import a module written by another person, I don't want to look in the
docs every time to know if the names start with upper case or lower case, and I
don't want a module of mine that uses three modules written by other people to
look like a patchwork of different styles (because half of it uses an API with
a style and half of it with another API and some bits written in a third way).

 If you don't act now, adopting less tolerance, this will lead to a mess.

 Bye,
 bearophile


I think we first need to figure out a standard for phobos 2 :)

std.string.isNumeric
std.string.expandtabs
std.string.tolowerInPlace <--Changes naming convention mid-way!
Nov 22 2010
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/22/10 5:02 PM, Eric Poggel wrote:

 On 11/22/2010 7:29 AM, bearophile wrote:

 From what I'm seeing in D.learn there is a problem in the D community:
 some people seem irrationally attached to the idea they are free to
 write D code as they like. I have four or five times tried to explain
 why coding standards are important for the development of the D
 community, but it seems not everybody is understanding it.

 So I suggest everyone that understands this problem to assume a more
 rigid and strict attitude toward this problem, because the D2 language
 community is just starting to develop now, and you don't want it to
 become the mess the C/C++ world it. I am talking about cases of
 struct/class names, cases of function names, and few other things.

 If I import a module written by another person, I don't want to look
 in the docs every time to know if the names start with upper case or
 lower case, and I don't want a module of mine that uses three modules
 written by other people to look like a patchwork of different styles
 (because half of it uses an API with a style and half of it with
 another API and some bits written in a third way).

 If you don't act now, adopting less tolerance, this will lead to a mess.

 Bye,
 bearophile


 I think we first need to figure out a standard for phobos 2 :)

 std.string.isNumeric


correct. Types in Phobos are LikeThis whereas functions and values are 
likeThis. (BTW I find that function beyond useless.)


 std.string.expandtabs


Copied from another language's strings lib.


 std.string.tolowerInPlace <--Changes naming convention mid-way!


Well, tolower is arguably a collocation :o).


Andrei
Nov 22 2010
next sibling parent spir <denis.spir gmail.com> writes:
On Mon, 22 Nov 2010 17:07:10 -0600
Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> wrote:


 std.string.expandtabs =20


=20
 Copied from another language's strings lib.
=20

 std.string.tolowerInPlace <--Changes naming convention mid-way! =20


=20
 Well, tolower is arguably a collocation :o).


You're right in both cases. But if one _really_ wants it, it's always possi=
ble to find an argument for any exception.

Denis
-- -- -- -- -- -- --
vit esse estrany =E2=98=A3

spir.wikidot.com
Nov 23 2010
prev sibling parent reply Brainy <smurf villa.ge> writes:
Andrei Alexandrescu Wrote:


 On 11/22/10 5:02 PM, Eric Poggel wrote:

 On 11/22/2010 7:29 AM, bearophile wrote:

 From what I'm seeing in D.learn there is a problem in the D community:
 some people seem irrationally attached to the idea they are free to
 write D code as they like. I have four or five times tried to explain
 why coding standards are important for the development of the D
 community, but it seems not everybody is understanding it.

 So I suggest everyone that understands this problem to assume a more
 rigid and strict attitude toward this problem, because the D2 language
 community is just starting to develop now, and you don't want it to
 become the mess the C/C++ world it. I am talking about cases of
 struct/class names, cases of function names, and few other things.

 If I import a module written by another person, I don't want to look
 in the docs every time to know if the names start with upper case or
 lower case, and I don't want a module of mine that uses three modules
 written by other people to look like a patchwork of different styles
 (because half of it uses an API with a style and half of it with
 another API and some bits written in a third way).

 If you don't act now, adopting less tolerance, this will lead to a mess.

 Bye,
 bearophile


 I think we first need to figure out a standard for phobos 2 :)

 std.string.isNumeric


 
 correct. Types in Phobos are LikeThis whereas functions and values are 
 likeThis. (BTW I find that function beyond useless.)
 

 std.string.expandtabs


 
 Copied from another language's strings lib.
 

 std.string.tolowerInPlace <--Changes naming convention mid-way!


 
 Well, tolower is arguably a collocation :o).
 
 
 Andrei


Bearophile seriously go cure yourself. Your obsession of making D __seem__ good
fails badly. People adopt D because of your advertisement on various forums and
tutorials. They expect much, but dive deep in shit in return. You can't beat
the authors in arrogance. They shamelessly defend bad coding practices like
this. You also can't change the way amateur followers think. D is a better C++,
nothing more. You want much more. Why stick with D? The ratio of successful
proposals would be much higher in communities of more experimental languages.
You also face tons of bugs with dmd. No other reference compiler is as buggy
and non-free. Think about it. This is an obsession. You owe nothing to the
developers. They don't appreciate your skills in any case. There will be no D3
in the near future. I hope the puremagic bugzilla will accidentally wipe all
your excellent proposals to make you realize this language has no future. TYVM
for your attention.
Nov 23 2010
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 11/23/10 5:32 PM, Brainy wrote:

 Bearophile seriously go cure yourself. Your obsession of making D
 __seem__ good fails badly. People adopt D because of your
 advertisement on various forums and tutorials. They expect much, but
 dive deep in shit in return. You can't beat the authors in arrogance.
 They shamelessly defend bad coding practices like this.


Quite honest, I wish my main problem were shoddy practices in naming 
functions. Anyhow, fact is, it's all true: expandtabs was taken verbatim 
from Python 
(http://www.tutorialspoint.com/python/string_expandtabs.htm). I 
personally think the whole function could be deprecated. tolower has 
virtually become a collocation because C has had it forever. Besides, I 
defined the function tolowerInPlace to keep a parallel with tolower, 
which creates a new string.

New code I introduced follows the convention that types start with 
uppercase and values and function names start with lowercase.

Overall this doesn't seem significant evidence of shameless defense of 
bad practices stemmed in arrogance. I trust that someone sufficiently 
motivated could construct a better case.


 You also
 can't change the way amateur followers think. D is a better C++,
 nothing more. You want much more. Why stick with D? The ratio of
 successful proposals would be much higher in communities of more
 experimental languages. You also face tons of bugs with dmd. No other
 reference compiler is as buggy and non-free. Think about it. This is
 an obsession. You owe nothing to the developers. They don't
 appreciate your skills in any case. There will be no D3 in the near
 future. I hope the puremagic bugzilla will accidentally wipe all your
 excellent proposals to make you realize this language has no future.
 TYVM for your attention.


Bearophile's output has made very significant progress since e.g. 1-2 
years ago, and I am very pleased to see that. At the same time, I must 
say I cannot allow myself to agree with all he says just to be nice, and 
I wouldn't rate the average of his contributions as excellent as of this 
time (he'd be the first to say he has much learning ahead of him 
although, again, the improvement has been visible). My perception is 
that less experienced designers tend to ascribe more value to his 
points, which is quite ironic since you wanted to implicitly distinguish 
yourself as savvy.

Overall I think bearophile is receiving fair and well-deserved 
attention, appreciation, and social proof for his contributions to this 
community, and I find this backhanded attempts at discouraging him quite 
unbecoming.


Andrei
Nov 23 2010
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Brainy wrote:

 I hope the
 puremagic bugzilla will accidentally wipe all your excellent proposals to
 make you realize this language has no future.


One constant in the last 10 years has been the confident predictions of D's 
imminent demise. Much to the irritation of the pundits, D continues to fail at 
failing.
Nov 23 2010
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, November 23, 2010 17:02:23 Walter Bright wrote:

 Brainy wrote:

 I hope the
 puremagic bugzilla will accidentally wipe all your excellent proposals to
 make you realize this language has no future.


 
 One constant in the last 10 years has been the confident predictions of D's
 imminent demise. Much to the irritation of the pundits, D continues to fail
 at failing.


Well, if you're going to fail at something, that would generally be the best 
thing to fail at.

- Jonathan M Davis
Nov 23 2010
parent Walter Bright <newshound2 digitalmars.com> writes:
Jonathan M Davis wrote:

 Well, if you're going to fail at something, that would generally be the best 
 thing to fail at.



A friend of mine drifted for years, and he finally got his life together and
now 
is doing well. We kid him that he "failed at being a loser".
Nov 23 2010
prev sibling next sibling parent sybrandy <sybrandy gmail.com> writes:
Much to the irritation of the pundits, D continues to fail at failing.


That's my favorite quote from this newsgroup!

Casey
Nov 24 2010
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 24/11/2010 01:02, Walter Bright wrote:

 Brainy wrote:

 I hope the
 puremagic bugzilla will accidentally wipe all your excellent proposals to
 make you realize this language has no future.


 One constant in the last 10 years has been the confident predictions of
 D's imminent demise. Much to the irritation of the pundits, D continues
 to fail at failing.


Whose pundits are those? At least in this NG, as far as I recall, the 
only people predicting the demise of D have been these nameless trolls. 
(probably similarly in reddit and other forums). Who has actually 
predicted the demised of D and was not an anonymous figure or random guy 
in the internet?

-- 
Bruno Medeiros - Software Engineer
Dec 03 2010
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Bruno Medeiros schrieb:

 On 24/11/2010 01:02, Walter Bright wrote:

 Brainy wrote:

 I hope the
 puremagic bugzilla will accidentally wipe all your excellent 
 proposals to
 make you realize this language has no future.


 One constant in the last 10 years has been the confident predictions of
 D's imminent demise. Much to the irritation of the pundits, D continues
 to fail at failing.


 
 Whose pundits are those? At least in this NG, as far as I recall, the 
 only people predicting the demise of D have been these nameless trolls. 
 (probably similarly in reddit and other forums). Who has actually 
 predicted the demised of D and was not an anonymous figure or random guy 
 in the internet?
 


Believe it or not: Most random guys and anonymous figures are actually real
people.
Of course they're harder to count.
Dec 03 2010
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
On 03/12/2010 17:08, Daniel Gibson wrote:

 Bruno Medeiros schrieb:

 On 24/11/2010 01:02, Walter Bright wrote:

 Brainy wrote:

 I hope the
 puremagic bugzilla will accidentally wipe all your excellent
 proposals to
 make you realize this language has no future.


 One constant in the last 10 years has been the confident predictions of
 D's imminent demise. Much to the irritation of the pundits, D continues
 to fail at failing.


 Whose pundits are those? At least in this NG, as far as I recall, the
 only people predicting the demise of D have been these nameless
 trolls. (probably similarly in reddit and other forums). Who has
 actually predicted the demised of D and was not an anonymous figure or
 random guy in the internet?


 Believe it or not: Most random guys and anonymous figures are actually
 real people.
 Of course they're harder to count.



Yes they are real people, but they are not pundits.
It might have been the case though that Walter was being very liberal in 
his usage of the term "pundits".

-- 
Bruno Medeiros - Software Engineer
Dec 03 2010
prev sibling next sibling parent reply "JimBob" <jim bob.com> writes:
"bearophile" <bearophileHUGS lycos.com> wrote in message 
news:icdnn4$2cnd$1 digitalmars.com...

  I have four or five times tried to explain why coding standards are 
 important for the
 development of the D community


And them there stupid people just wont listen to ya. Thats mighty 
unreasonable of them, you being president of the world an all.
Nov 22 2010
parent reply Matthias Walter <xammy xammy.homelinux.net> writes:
On 11/22/2010 06:21 PM, JimBob wrote:

 "bearophile" <bearophileHUGS lycos.com> wrote in message 
 news:icdnn4$2cnd$1 digitalmars.com...
   

  I have four or five times tried to explain why coding standards are 
 important for the
 development of the D community
     


 And them there stupid people just wont listen to ya. Thats mighty 
 unreasonable of them, you being president of the world an all. 
   


Come on guys, please don't flame here...

I don't like to force anybody in using a style they maybe don't like.
But on the other hand I think bearophile's arguments have some truth in
them.

What about adding a compiler switch that one can turn on and that warns
on obviously wrong names? Is this realistic? At least to check the usage
of underscores and captial first letter. The CamelCase can probably not
be verified, but hopefully a lot of programmers will use it, if the
compiler encourages them to not use underscores... Just an idea, you can
flame on, if you like.

Matthias
Nov 22 2010
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Matthias Walter wrote:

 What about adding a compiler switch that one can turn on and that warns
 on obviously wrong names? Is this realistic? At least to check the usage
 of underscores and captial first letter. The CamelCase can probably not
 be verified, but hopefully a lot of programmers will use it, if the
 compiler encourages them to not use underscores... Just an idea, you can
 flame on, if you like.



If you want, it would be easy to write a simple program that read the .json 
output of the compiler, and then enforce any naming convention you need.
Nov 22 2010
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday 22 November 2010 21:03:27 Walter Bright wrote:

 Matthias Walter wrote:

 What about adding a compiler switch that one can turn on and that warns
 on obviously wrong names? Is this realistic? At least to check the usage
 of underscores and captial first letter. The CamelCase can probably not
 be verified, but hopefully a lot of programmers will use it, if the
 compiler encourages them to not use underscores... Just an idea, you can
 flame on, if you like.


 
 If you want, it would be easy to write a simple program that read the .json
 output of the compiler, and then enforce any naming convention you need.


That could be a useful tool. And I do think that a basic set of "typical" D 
naming conventions and the like could be useful. But I don't really think that 
it makes sense to have the compiler itself enforcing style. That sort of thing 
definitely belongcs in external tools.

- Jonathan M Davis
Nov 22 2010
prev sibling next sibling parent reply spir <denis.spir gmail.com> writes:
On Mon, 22 Nov 2010 21:12:24 -0800
Jonathan M Davis <jmdavisProg gmx.com> wrote:


 If you want, it would be easy to write a simple program that read the .=




json

 output of the compiler, and then enforce any naming convention you need=




. =20

=20
 That could be a useful tool. And I do think that a basic set of "typical"=


 D=20

 naming conventions and the like could be useful.


Yes, but how is this possible since D's own builtin names do not follow the=
 proposed standard (--> wiki)? Should we all alias D's names in a standard =
header of every module?

Denis
-- -- -- -- -- -- --
vit esse estrany =E2=98=A3

spir.wikidot.com
Nov 23 2010
parent Don <nospam nospam.com> writes:
spir wrote:

 On Mon, 22 Nov 2010 21:12:24 -0800
 Jonathan M Davis <jmdavisProg gmx.com> wrote:
 

 If you want, it would be easy to write a simple program that read the .json
 output of the compiler, and then enforce any naming convention you need.  


 That could be a useful tool. And I do think that a basic set of "typical" D 
 naming conventions and the like could be useful.


 
 Yes, but how is this possible since D's own builtin names do not follow the
proposed standard (--> wiki)? 


That wiki page is the proposal of a single individual. It does not 
reflect a community consensus, nor is it in any way standard.
In fact, that is true of everything on the wiki -- helpful, but not 
official.



Should we all alias D's names in a standard header of every module?

 
 Denis
 -- -- -- -- -- -- --
 vit esse estrany ☣
 
 spir.wikidot.com
Nov 23 2010
prev sibling parent Matthias Walter <xammy xammy.homelinux.net> writes:
On 11/23/2010 12:12 AM, Jonathan M Davis wrote:

 On Monday 22 November 2010 21:03:27 Walter Bright wrote:
   

 Matthias Walter wrote:
     

 What about adding a compiler switch that one can turn on and that warns
 on obviously wrong names? Is this realistic? At least to check the usage
 of underscores and captial first letter. The CamelCase can probably not
 be verified, but hopefully a lot of programmers will use it, if the
 compiler encourages them to not use underscores... Just an idea, you can
 flame on, if you like.
       


 If you want, it would be easy to write a simple program that read the .json
 output of the compiler, and then enforce any naming convention you need.
     


 That could be a useful tool. And I do think that a basic set of "typical" D 
 naming conventions and the like could be useful. But I don't really think that 
 it makes sense to have the compiler itself enforcing style. That sort of thing 
 definitely belongcs in external tools.
   


So we should talk to the IDE designers, s.t. they include this into
their list of planned features. I recommend a 3-minute alarm sound per
badly named variable/function :)

Matthias
Nov 23 2010
prev sibling parent "JimBob" <jim bob.com> writes:
"Matthias Walter" <xammy xammy.homelinux.net> wrote in message 
news:mailman.576.1290487758.21107.digitalmars-d puremagic.com...

 On 11/22/2010 06:21 PM, JimBob wrote:

 "bearophile" <bearophileHUGS lycos.com> wrote in message
 news:icdnn4$2cnd$1 digitalmars.com...


  I have four or five times tried to explain why coding standards are
 important for the
 development of the D community


 And them there stupid people just wont listen to ya. Thats mighty
 unreasonable of them, you being president of the world an all.


 Come on guys, please don't flame here...

 I don't like to force anybody in using a style they maybe don't like.
 But on the other hand I think bearophile's arguments have some truth in
 them.


Whether he's right or not is beside the point. It was his arrogance that was 
the target of my jest.
Nov 23 2010
prev sibling next sibling parent reply Kagamin <spam here.lot> writes:
spir Wrote:


 void func(string[] strings) {
     string[] result;
     foreach (auto s ; strings) {
         if (s != "") {
             writefln("found: %s", s);
             result ~= s; }}}


bearophile, look!
Nov 23 2010
parent reply Max Samukha <spambox d-coding.com> writes:
On 11/23/2010 01:17 PM, Kagamin wrote:

 void func(string[] strings) {

       string[] result;
       foreach (auto s ; strings) {
           if (s != "") {
               writefln("found: %s", s);
               result ~= s; }}}




This takes too much vertical space and should be rewritten to:

void func(string[] strings) {string[] result; foreach(auto s; strings){ 
if (s != "") { writefln("found: %s", s); result ~= s; }}}

Nowadays most programmers have 16:9 displays, so the good coding style 
is to write as much as possible in one line. And the more misaligned the 
curies are, the better.
Nov 23 2010
next sibling parent so <so so.do> writes:
 This takes too much vertical space and should be rewritten to:

 void func(string[] strings) {string[] result; foreach(auto s; strings){  
 if (s != "") { writefln("found: %s", s); result ~= s; }}}

 Nowadays most programmers have 16:9 displays, so the good coding style  
 is to write as much as possible in one line. And the more misaligned the  
 curies are, the better.


Compile!

Error (line 1) ....
Error (line 1) ....
Error (line 1) ....
Error (line 1) ....
....

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
Nov 23 2010
prev sibling parent reply Kagamin <spam here.lot> writes:
Max Samukha Wrote:


 On 11/23/2010 01:17 PM, Kagamin wrote:

 void func(string[] strings) {

       string[] result;
       foreach (auto s ; strings) {
           if (s != "") {
               writefln("found: %s", s);
               result ~= s; }}}




 
 This takes too much vertical space and should be rewritten to:
 
 void func(string[] strings) {string[] result; foreach(auto s; strings){ 
 if (s != "") { writefln("found: %s", s); result ~= s; }}}


I wanted to say D allows even python-style formatting. Brace matching editor
will help in syntactical differences.
Nov 23 2010
parent reply spir <denis.spir gmail.com> writes:
On Tue, 23 Nov 2010 10:00:07 -0500
Kagamin <spam here.lot> wrote:


 Max Samukha Wrote:
=20

 On 11/23/2010 01:17 PM, Kagamin wrote:

 void func(string[] strings) {

       string[] result;
       foreach (auto s ; strings) {
           if (s !=3D "") {
               writefln("found: %s", s);
               result ~=3D s; }}}




=20
 This takes too much vertical space and should be rewritten to:
=20
 void func(string[] strings) {string[] result; foreach(auto s; strings){=




=20

 if (s !=3D "") { writefln("found: %s", s); result ~=3D s; }}}




Seriously, I fail to see how braces one their own line help visually catchi=
ng code structure (and it's not only me ;-)


 I wanted to say D allows even python-style formatting. Brace matching edi=


tor will help in syntactical differences.

That's similar what some Lisp/Scheme do ;-) Just add end/closing parens unt=
il your editor is happy (highlighting the first opening one).

Denis
-- -- -- -- -- -- --
vit esse estrany =E2=98=A3

spir.wikidot.com
Nov 23 2010
next sibling parent reply Max Samukha <spambox d-coding.com> writes:
On 11/23/2010 11:18 PM, spir wrote:

 Seriously, I fail to see how braces one their own line help visually catching
code structure


I agree that brace alignment has little to do with catching code 
structure. It is more about symmetry. And visual symmetry of braces in 
code is a matter of preference. I prefer symmetry. I have read and 
written quite a lot of code in various coding styles and aligned braces 
still look and feel cleaner to me, no matter how hard I try to be unbiased.

Regarding that vertical space argument, in my experience, big contiguous 
chunks of code are rarely read or written in one go (except when you are 
unlucky to read one of those just-get-the-job-done(TM) functions 
spreading a few dozens of screens). So saving vertical space is not a 
big concern in practice. And if you are using a good IDE, it is no 
concern at all.


 (and it's not only me


http://en.wikipedia.org/wiki/Argumentum_ad_populum
Nov 23 2010
parent spir <denis.spir gmail.com> writes:
On Wed, 24 Nov 2010 02:03:17 +0200
Max Samukha <spambox d-coding.com> wrote:


  > (and it's not only me =20
=20
 http://en.wikipedia.org/wiki/Argumentum_ad_populum


Good catch ;-)
(But I was not exactly pretending something to be true because more people =
think so -- instead that others also do not find braces-on-their-own-line h=
elpful).

Denis
-- -- -- -- -- -- --
vit esse estrany =E2=98=A3

spir.wikidot.com
Nov 24 2010
prev sibling parent sybrandy <sybrandy gmail.com> writes:
 Seriously, I fail to see how braces one their own line help visually catching
code structure (and it's not only me ;-)


For me, it really helps me make sure that I'm not missing a brace as I 
can see them line up visually.  It's easier to see the missing brace in 
code that looks like this:

if (condition)
{
    foo();
}

Than this:

if (condition) {
     foo();
}

Yes, this is a simplified case, but if you start multiple levels of 
nesting, it can be confusing.

Of course, a Erlang/Haskell/Python style indentation syntax does work, 
but then, IMHO, it works best if your functions are very small.  Of 
course, I've never done any Python development, however I have done 
Erlang and Haskell in the past and the fact that they really make it 
easier to write small functions helps a lot.

Smaller functions are better in all languages, but at least with code 
I've seen for Java and some D, methods can end up being fairly long.

Casey
Nov 24 2010
prev sibling next sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
bearophile <bearophileHUGS lycos.com> wrote:


 From what I'm seeing in D.learn there is a problem in the D community:=


  =


 some people seem irrationally attached to the idea they are free to  =



 write D code as they like. I have four or five times tried to explain =


 =


 why coding standards are important for the development of the D  =



 community, but it seems not everybody is understanding it.


First off, in your posts on D.learn, you come off as overzealous and
vindicatory, as if you are on a holy crusade for The One True Style=E2=84=
=A2.
This, I believe, is not a good way to greet newcomers.


That said, I agree there should be a One True Style=E2=84=A2, and here a=
re my
suggestions:

Make the style in three parts, where one is considered nigh obligatory,
and concerns public interface only. That is, names and structure.

The second part concerns only official D code. That is, if you want
your code in Phobos, make sure it follows these rules.

The third part should be guidelines to beautiful code. This is a
somewhat subjective measurement, and should be threated as such.


Whenever code is posted on the newsgroup that does not follow part 1,
feel free to suggest that the poster read the style guide. If it does
not follow part 2, leave it alone. If it blatantly violates the
intent of part 3, link to part 3.

-- =

Simen
Nov 23 2010
prev sibling parent Kagamin <spam here.lot> writes:
so Wrote:


 Eh.. their style maybe?



it more tasty.
BTW, .net framework doesn't follow it's style, it even mixes up to 3 different
naming conventions in the same class.
Nov 23 2010