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