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