coding style

[Bryan Call <bc...@yahoo-inc.com>]

I would like to open up a discussion about coding style...

I updated the coding style wiki because there was some confusion around method naming and private method naming.

http://cwiki.apache.org/confluence/display/TS/Coding+Style

We are pretty strict on our indentation and we need to be more strict on our class, method, and member names to insure consistency in the code.  Unfortunately there is no good tool to automate consistency like there is for indentation.

-Bryan

Re: coding style: to camel or not

[John Plevyak <jp...@acm.org>]

Regarding the m_ for member,

I agree that for private/protected variables an indicator is a good idea.
Regular members are always accessed by reference outside the object, so
it seems obvious that it is a member:

cache_read_vio->nbytes

is a member and it doesn't help (me) to have it be:

cache_read_vio->m_nbytes

Likewise, within a member function for the containing class I tend to think
of my own data members as local variables for a dynamic scope over
the collection of member functions.  This is particularly true in an
event driven model where often the members are acting as local variables
for a co-routine formed by the activations of the Continuation.  In that
case having them m_ seems to emphasize their heap load-store nature
rather than the dynamic execution state nature.  One of the problems that
some people have with event driven programming is trying to get their
head around what to do with what they had previously considered to be
dynamic execution state, and it seems like it would not be helpful to those
folks to emphasize that these are really data members of heap bound objects.

john

Re: coding style: to camel or not

[Paul Querna <pa...@querna.org>]

On Thu, Dec 10, 2009 at 10:44 AM, Manjesh Nilange <ma...@yahoo-inc.com> wrote:
>> MACROS
>> ClassNames
>> memberFunctions
>> members_variables
>
> How about having an 'm_' prefix to distinguish member variables from
> local variables? I know this is a couple of more characters to type, but
> I find it nicer to be able to distinguish class member variables easily.
> The rest of the list looks good.

+1, agree.
>> local_variables
>> local_functions

This is pretty much my preferred style (yes, C background :) ), so I'm
all for it !

RE: coding style: to camel or not

[Manjesh Nilange <ma...@yahoo-inc.com>]

> MACROS
> ClassNames
> memberFunctions
> members_variables

How about having an 'm_' prefix to distinguish member variables from
local variables? I know this is a couple of more characters to type, but
I find it nicer to be able to distinguish class member variables easily.
The rest of the list looks good. 

> local_variables
> local_functions

- Manjesh

coding style: to camel or not

[John Plevyak <jp...@acm.org>]

I have been reading style guides online and there is a good deal of 
disagreement regarding camel case.

Many people believe that it is harder to read readFromOpenFile as 
compared to read_from_open_file
and I have to agree.

However it is also nice to be able to tell the difference between the 
sorts of things one is dealing with
for APIs where clarity of purpose is perhaps more important than 
scan-ability.

How about:

MACROS
ClassNames
memberFunctions
members_variables
local_variables
local_functions

Private and protected members with preceeding _ would be _member_variables.

The rational being that the ability to distinguish the sort of thing you 
are dealing with
is most important for interfaces and non-local things which have diffuse 
context whereas
strictly local names should be most readable.  C styles (e.g. GNU) 
typically have all variables and
functions named_like_this, and retaining this for local variables and 
functions makes the
code more appealing to crossover C programmers.

Just an idea.

john