Is D open for different code conventions?

[Sean Kelly]

Bill Baxter wrote:
> Anonymous wrote:
>>
>>> I just want to ask D's community: it is appropriate if some projects 
>>> will use different code convention?
>>
>> If it is your project I don't see anybody forcing you to do anything.
>> Personally I don't even know which convention I'm supposed to use.
>> I wouldn't even be able to name the convention I use myself :D
> 
> toString, opApply, opCall, opCatAssign....
> 
> Some uses of camel case are dictated by the spec currently.
> And Phobos and Tango both use camelCase for methods.
> 
> I also used to like camelCase and groaned whenever I saw a different 
> convention, and *especially* at GTK code.  But I also came to the 
> realization at some point that underscore_separated really is easier to 
> read close to the deadline, late at night, with too little sleep.

It's a bit of a religious issue, but I've decided I like CamelCase for 
type names because it helps visually distinguish them from variable 
names, etc.  It's also a tiny bit more compact.  For what it's worth, I 
was an underscore_fellow until I started using D.

> On the other hand, having D and D libraries use camel case means that I 
> underscore_methods can serve as an indicator for what's "my code" and 
> what's "library code".

I've actually never liked having such a distinction :-)  Particularly 
with C++ where doing so can break the use of templates that rely on 
class-scope typedefs following certain conventions.


Sean