www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Is D open for different code conventions?

reply eao197 <eao197 intervale.ru> writes:
I just want to ask D's community: it is appropriate if some projects wil=
l  =

use different code convention?

I used CamelCase code convention, which was very similar to the current =
 =

D's style, for more than 6 years, but with time I felt that my eyes got =
 =

tired when dealing with big amount of CamelCase formatted code. So I  =

switched to lower_case style and use it for last 6 years.

Now, when I try to write D code in CamelCase style I've found the same  =

problem again -- my eyes get tired quickly. Because in code like such:

void
parseLine( char[] line, bool showGoodMessages )
   {
     if( line.length <=3D 2 )
       return;

     auto binImage =3D tryExtractShortMessageBody( line );
     if( binImage !is null )
       {
         auto analyzingResult =3D tryHandleHeadersAndBody( binImage );
         if( analyzingResult.isGoodMessage() )
           {
             if( showGoodMessages )
               Stdout.formatln( "OK: {0}", analyzingResult );
           }
         else
           showBadMessage( line, analyzingResult );
       }
     else
       Stderr.formatln( "nothing found in {0}", line );
   }

it is hard to read indentifiers like tryHandleHeadersAndBody. So I prefe=
r  =

to write:

void
parse_line( char[] line, bool show_good_messages )
   {
     if( line.length <=3D 2 )
       return;

     auto bin_image =3D try_extract_short_message_body( line );
     if( bin_image !is null )
       {
         auto analyzing_result =3D try_handle_headers_and_body( bin_imag=
e );
         if( analyzing_result.is_good_message() )
           {
             if( show_good_messages )
               Stdout.formatln( "OK: {0}", analyzing_result );
           }
         else
           show_bad_message( line, analyzing_result );
       }
     else
       Stderr.formatln( "nothing found in {0}", line );
   }

I think it would be good if there will be possibility to use different  =

code convention in D. For example, like Ruby's: CamelCase for class name=
s  =

and lower_case for method names, or like C++ ACE's: Camel_Case for class=
es  =

and lower_case for methods.

-- =

Regards,
Yauheni Akhotnikau
Jul 30 2007
next sibling parent reply renoX <renosky free.fr> writes:
eao197 Wrote:

 I just want to ask D's community: it is appropriate if some projects will  
 use different code convention?


Maybe there should be a vote?
I don't like at all CamelCase either..

[cut]

 I think it would be good if there will be possibility to use different  
 code convention in D. For example, like Ruby's: CamelCase for class names  
 and lower_case for method names, or like C++ ACE's: Camel_Case for classes  
 and lower_case for methods.


Restricting CamelCase to class name is a good compromise, I agree.

That said even for class name/typename, there is some weird 'double standard':
I doubt that you'll find many people who want to switch from 'int' to 'Int'..

renoX


 
 -- 
 Regards,
 Yauheni Akhotnikau
Jul 30 2007
parent eao197 <eao197 intervale.ru> writes:
On Mon, 30 Jul 2007 14:46:47 +0400, renoX <renosky free.fr> wrote:


 eao197 Wrote:

 I just want to ask D's community: it is appropriate if some projects  
 will
 use different code convention?


 Maybe there should be a vote?


I don't think that a vote is appropriate here. IMHO, the better way is  
allow to use different code conventions. Yes it leads to styles mixture  
(like in C++ when a project uses Qt+ACE+boost), but C++ show that it isn't  
a big problem. It is not a good idea to mix different styles in some kind  
of projects, like reusable libraries (for example it is bad idea to add  
new code to Tango in a different style). But when I wrote my own project  
with Tango I want to use my own code convention.


 That said even for class name/typename, there is some weird 'double  
 standard': I doubt that you'll find many people who want to switch from  
 'int' to 'Int'..


AFAIK, 'int' is not a class, so it isn't a problem :)

-- 
Regards,
Yauheni Akhotnikau
Jul 30 2007
prev sibling parent reply Anonymous <Anonymous Anonymous.com> writes:
 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
Jul 30 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
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.

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

--bb
Jul 30 2007
parent reply Sean Kelly <sean f4.ca> writes:
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
Jul 30 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Sean Kelly wrote:

 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.


I was actually only talking about method names. For class names I'm all 
for CapitalizedWords.  But as you say, it is just a religious thing, 
which is why the OP suggests making it a preference.  But I just don't 
see how that would work.  So to the OP:  what did you have in mind?  The 
only think I could imagine would be to make the compiler magically 
mangle a bunch of related names to the same symbol.  Like making all of

to_string
ToString
To_String
etc...

mangle to the same thing as

toString

but that doesn't really cover the std libary.  And I think it would be a 
really bad idea to globally treat some_function as synonymous with 
SomeFunction.  Reminds me of case-insensitive languages where 
SomeVArIaBle is the same thing as someVariable.

--bb
Jul 30 2007
parent BCS <ao pathlink.com> writes:
Reply to Bill,


 So to the OP:  what did you have
 in mind?  The only think I could imagine would be to make the compiler
 magically mangle a bunch of related names to the same symbol.  Like
 making all of
 
 to_string
 ToString
 To_String
 etc...
 mangle to the same thing as
 
 toString
 
 
 --bb
 



The only thing I would go for (in text ;) is "let everybody do it the way 
that they will and live with it!" Unless you are signing my paycheck, I'm 
going to name stuff the way I like to do it.
Jul 30 2007