digitalmars.D - Naming convention in Phobos
- Jim <bitcirkel yahoo.com> Mar 06 2011
- Jonathan M Davis <jmdavisProg gmx.com> Mar 06 2011
- dolive <dolive89 sina.com> Mar 06 2011
- dolive <dolive89 sina.com> Mar 06 2011
- "Nick Sabalausky" <a a.a> Mar 06 2011
- foobar <foo bar.com> Mar 06 2011
- Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> Mar 06 2011
- foobar <foo bar.com> Mar 06 2011
- "Nick Sabalausky" <a a.a> Mar 06 2011
- foobar <foo bar.com> Mar 06 2011
- spir <denis.spir gmail.com> Mar 06 2011
- "Simen kjaeraas" <simen.kjaras gmail.com> Mar 06 2011
- spir <denis.spir gmail.com> Mar 06 2011
- Emil Madsen <sovende gmail.com> Mar 08 2011
- Jonathan M Davis <jmdavisProg gmx.com> Mar 08 2011
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
Jonathan M Davis <jmdavisProg gmx.com> 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
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?
非常赞同，尽量不使用长名称但也不排斥，学习java命名哲学，让全世界都看得懂（非英语国家） 如果有多个同义词，请使用词频更高的 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
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
"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
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
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
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
"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
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
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
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
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
--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"><<a href=3D"mailto:jmdavisProg gmx.com">jmdavisProg gmx.com</a=></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> > Okay, so there's a discussion about identifier names in the propos= ed<br> > std.path replacement -- should they be abbreviated or not? Should we<b= r> > perhaps seek to have a consistent naming convention for all identifier= <br> > names in Phobos?<br> ><br> ><br> > Some of the potential benefits:<br> ><br> > =A0 Legibility, understandability and clarity (reduce ambiguity).<br> > =A0 Ease in finding a suitable function/class by name.<br> > =A0 Knowing if it's a cheap or costly function call.<br> > =A0 Aesthetics and professional appearance.<br> ><br> ><br> > Some properties that I can think of for discussion:<br> ><br> > =A0 Abbreviation (and if so, what to abbreviate and how much)?<br> > =A0 Preference of commonly used terms in other languages, contexts?<br=
r> > =A0 Explicit use of a prefix (example: calc or calculate) for costly<b= r> > operations? =A0 Naming of function and template arguments?<br> > =A0 Uppercase, lowercase, camelcase, underscore in multi-word names? A= ll caps<br> > for constants, or different appearance for different types (types,<br> > functions, arguments, constants...). What about acronyms: TCP, Tcp?<br=
> 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't been have been moving towards = it. There<br> are likely to be a few exceptions, but on the whole, that's how it'= 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's the way it has been, and that's the way = that it's<br> pretty much guaranteed to stay.<br> <br> Generally speaking, we want descriptive names, and I think that it's sa= fe to say<br> that we don't want overly long names, so if we can have descriptive but= short<br> names, that'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't use get or set, but I don't think that we= want to say<br> that we'll _never_ have function names prefixed with get or set. Normal= ly, we<br> won't, but it's going to be very situation-dependent.<br> <br> Now, as for the rest of it, I don't really want to get into a big discu= ssion of<br> the best way to name everything. It's far too context-dependent and ver= y quickly<br> turns towards bike shedding. I think that it's appropriate for anyone w= ho'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't<br> think that we're going to get much of value by having a big discussion = over<br> general naming conventions. It seems to me like it's just going to be a= classic<br> situation for bike shedding and generally useless discussion. What we'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'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 'Skeen' Madsen<br> </div> --0016364c7d316f1588049e012b5c--
Mar 08 2011
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