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 =
caps
 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?
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
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
next sibling parent reply "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  
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...
A witch! May we burn it? -- Simen
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
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...
A witch! May we burn it?
Such a polite way of inciting a witch burning :)
Mar 06 2011
prev 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 parent reply 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.
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.
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
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.
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.
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 reply Jim <bitcirkel yahoo.com> writes:
Jonathan M Davis 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 caps
 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
All right, thanks for the courteous reply. Considering the other comments in this thread I think there isn't much interest in working out or agreeing on a few good principles or guidelines for naming identifiers in Phobos. Otherwise, even if we could only agree on a few of them, they could be written down somewhere, should anyone someday be inclined to join the development.
Mar 06 2011
next sibling parent Don <nospam nospam.com> writes:
Jim wrote:
 Jonathan M Davis 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 caps
 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
All right, thanks for the courteous reply. Considering the other comments in this thread I think there isn't much interest in working out or agreeing on a few good principles or guidelines for naming identifiers in Phobos. Otherwise, even if we could only agree on a few of them, they could be written down somewhere, should anyone someday be inclined to join the development.
All future modules will undergo a review process which will prevent the worst naming examples. We will need to initiate a review of existing modules at some point. Until that's completed, it would seem to be a bit counterproductive to publish a list of rules that 80% of Phobos modules break... But in general, I agree with you.
Mar 06 2011
prev sibling parent reply Jonas Drewsen <jdrewsen nospam.com> writes:
On 06/03/11 18.50, Jim wrote:
 Jonathan M Davis 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 caps
 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
All right, thanks for the courteous reply. Considering the other comments in this thread I think there isn't much interest in working out or agreeing on a few good principles or guidelines for naming identifiers in Phobos. Otherwise, even if we could only agree on a few of them, they could be written down somewhere, should anyone someday be inclined to join the development.
Funny you mention it. I was actually looking for such guidelines a couple of days ago on both digitalmars.com and d-programming-language. I ended up having to look at the phobos source code to get an idea of the style. So thumbs up from here on having such guidelines. /Jonas
Mar 07 2011
parent reply %u <wfunction hotmail.com> writes:
 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. I don't like the idea that enum values (which are constants) would also be camelCased; I think they should be PascalCased. Why? Simply because something like: enum InteropKind { import, export } won't compile. Furthermore, these aren't "variables" (they can't vary *at all*, even through casts -- unlike immutables) so I think enum values should be CamelCased. (PLEASE DO NOT USE ALL CAPS as it has no real benefit, and since it needlessly forces the use of underscores.) Another issue: Whatever the naming scheme is, please make sure that it's _specific enough_ that it won't conflict with other imports through reasonable use. E.g. don't make a function in std.path called getName() to get a file's name, because someone who's unaware of this could easily call getName() for a totally different module (say, hypothetically, on an Exception) and it would confuse the heck out of the reader. In this case, I'd say it should be getFileName(). If there's a lot of good choices, then I'd say that using a camelCased version of what Microsoft does in .NET would be a good idea; e.g. getFullPath(), isPathRooted(), getTempFileName(), getDirectoryName(), etc. Just my take on this... any thoughts?
Mar 07 2011
parent reply "Lars T. Kyllingstad" <public kyllingen.NOSPAMnet> writes:
On Mon, 07 Mar 2011 09:36:11 +0000, %u wrote:

 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. I don't like the idea that enum values (which are constants) would also be camelCased; I think they should be PascalCased. Why? Simply because something like: enum InteropKind { import, export } won't compile.
I don't think I understand your reasoning. Enum members can't have names which are also keywords, hence enums should be capitalised? You could equally well use this argument for *all* D symbols...
 Furthermore, these aren't "variables" (they can't vary
 *at all*, even through casts -- unlike immutables) so I think enum
 values should be CamelCased. (PLEASE DO NOT USE ALL CAPS as it has no
 real benefit, and since it needlessly forces the use of underscores.)
I don't think the distinction is between variables and non-variables. Rather, the distinction is between functions and values on one side and types on the other. Functions and values are camel-cased, while types are capitalised. That leaves the question about how to name templates. In Phobos, the rule is extended to templates as follows: camelCase: - function templates - templates that evaluate to values Capitalise: - mixin templates - class/struct templates -Lars -Lars
Mar 07 2011
parent reply %u <wfunction hotmail.com> writes:
 I don't think I understand your reasoning.  Enum members can't
have names which are also keywords, hence enums should be capitalised? You could equally well use this argument for *all* D symbols... symbol for marking keywords as identifiers). However, the thing is that this happens _so_ often with enums that I think it's worth making it an exception. As soon as you start to write some sort of code that has to do anything remotely with programming, you can say something like: enum TypeCode { int, long, bool } as those are the most logical choices (and thinking around them is a bit difficult.) But you don't often really name a variable "int", so it's not so much as an issue with variables as with enums IMHO.
Mar 08 2011
parent reply spir <denis.spir gmail.com> writes:
On 03/08/2011 11:00 AM, %u wrote:
 I don't think I understand your reasoning.  Enum members can't
have names which are also keywords, hence enums should be capitalised? You could equally well use this argument for *all* D symbols... symbol for marking keywords as identifiers). However, the thing is that this happens _so_ often with enums that I think it's worth making it an exception. As soon as you start to write some sort of code that has to do anything remotely with programming, you can say something like: enum TypeCode { int, long, bool } as those are the most logical choices (and thinking around them is a bit difficult.) But you don't often really name a variable "int", so it's not so much as an issue with variables as with enums IMHO.
Fortunately, these are "very not" any kind of <<most logical choices>>. Neither according to D's own naming convention, nore (imo) according to plain common sense. I have the same kind of use case as you, apparently (including even a 'TypeCodes' enum!), and thank to D's very weird naming, /I/ can use sensible names for enum members and various other symbol series, without resorting to a kind of prefix code or such. // same names as in the source language, thanx! enum TypeCodes { Integer, Real, Text, Logical, Array, ... } Denis -- _________________ vita es estrany spir.wikidot.com
Mar 08 2011
parent reply %u <wfunction hotmail.com> writes:
 Fortunately, these are "very not" any kind of <<most logical
choices>>. Neither according to D's own naming convention, nore (imo) according to plain common sense. I have the same kind of use case as you, apparently (including even a 'TypeCodes' enum!), and thank to D's very weird naming, /I/ can use sensible names for enum members and various other symbol series, without resorting to a kind of prefix code or such. // same names as in the source language, thanx! enum TypeCodes { Integer, Real, Text, Logical, Array, ... } Noticed that you capitalized "real", which would have collided with the keyword. (My point wasn't that "long" was the best name, but that this situation obviously occurs often enough to merit consideration of a different casing convention.)
Mar 08 2011
next sibling parent spir <denis.spir gmail.com> writes:
On 03/08/2011 07:28 PM, %u wrote:
 Fortunately, these are "very not" any kind of<<most logical
choices>>. Neither according to D's own naming convention, nore (imo) according to plain common sense. I have the same kind of use case as you, apparently (including even a 'TypeCodes' enum!), and thank to D's very weird naming, /I/ can use sensible names for enum members and various other symbol series, without resorting to a kind of prefix code or such. // same names as in the source language, thanx! enum TypeCodes { Integer, Real, Text, Logical, Array, ... } Noticed that you capitalized "real", which would have collided with the keyword. (My point wasn't that "long" was the best name, but that this situation obviously occurs often enough to merit consideration of a different casing convention.)
Right. Did not even know "Real" is a keyword ;-) (the above list is not copied from my 'real' code). Denis -- _________________ vita es estrany spir.wikidot.com
Mar 08 2011
prev sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Tuesday, March 08, 2011 10:28:11 %u wrote:
 Fortunately, these are "very not" any kind of <<most logical
choices>>. Neither according to D's own naming convention, nore (imo) according to plain common sense. I have the same kind of use case as you, apparently (including even a 'TypeCodes' enum!), and thank to D's very weird naming, /I/ can use sensible names for enum members and various other symbol series, without resorting to a kind of prefix code or such. // same names as in the source language, thanx! enum TypeCodes { Integer, Real, Text, Logical, Array, ... } Noticed that you capitalized "real", which would have collided with the keyword. (My point wasn't that "long" was the best name, but that this situation obviously occurs often enough to merit consideration of a different casing convention.)
I have _never_ needed to use a primitive type's name (which is obviously a keyword) in an enum. _Never_. I'd be very surprised if Phobos ever needed to. I have a _very_ hard time believing that this is a common thing to do. And if type codes is your example, well type codes are generally considered to be bad practice, so I don't really see them as much of a supporting argument. Regardless, no matter what your naming conventions are, you're going to run into places where they don't work quite as well as you'd like. The naming conventions that we've been using for Phobos have generally been working quite well. The problem is generally that older Phobos code doesn't follow them, but that's slowly being fixed. What we've been doing works. And while I think that D code in general should follow similar naming conventions, you _are_ perfectly free to use whatever naming conventions you like in your own code. - Jonathan M Davis
Mar 08 2011
prev sibling next sibling parent Emil Madsen <sovende gmail.com> writes:
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
caps
 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
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