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


"d.win32.registry"

 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


 "d.win32.registry"

 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






and

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


 "d.win32.registry"

 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




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.


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


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.


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




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.


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;
}


(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


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 "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


 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
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


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.
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






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.
Sep 19 2003
next sibling parent J Anderson <anderson badmama.com.au.REMOVE> writes:
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
...
  


I lost a mark in an ASM assignment once for not using uppercase for 
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


prefer

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


much

 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


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).


Jabba?  Java the Hutt?  It is kinda bloated!  harhar


 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 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:
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.
      


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
    


prefer
  


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


much
  


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
    


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).
    


Jabba?  Java the Hutt?  It is kinda bloated!  harhar

  


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 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


  


I'd also like it if the _ was optional, although I know that's never 
going to happen.
Sep 21 2003
parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
	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


first capitalized.

  int myFunc();

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


insensitive file systems.

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


example:

  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