D - Naming conventions
- "Matthew Wilson" <matthew stlsoft.org> Sep 19 2003
- "Julio César Carrascal Urquijo" <adnoctum phreaker.net> Sep 19 2003
- "Matthew Wilson" <matthew stlsoft.org> Sep 19 2003
- "Sean L. Palmer" <palmer.sean verizon.net> Sep 19 2003
- "Hauke Duden" <H.NS.Duden gmx.net> Sep 20 2003
- Benji Smith <dlanguage xxagg.com> Sep 22 2003
- Hauke Duden <H.NS.Duden gmx.net> Sep 22 2003
- Helmut Leitner <leitner hls.via.at> Sep 22 2003
- Hauke Duden <H.NS.Duden gmx.net> Sep 22 2003
- Helmut Leitner <leitner hls.via.at> Sep 22 2003
- Hauke Duden <H.NS.Duden gmx.net> Sep 22 2003
- Helmut Leitner <helmut.leitner chello.at> Sep 22 2003
- Hauke Duden <H.NS.Duden gmx.net> Sep 23 2003
- "Julio César Carrascal Urquijo" <adnoctum phreaker.net> Sep 22 2003
- Benji Smith <dlanguage xxagg.com> Sep 23 2003
- "Sean L. Palmer" <palmer.sean verizon.net> Sep 22 2003
- Antti =?iso-8859-1?Q?Syk=E4ri?= <jsykari gamma.hut.fi> Sep 21 2003
- "Sean L. Palmer" <palmer.sean verizon.net> Sep 19 2003
- "Matthew Wilson" <matthew stlsoft.org> Sep 19 2003
- "Sean L. Palmer" <palmer.sean verizon.net> Sep 19 2003
- "Matthew Wilson" <matthew stlsoft.org> Sep 19 2003
- J Anderson <anderson badmama.com.au.REMOVE> Sep 20 2003
- "Sean L. Palmer" <palmer.sean verizon.net> Sep 20 2003
- J Anderson <anderson badmama.com.au.REMOVE> Sep 21 2003
- "Sean L. Palmer" <palmer.sean verizon.net> Sep 22 2003
- Helmut Leitner <leitner hls.via.at> Sep 20 2003
- "Sean L. Palmer" <palmer.sean verizon.net> Sep 20 2003
- "Julio César Carrascal Urquijo" <adnoctum phreaker.net> Sep 20 2003
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
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
"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
"Sean L. Palmer" <palmer.sean verizon.net> "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
"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
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
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
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
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
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
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
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
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
What is IOFile - an input-output-file - an interface to OFile
Then, what's OFile? We say "no abreviations" remember? :)
Sep 22 2003
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
"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
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
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
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
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
"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
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
"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! harhar2. 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
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! harhar2. 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
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
"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
"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
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