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.

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.

"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

"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

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.

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

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.

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

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

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