www.digitalmars.com         C & C++   DMDScript  

D - Naming conventions

reply "Matthew Wilson" <matthew stlsoft.org> writes:
Any chance on our standardising on lowercase for modules, and UpperCase for
Classes? (Naturally there'd be exceptions, such as c.stdio.)

If not, I'd be interested to hear of suggestions for a good convention. For
example, I don't think many would suggest that having the same name and
capitalisation for a module and a class (e.g. the module "d.win32.registry"
and the class "registry") is a good thing.
Sep 19 2003
next sibling parent reply "Julio CÚsar Carrascal Urquijo" <adnoctum phreaker.net> writes:
 example, I don't think many would suggest that having the same name and
 capitalisation for a module and a class (e.g. the module

 and the class "registry") is a good thing.

Why not? Module and classes are conceptualy the same thing (another name scope) and work pretty much the same (except for instantiation). I vote for MixedCase convention for modules and classes and lowerUpperCase for methods, types and variables. Keywords already use lowerUpperCase and that provides lots of conflicts: import win32.module; That's my opinion but i'll use whatever is decided here anyway. Cheers.
Sep 19 2003
parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
"Julio CÚsar Carrascal Urquijo" <adnoctum phreaker.net> wrote in message
news:bkgk1j$2mtv$2 digitaldaemon.com...
 example, I don't think many would suggest that having the same name and
 capitalisation for a module and a class (e.g. the module

 and the class "registry") is a good thing.

Why not? Module and classes are conceptualy the same thing (another name scope) and work pretty much the same (except for instantiation).

How are modules and classes the same thing. I've heard this many times within C++, but I just can't see it. Persuade me (if you can!).
 I vote for MixedCase convention for modules and classes and lowerUpperCase
 for methods, types and variables.

Sorry. Strongly disagree. What's the virtue in not being able to distinguish between methods/types and variables? lowerUpperCase should be only for variables.
 Keywords already use lowerUpperCase and that provides lots of conflicts:

 import win32.module;

That's a fair point. I doubt anyone else'll ever be persuaded to have uppercase keywords, though.
 That's my opinion but i'll use whatever is decided here anyway.

Well, there's not a single perfect answer, simple because there are only two cases, and a limited number of ways of mixing those cases. As we've just seen, two people have radically disagreed about two things. Heaven knows how many opinions there'll be once a few more jump in.
Sep 19 2003
next sibling parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bkgkvc$2qv4$1 digitaldaemon.com...
 "Julio CÚsar Carrascal Urquijo" <adnoctum phreaker.net> wrote in message
 news:bkgk1j$2mtv$2 digitaldaemon.com...
 example, I don't think many would suggest that having the same name



 capitalisation for a module and a class (e.g. the module

 and the class "registry") is a good thing.

Why not? Module and classes are conceptualy the same thing (another name scope) and work pretty much the same (except for instantiation).

How are modules and classes the same thing. I've heard this many times within C++, but I just can't see it. Persuade me (if you can!).

A module is a class that is all static. It's as close as you can get to a singleton as there is.
 I vote for MixedCase convention for modules and classes and


 for methods, types and variables.

Sorry. Strongly disagree. What's the virtue in not being able to

 between methods/types and variables? lowerUpperCase should be only for
 variables.

I use this style.
 Keywords already use lowerUpperCase and that provides lots of conflicts:

 import win32.module;

That's a fair point. I doubt anyone else'll ever be persuaded to have uppercase keywords, though.

What if the identifiers were not case sensitive, unless they were single letter identifiers?
 That's my opinion but i'll use whatever is decided here anyway.

Well, there's not a single perfect answer, simple because there are only

 cases, and a limited number of ways of mixing those cases. As we've just
 seen, two people have radically disagreed about two things. Heaven knows

 many opinions there'll be once a few more jump in.

Wheeee!!! Sean
Sep 19 2003
prev sibling next sibling parent reply "Hauke Duden" <H.NS.Duden gmx.net> writes:
"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bkgkvc$2qv4$1 digitaldaemon.com...
 I vote for MixedCase convention for modules and classes and


 for methods, types and variables.

Sorry. Strongly disagree. What's the virtue in not being able to

 between methods/types and variables? lowerUpperCase should be only for
 variables.

Actually, I think lowerUpperCase should also be used for methods (not types, though). Method calls are immediately recognizable by the brackets that follow them. I'd rather save pure UpperCase for classes only. And besides: in D the difference between methods and variables is starting to vanish with the new gettor and settor methods. One more reason why they should be named in a similar way. May I suggest another radical thing (I hope I'm not getting banned for this ;))? How about CClass, IInterface and TTemplateClass? I know that many people see it as too Microsoft-ish, but I have found it useful in the past to be able to easily distingusih interfaces, classes and template classes. They are all used in a different way. For example, templates are instantiated in a different way than simple classes (needing template parameters) and interfaces cannot be instantiated at all. Hmmm. I don't have much experience with D structs, but maybe it is also a good idea to name them differently than classes? Depends on wether their differences really cause them to be used in distinguished ways. Hauke
Sep 20 2003
parent reply Benji Smith <dlanguage xxagg.com> writes:
On Sat, 20 Sep 2003 12:32:21 +0200, "Hauke Duden" <H.NS.Duden gmx.net>
wrote:

How about CClass, IInterface and TTemplateClass? I know that many people see
it as too Microsoft-ish, but I have found it useful in the past to be able
to easily distingusih interfaces, classes and template classes. They are all
used in a different way. For example, templates are instantiated in a
different way than simple classes (needing template parameters) and
interfaces cannot be instantiated at all.

I usually use IXxxxxXxxxx and TXxxxxxXxxxx for interfaces and templates, since I think it helps distinguish them just a little bit, but I think that CXxxxxXxxxx for classes is a little bit too much. The I and T prefixes for interfaces and templates are there to _distinguish_ them from classes, which, in my opinion, is the default assumption.
Sep 22 2003
next sibling parent Hauke Duden <H.NS.Duden gmx.net> writes:
Benji Smith wrote:
 I usually use IXxxxxXxxxx and TXxxxxxXxxxx for interfaces and
 templates, since I think it helps distinguish them just a little bit,
 but I think that CXxxxxXxxxx for classes is a little bit too much. The
 I and T prefixes for interfaces and templates are there to
 _distinguish_ them from classes, which, in my opinion, is the default
 assumption.

I could live with that, as long as interfaces and templates are instantly recognizable. I use the C prefix mostly because then I can use MixedCase for constants. I just hate UPPERCASE and UPPER_CASE - they take long to type and are pretty hard to read. Hauke
Sep 22 2003
prev sibling parent reply Helmut Leitner <leitner hls.via.at> writes:
Benji Smith wrote:
 
 On Sat, 20 Sep 2003 12:32:21 +0200, "Hauke Duden" <H.NS.Duden gmx.net>
 wrote:
 
How about CClass, IInterface and TTemplateClass? I know that many people see
it as too Microsoft-ish, but I have found it useful in the past to be able
to easily distingusih interfaces, classes and template classes. They are all
used in a different way. For example, templates are instantiated in a
different way than simple classes (needing template parameters) and
interfaces cannot be instantiated at all.

I usually use IXxxxxXxxxx and TXxxxxxXxxxx for interfaces and templates, since I think it helps distinguish them just a little bit, but I think that CXxxxxXxxxx for classes is a little bit too much. The I and T prefixes for interfaces and templates are there to _distinguish_ them from classes, which, in my opinion, is the default assumption.

I think we should also consider: I_XxxxxYyyyy T_XxxxxxxYyyyy (for readability) InterfaceXxxxxYyyy TemplateXxxxYyyyy (Appreviations are evil) -- Helmut Leitner leitner hls.via.at Graz, Austria www.hls-software.com
Sep 22 2003
parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
Helmut Leitner wrote:
 I think we should also consider:
    I_XxxxxYyyyy   T_XxxxxxxYyyyy  (for readability)

Hmmm. For me this is not more readable at all. It looks like the beginning of a constant.
    InterfaceXxxxxYyyy   TemplateXxxxYyyyy  (Appreviations are evil)

Not if you have to use them all the time! There's a reason why 'for' is called 'for' and not 'LoopWithAutomaticInitializationAndConditionCheckAndIncrementation'. Abbreviations are only evil if they cannot be easily understood. I.e. for many variable names abbreviations are a bad thing if strangers are trying to understand the code [I often refer to this as the wheel-of-fortune style of programming - for some people, vowels seem to cost money ;)]. However, if there is an accepted convention for the I and T prefixes then everyone using D will instantly understand them. Hauke
Sep 22 2003
parent reply Helmut Leitner <leitner hls.via.at> writes:
Hauke Duden wrote:
 
 Helmut Leitner wrote:
 I think we should also consider:
    I_XxxxxYyyyy   T_XxxxxxxYyyyy  (for readability)

Hmmm. For me this is not more readable at all. It looks like the beginning of a constant.
    InterfaceXxxxxYyyy   TemplateXxxxYyyyy  (Appreviations are evil)

Not if you have to use them all the time! There's a reason why 'for' is called 'for' and not 'LoopWithAutomaticInitializationAndConditionCheckAndIncrementation'. Abbreviations are only evil if they cannot be easily understood. I.e. for many variable names abbreviations are a bad thing if strangers are trying to understand the code [I often refer to this as the wheel-of-fortune style of programming - for some people, vowels seem to cost money ;)]. However, if there is an accepted convention for the I and T prefixes then everyone using D will instantly understand them.

This has very much to do with habits. It's about a clear separation of semantic units (words). A clear separation is - a change lower to upper - a separator character like "_" These are not clearly separable (you need insider knowledge): fopen strrchr ShowHTML IPrt IBMClass (interface "BMClass" ?) These are clearly separable (even if one isn't used to it): file_open OpenFile OPEN_FILE InterfacePrintable I_Printable toString Personally I prefer slight abbreviations, but the trend is against it. IMHO it would be better for the development of D not to abbreviate. "No abbreviations" would mean "no discussions about abbreviations". This would free energy for more impotant things. -- Helmut Leitner leitner hls.via.at Graz, Austria www.hls-software.com
Sep 22 2003
next sibling parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
Helmut Leitner wrote:
 This has very much to do with habits.
 
 It's about a clear separation of semantic units (words).
 
 A clear separation is
    - a change lower to upper
    - a separator character like "_"
 
 These are not clearly separable (you need insider knowledge):
    fopen
    strrchr
    ShowHTML  
    IPrt
    IBMClass (interface "BMClass" ?)
 
 These are clearly separable (even if one isn't used to it):
    file_open
    OpenFile
    OPEN_FILE
    InterfacePrintable
    I_Printable
    toString 
 
 Personally I prefer slight abbreviations, but the trend is against it.
 
 IMHO it would be better for the development of D not to abbreviate.
 "No abbreviations" would mean "no discussions about abbreviations".
 This would free energy for more impotant things.

Heh. So would the rule "always use abbreviations" (which I'm definitely NOT advocating!). That doesn't make it a good rule. I also prefer OpenFile to fopen. However, I definitely think that prefixing every interface name with "Interface" instead of "I" is too verbose. The fact that abbreviations are problematic does not mean that names should be long. The key is to make the names as short as possible and keep them intuitive and understandable at the same time. "toString" is a good example. It is immediately clear what it means if you see obj.toString, even though the name is short. However, if you get right down to it, toString doesn't really describe what the method does. Is something strung together? Is the parameter (which is really a formatting argument) converted to a string? What kind of string is produced? "convertThisObjectToCharacterString" would be more exact. However, every programmer knows that a "string" is a character string if nothing says otherwise. Every programmer also knows methods work on their own objects by default. So the short name is understandable and long enough. The thing is to have good "defaults" that can be used in names. Having a consistent naming convention for a language goes a long way to establish such defaults and thus allows shorter names. If the "I" prefix is standard then the default exists and there is no need to describe the meaning of it further in every single interface you create. Hauke
Sep 22 2003
parent reply Helmut Leitner <helmut.leitner chello.at> writes:
Hauke Duden wrote:
 The thing is to have good "defaults" that can be used in names. Having a
 consistent naming convention for a language goes a long way to establish
 such defaults and thus allows shorter names. If the "I" prefix is
 standard then the default exists and there is no need to describe the
 meaning of it further in every single interface you create.

What is IOFile - an input-output-file - an interface to OFile ??? Using a "I_" or "Interface" prefix it would be clear. -- Helmut Leitner leitner hls.via.at Graz, Austria www.hls-software.com
Sep 22 2003
next sibling parent Hauke Duden <H.NS.Duden gmx.net> writes:
Helmut Leitner wrote:
 What is IOFile
 
   - an input-output-file
   - an interface to OFile 

Aaah. Good one ;). This problem never occurred in my programs because every kind of class construct has a prefix (normal classes have a C). So IOFile would be an interface to an OFile.
 Using a "I_" or "Interface" prefix it would be clear. 

True. But as I said earlier, for me it looks too much like a constant. I also don't like having to type underscores. Maybe it is just the way I type (kind of 8 1/2 finger freestyle), but for underscores I need to move my hands more than I like to do. It may also have something to do with the german keyboard layout, I don't know. I realize that this is entirely subjective, though. Still, I found conventions that I am quite happy with and that do not use underscores at all. These are: CClass IInterface TTemplate someMethod() someVariable m_MyMember SomeConstant Works pretty well for me. Hauke
Sep 23 2003
prev sibling next sibling parent "Julio CÚsar Carrascal Urquijo" <adnoctum phreaker.net> writes:
 What is IOFile

   - an input-output-file
   - an interface to OFile

Then, what's OFile? We say "no abreviations" remember? :)
Sep 22 2003
prev sibling parent Benji Smith <dlanguage xxagg.com> writes:
On Mon, 22 Sep 2003 23:01:37 +0200, Helmut Leitner
<helmut.leitner chello.at> wrote:

Hauke Duden wrote:
 The thing is to have good "defaults" that can be used in names. Having a
 consistent naming convention for a language goes a long way to establish
 such defaults and thus allows shorter names. If the "I" prefix is
 standard then the default exists and there is no need to describe the
 meaning of it further in every single interface you create.

What is IOFile - an input-output-file - an interface to OFile ??? Using a "I_" or "Interface" prefix it would be clear.

Ideally, I think it should be an IoFile. Just like I have an XmlDocumentFactory, not an XMLDocumentFactory. So, an IOFile should be an interface to an OFile. But what the hell is an OFile? An interface to an IoFile should be an IIoFile. Just like a template for a Thingy should be a TThingy. --Benji
Sep 23 2003
prev sibling parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
"Helmut Leitner" <leitner hls.via.at> wrote in message
news:3F6F1A8E.4550CCA5 hls.via.at...
 Personally I prefer slight abbreviations, but the trend is against it.

 IMHO it would be better for the development of D not to abbreviate.
 "No abbreviations" would mean "no discussions about abbreviations".
 This would free energy for more impotant things.

Heh... forget abbreviations, just choose shorter words!! ;) Sean
Sep 22 2003
prev sibling parent Antti =?iso-8859-1?Q?Syk=E4ri?= <jsykari gamma.hut.fi> writes:
Mmm... naming conventions. Now we're getting to the sensitive areas in
language design. I foresee some serious flamewars building up ;)

My preferences would be along the lines of

import modules.like.this;

struct This_Is_A_Type
{
    void member_function()
    {
    }

    int member_variable;
}

enum Another_Type
{
    value_one,
    value_two
}

int main()
{
    Another_Type variables_like_this;

    return 0;
}

About ints, floats, etc. Do as Java and C# do. You can't fight the C
(and C++) legacy.

Everyone seems to like MixedCase and lowerUpperCase nowadays, like Java
and Smalltalk. Well, separating_words_like_this_might_take_a_bit_longer
to_type_but onTheOtherHandPersonallyIFindThisMuchLessReadableHowAboutYou?

-Antti

More comments below:

In article <bkgkvc$2qv4$1 digitaldaemon.com>, Matthew Wilson wrote:
 I vote for MixedCase convention for modules and classes and lowerUpperCase
 for methods, types and variables.

Sorry. Strongly disagree. What's the virtue in not being able to distinguish between methods/types and variables? lowerUpperCase should be only for variables.

Classes are types as well as enums, structs, typedefs, unions, etc. So they should be the same. MixedCase I'd say. However, methods and variables are used kind of the same, especially now that we have properties. You know, if you look at the code Array array; array.size = 15; printf("%d\n", array.size); You should be able to change the implementation of member "size" between a property (member functions void size(int) and int size()) and member variable (just int size;) without having to go through the client code and changing some damn capitalization. The whole point of properties is that they behave the same syntactically as member variables and you can use one where you can use the other. This is not the case with, for example, classes and functions. This is already the convention already used by, for example, http://www.digitalmars.com/d/property.html -Antti
Sep 21 2003
prev sibling next sibling parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
The problem with making all classes initial caps is that all the builtin
types are all lowercase.

This effort is doomed to failure.

Sean

"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bkghl9$2ene$1 digitaldaemon.com...
 Any chance on our standardising on lowercase for modules, and UpperCase

 Classes? (Naturally there'd be exceptions, such as c.stdio.)

 If not, I'd be interested to hear of suggestions for a good convention.

 example, I don't think many would suggest that having the same name and
 capitalisation for a module and a class (e.g. the module

 and the class "registry") is a good thing.

Sep 19 2003
next sibling parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
 The problem with making all classes initial caps is that all the builtin
 types are all lowercase.

That's true. However, since they're built-in, that does not present too much of a problem.
 This effort is doomed to failure.

Notwithstanding my previous comment, you are correct here. Human nature is what it is. I guess I'm seeking just to test the waters such that there's enough people that can live with what I do with the registry library so that I won't be "asked" to revise the naming.
 Sean

 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bkghl9$2ene$1 digitaldaemon.com...
 Any chance on our standardising on lowercase for modules, and UpperCase

 Classes? (Naturally there'd be exceptions, such as c.stdio.)

 If not, I'd be interested to hear of suggestions for a good convention.

 example, I don't think many would suggest that having the same name and
 capitalisation for a module and a class (e.g. the module

 and the class "registry") is a good thing.


Sep 19 2003
parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
Why didn't you say so?  ;)

I do think D needs to decide on a naming convention for builtins and
standard library.  I think it needs to happen very very soon.

I do not think you can force everybody else to use the same convention
(except when interfacing with the standard library of course) nor is it
possible to come up with a convention that everybody is happy with.

Sean

"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bkgm88$2ugv$1 digitaldaemon.com...
 The problem with making all classes initial caps is that all the builtin
 types are all lowercase.

That's true. However, since they're built-in, that does not present too

 of a problem.

 This effort is doomed to failure.

Notwithstanding my previous comment, you are correct here. Human nature is what it is. I guess I'm seeking just to test the waters such that there's enough people that can live with what I do with the registry library so

 I won't be "asked" to revise the naming.

Sep 19 2003
parent reply "Matthew Wilson" <matthew stlsoft.org> writes:
"Sean L. Palmer" <palmer.sean verizon.net> wrote in message
news:bkgnhd$th$1 digitaldaemon.com...
 Why didn't you say so?  ;)

Asked and answered (well, winked, anyway)
 I do think D needs to decide on a naming convention for builtins and
 standard library.  I think it needs to happen very very soon.

Absolutely. I think 1. Modules: c.stdio c.win32 d.win32.registry 2. Classes: KeySequence File 3. Free functions: <no bloody idea! clearly things in c.stdio are going to be lowercase. Things in c.win32 are not (e.g. RegCreateKeyExA). I would prefer to write free functions as Api_SomeFunction, but I can live with pretty much any convention. > 4. Methods: CreateSubKey 5. Properties: Values OpenFiles 6. Variables: someVariable <and the odd, bIfOpen, thrown in!! Ha ha> 7. Enums - yikes thisway or this_way or ThisWay or THIS_WAY As far as I can tell 1. is already happening. There's been the odd mention of "D.Xyz.Abc" but I think Walter's already sailed this ship with c.stdio. It would be ludicrous to have "c.*" and "D.*". There's nothing stopping 3rd parties from having uppercase it they wish. Jaba uses all lowercase for the standard libs, and most vendors do too, but some use upper (IIRC). 2. seems to be the way everyone writes code, so not in the least contentious 3. the "c.*" functions are already set. We have no choice but to follow whatever naming convention for any C-libs we link to, unless someone wants to go to the paitful and pointless effort of wrapping them. (Bags not me!) I've not noticed many people talking about free functions otherwise. (I do hope we've all not been seduced by the everything is an object bullshit. Sigh). 4. Pretty much all code I've seen posted does this, so shouldn't be a prob. However, I think a most of Phobos code uses lowercase ... I just did a grep, and it appears that most, but not all, of Phobos uses lower. I think this chews, but can live with it for the moment for the same reason that it's useful in C++, to disambiguate standard library / STL stuff from "proper" code. This is going to be a pain in the future, methinks. 5. I guess these are too new to tell. 6. I've not seen any uppercase variable names, thank goodness! 7. We need some opinions on this asap. I've used both ThisWay and THIS_WAY, so I'm a hypocrite. Since we don't need to reserve all uppercase for the preprocessor, I'd like to use uppercase for constants and enum names / variables, but recognise this may not be popular. Lots of opinions please ...
 I do not think you can force everybody else to use the same convention
 (except when interfacing with the standard library of course) nor is it
 possible to come up with a convention that everybody is happy with.

 Sean

 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bkgm88$2ugv$1 digitaldaemon.com...
 The problem with making all classes initial caps is that all the



 types are all lowercase.

That's true. However, since they're built-in, that does not present too

 of a problem.

 This effort is doomed to failure.

Notwithstanding my previous comment, you are correct here. Human nature


 what it is. I guess I'm seeking just to test the waters such that


 enough people that can live with what I do with the registry library so

 I won't be "asked" to revise the naming.


Sep 19 2003
next sibling parent J Anderson <anderson badmama.com.au.REMOVE> writes:
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Matthew Wilson wrote:

7. We need some opinions on this asap. I've used both ThisWay and THIS_WAY,
so I'm a hypocrite. Since we don't need to reserve all uppercase for the
preprocessor, I'd like to use uppercase for constants and enum names /
variables, but recognise this may not be popular. Lots of opinions please
...
  

constants (although there was no style guide imposed). I think the lecturer was feed up with giving me 100% all the time. Now I always use uppercase for constants and enums. However, one problem with this approach, is when a constant changes to a variable ("This should never happen good design blah blah..."), although it's not generally a problem for enums. Really though I think that's a minor issue, go ahead, use uppercase for capitals.
Sep 20 2003
prev sibling parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bkgonn$4ln$1 digitaldaemon.com...
 "Sean L. Palmer" <palmer.sean verizon.net> wrote in message
 news:bkgnhd$th$1 digitaldaemon.com...
 I do think D needs to decide on a naming convention for builtins and
 standard library.  I think it needs to happen very very soon.

Absolutely. I think 1. Modules: c.stdio c.win32 d.win32.registry

Only because there's so much momentum built up around it already.
     2. Classes:
         KeySequence
         File

I do this, but I'm constantly bummed that the style is different for builtins than for my classes and typedefs: int float Int32 UInt32 // or Uint32? Vector3 Matrix4x4 It ends up making me want to make every identifier initial lowercase mixed-case.
     3. Free functions:
         <no bloody idea! clearly things in c.stdio are going to be
 lowercase. Things in c.win32 are not (e.g. RegCreateKeyExA). I would

 to write free functions as Api_SomeFunction, but I can live with pretty

 any convention. >

No, that's what modules are for. Why redundantly put the api name into the function name? Just import the module as needing explicit qualification.
     4. Methods:
         CreateSubKey

     5. Properties:
         Values
         OpenFiles

     6. Variables:
         someVariable
         <and the odd, bIfOpen, thrown in!! Ha ha>

     7. Enums - yikes
         thisway or
         this_way or
         ThisWay or
         THIS_WAY

Yah... my enums look more like values. Variables, constants, and enumerants, all initial lowercase.
 As far as I can tell

 1. is already happening. There's been the odd mention of "D.Xyz.Abc" but I
 think Walter's already sailed this ship with c.stdio. It would be

 to have "c.*" and "D.*". There's nothing stopping 3rd parties from having
 uppercase it they wish. Jaba uses all lowercase for the standard libs, and
 most vendors do too, but some use upper (IIRC).

Jabba? Java the Hutt? It is kinda bloated! harhar
 2. seems to be the way everyone writes code, so not in the least

 3. the "c.*" functions are already set. We have no choice but to follow
 whatever naming convention for any C-libs we link to, unless someone wants
 to go to the paitful and pointless effort of wrapping them. (Bags not me!)
 I've not noticed many people talking about free functions otherwise. (I do
 hope we've all not been seduced by the everything is an object bullshit.
 Sigh).

 4. Pretty much all code I've seen posted does this, so shouldn't be a

 However, I think a most of Phobos code uses lowercase ...

 I just did a grep, and it appears that most, but not all, of Phobos uses
 lower. I think this chews, but can live with it for the moment for the

 reason that it's useful in C++, to disambiguate standard library / STL

 from "proper" code.

 This is going to be a pain in the future, methinks.

 5. I guess these are too new to tell.

 6. I've not seen any uppercase variable names, thank goodness!

 7. We need some opinions on this asap. I've used both ThisWay and

 so I'm a hypocrite. Since we don't need to reserve all uppercase for the
 preprocessor, I'd like to use uppercase for constants and enum names /
 variables, but recognise this may not be popular. Lots of opinions please
 ...

I think all uppercase is ugly, and not only that, it forces you to use underscores to separate the words, which I also dislike. I think of the variable/method/class separation more of like value/function/type. Currently, for me, functions are capitalized like types. This sorta makes sense when you think about typecasting, which is a function. MyType(x) I'm really starting to like the rule case is insignificant unless the identifier is only one character, in which case it is significant. That way you can have A and a. Or maybe as a more general single rule, case is significant for the first character of an identifier, and insignificant for the rest. That way you can have Foo and foo, but FOO is the same as Foo, and fOO is the same as foo. people don't have to worry about memorizing the case of the rest of the identifier, which is what most people disagree on most anyway. I don't really care what style the library is written in... I just don't like to have to switch styles when I am dealing with different libraries. If you're using 3 libraries you have to mix 3 different styles, plus your own style. That's a lot to remember. Sean
Sep 20 2003
parent reply J Anderson <anderson badmama.com.au.REMOVE> writes:
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Sean L. Palmer wrote:

"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bkgonn$4ln$1 digitaldaemon.com...
  

"Sean L. Palmer" <palmer.sean verizon.net> wrote in message
news:bkgnhd$th$1 digitaldaemon.com...
    

I do think D needs to decide on a naming convention for builtins and
standard library.  I think it needs to happen very very soon.
      

1. Modules: c.stdio c.win32 d.win32.registry

Only because there's so much momentum built up around it already.
    2. Classes:
        KeySequence
        File
    

I do this, but I'm constantly bummed that the style is different for builtins than for my classes and typedefs: int float Int32 UInt32 // or Uint32? Vector3 Matrix4x4 It ends up making me want to make every identifier initial lowercase mixed-case.
    3. Free functions:
        <no bloody idea! clearly things in c.stdio are going to be
lowercase. Things in c.win32 are not (e.g. RegCreateKeyExA). I would
    

to write free functions as Api_SomeFunction, but I can live with pretty
    

any convention. >
    

No, that's what modules are for. Why redundantly put the api name into the function name? Just import the module as needing explicit qualification.
    4. Methods:
        CreateSubKey

    5. Properties:
        Values
        OpenFiles

    6. Variables:
        someVariable
        <and the odd, bIfOpen, thrown in!! Ha ha>

    7. Enums - yikes
        thisway or
        this_way or
        ThisWay or
        THIS_WAY
    

Yah... my enums look more like values. Variables, constants, and enumerants, all initial lowercase.
As far as I can tell

1. is already happening. There's been the odd mention of "D.Xyz.Abc" but I
think Walter's already sailed this ship with c.stdio. It would be
    

to have "c.*" and "D.*". There's nothing stopping 3rd parties from having
uppercase it they wish. Jaba uses all lowercase for the standard libs, and
most vendors do too, but some use upper (IIRC).
    

Jabba? Java the Hutt? It is kinda bloated! harhar
2. seems to be the way everyone writes code, so not in the least
    

3. the "c.*" functions are already set. We have no choice but to follow
whatever naming convention for any C-libs we link to, unless someone wants
to go to the paitful and pointless effort of wrapping them. (Bags not me!)
I've not noticed many people talking about free functions otherwise. (I do
hope we've all not been seduced by the everything is an object bullshit.
Sigh).

4. Pretty much all code I've seen posted does this, so shouldn't be a
    

However, I think a most of Phobos code uses lowercase ...

I just did a grep, and it appears that most, but not all, of Phobos uses
lower. I think this chews, but can live with it for the moment for the
    

reason that it's useful in C++, to disambiguate standard library / STL
    

from "proper" code.

This is going to be a pain in the future, methinks.

5. I guess these are too new to tell.

6. I've not seen any uppercase variable names, thank goodness!

7. We need some opinions on this asap. I've used both ThisWay and
    

so I'm a hypocrite. Since we don't need to reserve all uppercase for the
preprocessor, I'd like to use uppercase for constants and enum names /
variables, but recognise this may not be popular. Lots of opinions please
...
    

I think all uppercase is ugly, and not only that, it forces you to use underscores to separate the words, which I also dislike. I think of the variable/method/class separation more of like value/function/type. Currently, for me, functions are capitalized like types. This sorta makes sense when you think about typecasting, which is a function. MyType(x) I'm really starting to like the rule case is insignificant unless the identifier is only one character, in which case it is significant. That way you can have A and a. Or maybe as a more general single rule, case is significant for the first character of an identifier, and insignificant for the rest. That way you can have Foo and foo, but FOO is the same as Foo, and fOO is the same as foo. people don't have to worry about memorizing the case of the rest of the identifier, which is what most people disagree on most anyway. I don't really care what style the library is written in... I just don't like to have to switch styles when I am dealing with different libraries. If you're using 3 libraries you have to mix 3 different styles, plus your own style. That's a lot to remember. Sean

going to happen.
Sep 21 2003
parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

"J Anderson" <anderson badmama.com.au.REMOVE> wrote in message =
news:bkkfta$f1q$1 digitaldaemon.com...
  Sean L. Palmer wrote:

I don't really care what style the library is written in... I just don't
like to have to switch styles when I am dealing with different =
libraries.
If you're using 3 libraries you have to mix 3 different styles, plus =
your
own style.  That's a lot to remember.

Sean


  I'd also like it if the _ was optional, although I know that's never =
going to happen.
Could happen!  That's a good idea.

Please trim your quotes down.  Several pages for a one-liner with no =
indication of where the quotes were and where your reply might be was a =
bit frustrating.

Sean
Sep 22 2003
prev sibling parent reply Helmut Leitner <leitner hls.via.at> writes:
"Sean L. Palmer" wrote:
 
 The problem with making all classes initial caps is that all the builtin
 types are all lowercase.

But doesn't this make a nice distiction between primitives and classes? -- Helmut Leitner leitner hls.via.at Graz, Austria www.hls-software.com
Sep 20 2003
parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
"Helmut Leitner" <leitner hls.via.at> wrote in message
news:3F6C075F.C5EB0D8A hls.via.at...
 The problem with making all classes initial caps is that all the builtin
 types are all lowercase.

But doesn't this make a nice distiction between primitives and classes?

Why distinguish? Who cares? They're both types. I want to unify the type system, not accentuate the difference between builtins and user-defineds. Why are those so special that they deserve to be an exception to the style? Sean
Sep 20 2003
prev sibling parent "Julio CÚsar Carrascal Urquijo" <adnoctum phreaker.net> writes:
From D reference manual:

General
Names formed by joining multiple works should have each word other than the

  int myFunc();

Module
Module names are all lower case. This avoids problems dealing with case

C Modules
Modules that are interfaces to C functions go into the "c" package, for

  import c.stdio;

Module names should be all lower case.

Class, Struct, Union, Enum names
are capitalized.
  class Foo;
  class FooAndBar;

Function names
Function names are not capitalized.
  int done();
  int doneProcessing();

Const names
Are in all caps.

Enum member names
Are in all caps.

I'm pretty happy with that but I was hoping we could change the line "Module names should be all lower case." to "Module names should be mixed case.". :) Off course, C, Win32, X11 modules will have to use whatever convention is used in the native library.
Sep 20 2003