Naming of private functions

[Phlip]

How about this one: member functions must have names with strictly
alternating uppercase and lowercase letters.

tHaT's NoT eStHeTiC.

 

[Daniel T.]

The company where I work uses a naming convention that I have
never used before. They use mixed-case letters for public
member functions, but lower-case with underscores for the
rest, like this:

class Foo
{
public:
void somePublicMemberFunction();
protected:
void hello_i_am_protected();
private:
void this_one_is_private();
};

The other developers swear that this convention makes code
easier to understand, but not one of can give me a concrete
justification.

Incidentally, in my previous jobs I always used the same
convention for all member functions quite happily, but after
several months of using this new one I'm still not convinced
it adds value.

I understand that private *data* members deserve a trailing
underscore or m_ prefix to differentiate them from local
variables or function arguments, but the need for this
convention is not clear to me at all.

Anyone see the benefits?

It's a stretch, but here it goes... Private member-functions need not
worry about checking the class invariant nor ensuring it upon exit,
public member-functions do. Giving them different naming conventions
might be useful to show this from within the source file without having
to check the header. However, if I'm right, then making protected
functions the same as private doesn't necessarily make sense, many of
them must insure class invariants as well... And of course, if none of
the programmers know that this is the justification, then the naming
convention isn't doing its job anyway.

 

[Jonathan Turkanis]

tHaT's NoT eStHeTiC.

eVeNsCrEwY?

Jonathan

 

[Risto Lankinen]

that code duplicates no behavior?

.... that no code duplicates behaviour, you mean?

- Risto -

 

[DeMarcus]

There's nothing wrong with making things even more clear and readable.
You may have a different oppinion than your collegues what's clear and
not, but to me it sound like a big mistake trying to change a comapany's
coding convention unless you're hired for that reason. There's a lot
of other interesting tasks to take care of than reinventing the wheel,
at least according to all members of a company board.

You may have a point though, and it could be worthwhile have a look at
it when a completely new and independent project is upcomming, but don't
harass your poor project manager with such small things. He's trying to
survive day by day making the CEO pleased.

Don't take me wrong. Standards are good, everyone should have one.


Best Regards
Daniel Marcus

 

[jeffc]

The other developers swear that this convention makes code
easier to understand, but not one of can give me a concrete
justification.

That's because chocolate is better than vanilla, even though I can't
actually prove it.

 

[jeffc]

My goal wasn't
to solicit a psychic reading; just to possibly hear from
someone who can offer an objective justification for this
peculiar naming scheme.

There isn't one.

I can't see the benefit either. As for why they keep using
it, my theory is that it's a misguided convention (akin to
that used to differentiate access for data members) that
got used, gained critical mass, and now everyone keeps
doing it for no reason other than to keep the code looking
consistent.

Consistency IS an objective reason to use something.

 

[Cy Edmunds]

How about this one: member functions must have names with strictly
alternating uppercase and lowercase letters.

Jonathan

Good point. Although I generally prefer

mY cAPS lOCK kEY iS iN tHE wRONG pOSITION

style.