www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Naming convention in Phobos

reply Jim <bitcirkel yahoo.com> writes:
Okay, so there's a discussion about identifier names in the proposed std.path
replacement -- should they be abbreviated or not?
Should we perhaps seek to have a consistent naming convention for all
identifier names in Phobos?


Some of the potential benefits:

 Legibility, understandability and clarity (reduce ambiguity).
 Ease in finding a suitable function/class by name.
 Knowing if it's a cheap or costly function call.
 Aesthetics and professional appearance.


Some properties that I can think of for discussion:

 Abbreviation (and if so, what to abbreviate and how much)?
 Preference of commonly used terms in other languages, contexts?
 Use of get and set prefixes or not (getName() or simply name())?
 Explicit use of a prefix (example: calc or calculate) for costly operations?
 Naming of function and template arguments?
 Uppercase, lowercase, camelcase, underscore in multi-word names? All caps for
constants, or different appearance for different types (types, functions,
arguments, constants...). What about acronyms: TCP, Tcp?

Are there other concerns?
Mar 06 2011
next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Sunday 06 March 2011 02:59:25 Jim wrote:
 Okay, so there's a discussion about identifier names in the proposed
 std.path replacement -- should they be abbreviated or not? Should we
 perhaps seek to have a consistent naming convention for all identifier
 names in Phobos?
=20
=20
 Some of the potential benefits:
=20
 =95 Legibility, understandability and clarity (reduce ambiguity).
 =95 Ease in finding a suitable function/class by name.
 =95 Knowing if it's a cheap or costly function call.
 =95 Aesthetics and professional appearance.
=20
=20
 Some properties that I can think of for discussion:
=20
 =95 Abbreviation (and if so, what to abbreviate and how much)?
 =95 Preference of commonly used terms in other languages, contexts?
 =95 Use of get and set prefixes or not (getName() or simply name())?
 =95 Explicit use of a prefix (example: calc or calculate) for costly
 operations? =95 Naming of function and template arguments?
 =95 Uppercase, lowercase, camelcase, underscore in multi-word names? All =

 for constants, or different appearance for different types (types,
 functions, arguments, constants...). What about acronyms: TCP, Tcp?
=20
 Are there other concerns?

The general naming convention as far as variable names go is camelcased wit= h the=20 name starting with a lower case letter - this includes constants. Most of P= hobos=20 follows this, and the parts that haven't been have been moving towards it. = There=20 are likely to be a few exceptions, but on the whole, that's how it's suppos= ed to=20 be. Type names are the same, except they start with an upper case letter (t= his=20 includes enum names - the enum values are capitalized the same as any other= =20 variables however). That's the way it has been, and that's the way that it'= s=20 pretty much guaranteed to stay. Generally speaking, we want descriptive names, and I think that it's safe t= o say=20 that we don't want overly long names, so if we can have descriptive but sho= rt=20 names, that's generally best. get and set prefixes are likely to be rare, b= ecause=20 most of such functions will be properties, and properties will normally hav= e=20 nouns for names and won't use get or set, but I don't think that we want to= say=20 that we'll _never_ have function names prefixed with get or set. Normally, = we=20 won't, but it's going to be very situation-dependent. Now, as for the rest of it, I don't really want to get into a big discussio= n of=20 the best way to name everything. It's far too context-dependent and very qu= ickly=20 turns towards bike shedding. I think that it's appropriate for anyone who's= =20 developing a module for Phobos to come up with names that they think are=20 reasonable and which follow the very basic naming conventions that we follo= w,=20 and then have names adjusted as needed during the review process. I really = don't=20 think that we're going to get much of value by having a big discussion over= =20 general naming conventions. It seems to me like it's just going to be a cla= ssic=20 situation for bike shedding and generally useless discussion. What we've be= en=20 doing generally works just fine. =2D Jonathan M Davis
Mar 06 2011
prev sibling next sibling parent dolive <dolive89 sina.com> writes:
Jim Wrote:

 Okay, so there's a discussion about identifier names in the proposed std.path
replacement -- should they be abbreviated or not?
 Should we perhaps seek to have a consistent naming convention for all
identifier names in Phobos?
 
 
 Some of the potential benefits:
 
  Legibility, understandability and clarity (reduce ambiguity).
  Ease in finding a suitable function/class by name.
  Knowing if it's a cheap or costly function call.
  Aesthetics and professional appearance.
 
 
 Some properties that I can think of for discussion:
 
  Abbreviation (and if so, what to abbreviate and how much)?
  Preference of commonly used terms in other languages, contexts?
  Use of get and set prefixes or not (getName() or simply name())?
  Explicit use of a prefix (example: calc or calculate) for costly operations?
  Naming of function and template arguments?
  Uppercase, lowercase, camelcase, underscore in multi-word names? All caps
for constants, or different appearance for different types (types, functions,
arguments, constants...). What about acronyms: TCP, Tcp?
 
 Are there other concerns?

&#38750;&#24120;&#36190;&#21516;&#65292;&#23613;&#37327;&#19981;&#20351;&#29992;&#38271;&#21517;&#31216;&#20294;&#20063;&#19981;&#25490;&#26021;&#65292;&#23398;&#20064;java&#21629;&#21517;&#21746;&#23398;&#65292;&#35753;&#20840;&#19990;&#30028;&#37117;&#30475;&#24471;&#25026;&#65288;&#38750;&#33521;&#35821;&#22269;&#23478;&#65289; &#22914;&#26524;&#26377;&#22810;&#20010;&#21516;&#20041;&#35789;&#65292;&#35831;&#20351;&#29992;&#35789;&#39057;&#26356;&#39640;&#30340; Very much in favor! Try not to use the long name But not exclusive, Learning java naming philosophy, If you have multiple synonyms, Please use the word frequency higher, Let the whole world are able to understand (non-English speaking countries) thank you very much! dolive
Mar 06 2011
prev sibling next sibling parent dolive <dolive89 sina.com> writes:
Jim Wrote:

 Okay, so there's a discussion about identifier names in the proposed std.path
replacement -- should they be abbreviated or not?
 Should we perhaps seek to have a consistent naming convention for all
identifier names in Phobos?
 
 
 Some of the potential benefits:
 
  Legibility, understandability and clarity (reduce ambiguity).
  Ease in finding a suitable function/class by name.
  Knowing if it's a cheap or costly function call.
  Aesthetics and professional appearance.
 
 
 Some properties that I can think of for discussion:
 
  Abbreviation (and if so, what to abbreviate and how much)?
  Preference of commonly used terms in other languages, contexts?
  Use of get and set prefixes or not (getName() or simply name())?
  Explicit use of a prefix (example: calc or calculate) for costly operations?
  Naming of function and template arguments?
  Uppercase, lowercase, camelcase, underscore in multi-word names? All caps
for constants, or different appearance for different types (types, functions,
arguments, constants...). What about acronyms: TCP, Tcp?
 
 Are there other concerns?

Phobos naming convention should be a major adjustment! thanks all ! dolive
Mar 06 2011
prev sibling next sibling parent reply "Nick Sabalausky" <a a.a> writes:
"Jim" <bitcirkel yahoo.com> wrote in message 
news:ikvped$1o35$1 digitalmars.com...
 Okay, so there's a discussion about identifier names in the proposed 
 std.path replacement -- should they be abbreviated or not?
 Should we perhaps seek to have a consistent naming convention for all 
 identifier names in Phobos?


 Some of the potential benefits:

  Legibility, understandability and clarity (reduce ambiguity).
  Ease in finding a suitable function/class by name.
  Knowing if it's a cheap or costly function call.
  Aesthetics and professional appearance.


 Some properties that I can think of for discussion:

  Abbreviation (and if so, what to abbreviate and how much)?
  Preference of commonly used terms in other languages, contexts?
  Use of get and set prefixes or not (getName() or simply name())?
  Explicit use of a prefix (example: calc or calculate) for costly 
 operations?
  Naming of function and template arguments?
  Uppercase, lowercase, camelcase, underscore in multi-word names? All 
 caps for constants, or different appearance for different types (types, 
 functions, arguments, constants...). What about acronyms: TCP, Tcp?

 Are there other concerns?

I think that every individual variable, function and type in Phobos should use the naming convention of whatever random language the author happened to be thinking of when they wrote it. That way Phobos won't seem messy. Plus, the lack of any sensible rules would make it super-easy to remember all the different spellings, punctuations and capitalizations.
Mar 06 2011
next sibling parent reply foobar <foo bar.com> writes:
Nick Sabalausky Wrote:

 "Jim" <bitcirkel yahoo.com> wrote in message 
 news:ikvped$1o35$1 digitalmars.com...
 Okay, so there's a discussion about identifier names in the proposed 
 std.path replacement -- should they be abbreviated or not?
 Should we perhaps seek to have a consistent naming convention for all 
 identifier names in Phobos?


 Some of the potential benefits:

  Legibility, understandability and clarity (reduce ambiguity).
  Ease in finding a suitable function/class by name.
  Knowing if it's a cheap or costly function call.
  Aesthetics and professional appearance.


 Some properties that I can think of for discussion:

  Abbreviation (and if so, what to abbreviate and how much)?
  Preference of commonly used terms in other languages, contexts?
  Use of get and set prefixes or not (getName() or simply name())?
  Explicit use of a prefix (example: calc or calculate) for costly 
 operations?
  Naming of function and template arguments?
  Uppercase, lowercase, camelcase, underscore in multi-word names? All 
 caps for constants, or different appearance for different types (types, 
 functions, arguments, constants...). What about acronyms: TCP, Tcp?

 Are there other concerns?

I think that every individual variable, function and type in Phobos should use the naming convention of whatever random language the author happened to be thinking of when they wrote it. That way Phobos won't seem messy. Plus, the lack of any sensible rules would make it super-easy to remember all the different spellings, punctuations and capitalizations.

I would also add to the above excellent point that in order to prevent unworthy people of programming in the holly D programming language we must require every D programmer to be fluent in English, Latin and Greek (including cultural references to movies and such), have *at least* expert Unix hacking credentials, have a certified MSFT engineering diploma, be Guru level programmers in all of the following: c, c++, Haskell, Perl, APL, LISP, ALGOL and COBOL. AND, lest we forget, they must code ONLY in a terminal based text-editor with 80 character wide lines.
Mar 06 2011
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/6/11 9:27 AM, foobar wrote:
 Nick Sabalausky Wrote:

 "Jim"<bitcirkel yahoo.com>  wrote in message
 news:ikvped$1o35$1 digitalmars.com...
 Okay, so there's a discussion about identifier names in the proposed
 std.path replacement -- should they be abbreviated or not?
 Should we perhaps seek to have a consistent naming convention for all
 identifier names in Phobos?


 Some of the potential benefits:

  Legibility, understandability and clarity (reduce ambiguity).
  Ease in finding a suitable function/class by name.
  Knowing if it's a cheap or costly function call.
  Aesthetics and professional appearance.


 Some properties that I can think of for discussion:

  Abbreviation (and if so, what to abbreviate and how much)?
  Preference of commonly used terms in other languages, contexts?
  Use of get and set prefixes or not (getName() or simply name())?
  Explicit use of a prefix (example: calc or calculate) for costly
 operations?
  Naming of function and template arguments?
  Uppercase, lowercase, camelcase, underscore in multi-word names? All
 caps for constants, or different appearance for different types (types,
 functions, arguments, constants...). What about acronyms: TCP, Tcp?

 Are there other concerns?

I think that every individual variable, function and type in Phobos should use the naming convention of whatever random language the author happened to be thinking of when they wrote it. That way Phobos won't seem messy. Plus, the lack of any sensible rules would make it super-easy to remember all the different spellings, punctuations and capitalizations.

I would also add to the above excellent point that in order to prevent unworthy people of programming in the holly

You have a typo there. Andrei
Mar 06 2011
parent reply foobar <foo bar.com> writes:
Andrei Alexandrescu Wrote:

 On 3/6/11 9:27 AM, foobar wrote:
 Nick Sabalausky Wrote:

 "Jim"<bitcirkel yahoo.com>  wrote in message
 news:ikvped$1o35$1 digitalmars.com...
 Okay, so there's a discussion about identifier names in the proposed
 std.path replacement -- should they be abbreviated or not?
 Should we perhaps seek to have a consistent naming convention for all
 identifier names in Phobos?


 Some of the potential benefits:

  Legibility, understandability and clarity (reduce ambiguity).
  Ease in finding a suitable function/class by name.
  Knowing if it's a cheap or costly function call.
  Aesthetics and professional appearance.


 Some properties that I can think of for discussion:

  Abbreviation (and if so, what to abbreviate and how much)?
  Preference of commonly used terms in other languages, contexts?
  Use of get and set prefixes or not (getName() or simply name())?
  Explicit use of a prefix (example: calc or calculate) for costly
 operations?
  Naming of function and template arguments?
  Uppercase, lowercase, camelcase, underscore in multi-word names? All
 caps for constants, or different appearance for different types (types,
 functions, arguments, constants...). What about acronyms: TCP, Tcp?

 Are there other concerns?

I think that every individual variable, function and type in Phobos should use the naming convention of whatever random language the author happened to be thinking of when they wrote it. That way Phobos won't seem messy. Plus, the lack of any sensible rules would make it super-easy to remember all the different spellings, punctuations and capitalizations.

I would also add to the above excellent point that in order to prevent unworthy people of programming in the holly

You have a typo there. Andrei

Well than I must be unworthy of the D community. I must flee before you come chasing me with pitchforks...
Mar 06 2011
parent "Nick Sabalausky" <a a.a> writes:
"Simen kjaeraas" <simen.kjaras gmail.com> wrote in message 
news:op.vrxix902vxi10f biotronic-laptop...
 foobar <foo bar.com> wrote:

 I would also add to the above excellent point that in order to

You have a typo there. Andrei

Well than I must be unworthy of the D community. I must flee before you come chasing me with pitchforks...

A witch! May we burn it?

Such a polite way of inciting a witch burning :)
Mar 06 2011
prev sibling parent foobar <foo bar.com> writes:
spir Wrote:

 On 03/06/2011 04:27 PM, foobar wrote:
 Are there other concerns?

  I think that every individual variable, function and type in Phobos should
  use the naming convention of whatever random language the author happened to
  be thinking of when they wrote it. That way Phobos won't seem messy. Plus,
  the lack of any sensible rules would make it super-easy to remember all the
  different spellings, punctuations and capitalizations.


AND, lest we forget, they must code ONLY in a terminal based text-editor with 80 character wide lines.

Thus, if I understand correctly, the D community finally let down all prerequisites in fields of mathematical logics, philosophy of language, and metaphysics of automata? Or what? Denis -- _________________ vita es estrany spir.wikidot.com

Oh my, I forgot those! Don't be silly, The D prerequisites can only grow. It is cosmologically impossible to remove anything since it is written in punch-cards (which is worse than writing in stones).
Mar 06 2011
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On 03/06/2011 04:27 PM, foobar wrote:
 Are there other concerns?

  I think that every individual variable, function and type in Phobos should
  use the naming convention of whatever random language the author happened to
  be thinking of when they wrote it. That way Phobos won't seem messy. Plus,
  the lack of any sensible rules would make it super-easy to remember all the
  different spellings, punctuations and capitalizations.


AND, lest we forget, they must code ONLY in a terminal based text-editor with 80 character wide lines.

Thus, if I understand correctly, the D community finally let down all prerequisites in fields of mathematical logics, philosophy of language, and metaphysics of automata? Or what? Denis -- _________________ vita es estrany spir.wikidot.com
Mar 06 2011
prev sibling parent "Simen kjaeraas" <simen.kjaras gmail.com> writes:
foobar <foo bar.com> wrote:

 I would also add to the above excellent point that in order to  

You have a typo there. Andrei

Well than I must be unworthy of the D community. I must flee before you come chasing me with pitchforks...

A witch! May we burn it? -- Simen
Mar 06 2011
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On 03/06/2011 04:54 PM, foobar wrote:
 Andrei Alexandrescu Wrote:

 On 3/6/11 9:27 AM, foobar wrote:
 Nick Sabalausky Wrote:

 "Jim"<bitcirkel yahoo.com>   wrote in message
 news:ikvped$1o35$1 digitalmars.com...
 Okay, so there's a discussion about identifier names in the proposed
 std.path replacement -- should they be abbreviated or not?
 Should we perhaps seek to have a consistent naming convention for all
 identifier names in Phobos?


 Some of the potential benefits:

 • Legibility, understandability and clarity (reduce ambiguity).
 • Ease in finding a suitable function/class by name.
 • Knowing if it's a cheap or costly function call.
 • Aesthetics and professional appearance.


 Some properties that I can think of for discussion:

 • Abbreviation (and if so, what to abbreviate and how much)?
 • Preference of commonly used terms in other languages, contexts?
 • Use of get and set prefixes or not (getName() or simply name())?
 • Explicit use of a prefix (example: calc or calculate) for costly
 operations?
 • Naming of function and template arguments?
 • Uppercase, lowercase, camelcase, underscore in multi-word names? All
 caps for constants, or different appearance for different types (types,
 functions, arguments, constants...). What about acronyms: TCP, Tcp?

 Are there other concerns?

I think that every individual variable, function and type in Phobos should use the naming convention of whatever random language the author happened to be thinking of when they wrote it. That way Phobos won't seem messy. Plus, the lack of any sensible rules would make it super-easy to remember all the different spellings, punctuations and capitalizations.

I would also add to the above excellent point that in order to prevent unworthy people of programming in the holly

You have a typo there. Andrei

Well than I must be unworthy of the D community. I must flee before you come chasing me with pitchforks...

...or anathems Denis -- _________________ vita es estrany spir.wikidot.com
Mar 06 2011
prev sibling next sibling parent Emil Madsen <sovende gmail.com> writes:
--0016364c7d316f1588049e012b5c
Content-Type: text/plain; charset=ISO-8859-1

On 6 March 2011 12:38, Jonathan M Davis <jmdavisProg gmx.com> wrote:

 On Sunday 06 March 2011 02:59:25 Jim wrote:
 Okay, so there's a discussion about identifier names in the proposed
 std.path replacement -- should they be abbreviated or not? Should we
 perhaps seek to have a consistent naming convention for all identifier
 names in Phobos?


 Some of the potential benefits:

   Legibility, understandability and clarity (reduce ambiguity).
   Ease in finding a suitable function/class by name.
   Knowing if it's a cheap or costly function call.
   Aesthetics and professional appearance.


 Some properties that I can think of for discussion:

   Abbreviation (and if so, what to abbreviate and how much)?
   Preference of commonly used terms in other languages, contexts?
   Use of get and set prefixes or not (getName() or simply name())?
   Explicit use of a prefix (example: calc or calculate) for costly
 operations?   Naming of function and template arguments?
   Uppercase, lowercase, camelcase, underscore in multi-word names? All

 for constants, or different appearance for different types (types,
 functions, arguments, constants...). What about acronyms: TCP, Tcp?

 Are there other concerns?

The general naming convention as far as variable names go is camelcased with the name starting with a lower case letter - this includes constants. Most of Phobos follows this, and the parts that haven't been have been moving towards it. There are likely to be a few exceptions, but on the whole, that's how it's supposed to be. Type names are the same, except they start with an upper case letter (this includes enum names - the enum values are capitalized the same as any other variables however). That's the way it has been, and that's the way that it's pretty much guaranteed to stay. Generally speaking, we want descriptive names, and I think that it's safe to say that we don't want overly long names, so if we can have descriptive but short names, that's generally best. get and set prefixes are likely to be rare, because most of such functions will be properties, and properties will normally have nouns for names and won't use get or set, but I don't think that we want to say that we'll _never_ have function names prefixed with get or set. Normally, we won't, but it's going to be very situation-dependent. Now, as for the rest of it, I don't really want to get into a big discussion of the best way to name everything. It's far too context-dependent and very quickly turns towards bike shedding. I think that it's appropriate for anyone who's developing a module for Phobos to come up with names that they think are reasonable and which follow the very basic naming conventions that we follow, and then have names adjusted as needed during the review process. I really don't think that we're going to get much of value by having a big discussion over general naming conventions. It seems to me like it's just going to be a classic situation for bike shedding and generally useless discussion. What we've been doing generally works just fine. - Jonathan M Davis

Just a thought, is there some sort of tool whats able to check if a code follow these standards? And if its the case, why isn't it used? - so people are forced to conform to the coding standard before being able to commit anything. -- // Yours sincerely // Emil 'Skeen' Madsen --0016364c7d316f1588049e012b5c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On 6 March 2011 12:38, Jonathan M Davis <span di= r=3D"ltr">&lt;<a href=3D"mailto:jmdavisProg gmx.com">jmdavisProg gmx.com</a=
&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 =

<div><div></div><div class=3D"h5">On Sunday 06 March 2011 02:59:25 Jim wrot= e:<br> &gt; Okay, so there&#39;s a discussion about identifier names in the propos= ed<br> &gt; std.path replacement -- should they be abbreviated or not? Should we<b= r> &gt; perhaps seek to have a consistent naming convention for all identifier= <br> &gt; names in Phobos?<br> &gt;<br> &gt;<br> &gt; Some of the potential benefits:<br> &gt;<br> &gt; =A0 Legibility, understandability and clarity (reduce ambiguity).<br> &gt; =A0 Ease in finding a suitable function/class by name.<br> &gt; =A0 Knowing if it&#39;s a cheap or costly function call.<br> &gt; =A0 Aesthetics and professional appearance.<br> &gt;<br> &gt;<br> &gt; Some properties that I can think of for discussion:<br> &gt;<br> &gt; =A0 Abbreviation (and if so, what to abbreviate and how much)?<br> &gt; =A0 Preference of commonly used terms in other languages, contexts?<br=

r> &gt; =A0 Explicit use of a prefix (example: calc or calculate) for costly<b= r> &gt; operations? =A0 Naming of function and template arguments?<br> &gt; =A0 Uppercase, lowercase, camelcase, underscore in multi-word names? A= ll caps<br> &gt; for constants, or different appearance for different types (types,<br> &gt; functions, arguments, constants...). What about acronyms: TCP, Tcp?<br=

&gt; Are there other concerns?<br> <br> </div></div>The general naming convention as far as variable names go is ca= melcased with the<br> name starting with a lower case letter - this includes constants. Most of P= hobos<br> follows this, and the parts that haven&#39;t been have been moving towards = it. There<br> are likely to be a few exceptions, but on the whole, that&#39;s how it&#39;= s supposed to<br> be. Type names are the same, except they start with an upper case letter (t= his<br> includes enum names - the enum values are capitalized the same as any other= <br> variables however). That&#39;s the way it has been, and that&#39;s the way = that it&#39;s<br> pretty much guaranteed to stay.<br> <br> Generally speaking, we want descriptive names, and I think that it&#39;s sa= fe to say<br> that we don&#39;t want overly long names, so if we can have descriptive but= short<br> names, that&#39;s generally best. get and set prefixes are likely to be rar= e, because<br> most of such functions will be properties, and properties will normally hav= e<br> nouns for names and won&#39;t use get or set, but I don&#39;t think that we= want to say<br> that we&#39;ll _never_ have function names prefixed with get or set. Normal= ly, we<br> won&#39;t, but it&#39;s going to be very situation-dependent.<br> <br> Now, as for the rest of it, I don&#39;t really want to get into a big discu= ssion of<br> the best way to name everything. It&#39;s far too context-dependent and ver= y quickly<br> turns towards bike shedding. I think that it&#39;s appropriate for anyone w= ho&#39;s<br> developing a module for Phobos to come up with names that they think are<br=

w,<br> and then have names adjusted as needed during the review process. I really = don&#39;t<br> think that we&#39;re going to get much of value by having a big discussion = over<br> general naming conventions. It seems to me like it&#39;s just going to be a= classic<br> situation for bike shedding and generally useless discussion. What we&#39;v= e been<br> doing generally works just fine.<br> <font color=3D"#888888"><br> - Jonathan M Davis<br> </font></blockquote></div><br>Just a=A0thought, is there some sort of tool = whats able to check if a code follow these standards?<div>And if its the ca= se, why isn&#39;t it used? - so people are forced to conform to the coding = standard before being able to commit anything.<br clear=3D"all"> <br>-- <br>// Yours sincerely<br>// Emil &#39;Skeen&#39; Madsen<br> </div> --0016364c7d316f1588049e012b5c--
Mar 08 2011
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, March 08, 2011 15:42:47 Emil Madsen wrote:
 Just a thought, is there some sort of tool whats able to check if a code
 follow these standards?
 And if its the case, why isn't it used? - so people are forced to conform
 to the coding standard before being able to commit anything.

No one is forced to conform to any standard. You can code however you like. Now, if you're submitting code to Phobos, it should follow Phobos' naming conventions, and perhaps we should do a better job about making those clear, but for the most part, anyone working on Phobos is already aware of them. Tools do exist to check style conformance for a variety of languages. I'm not aware of any which exist for D at present, but you might be able to coerce one for a language like C++ to do it. Regardless, it's not like the D community at large is being forced to follow the same naming conventions in their code that Phobos is using. I'd say that it's _preferred_ that they do for general code readability and such, but everyone is free to use whatever naming conventions that they prefer in their own code. Neither the lanugage no the compiler forces any sort of naming conventions on anyone beyond the basic rules of which characters an identifier can contain and that an identifier can't be a keyword. - Jonathan M Davis
Mar 08 2011