Naming of private functions

[Derek]

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 somePublicMembe rFunction();
protected:
void hello_i_am_prot ected();
private:
void this_one_is_pri vate();
};

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?

[Bret Pehrson]

Re: Naming of private functions

What is the convention if a previously protected/private method is 'promoted'
to public? Search-and-replace name change?

Derek wrote:[color=blue]
>
> 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 somePublicMembe rFunction();
> protected:
> void hello_i_am_prot ected();
> private:
> void this_one_is_pri vate();
> };
>
> 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?[/color]

--
Bret Pehrson
mailto:bret@inf owest.com
NOSPAM - Include this key in all e-mail correspondence <<38952rglkwdsl >>

[Victor Bazarov]

Re: Naming of private functions

"Derek" <me@nowhere.spe cial.com> wrote...[color=blue]
> 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 somePublicMembe rFunction();
> protected:
> void hello_i_am_prot ected();
> private:
> void this_one_is_pri vate();
> };
>
> The other developers swear that this convention makes code
> easier to understand, but not one of can give me a concrete
> justification.[/color]

Naming conventions are intended to give the reader a way to
quickly understand something about the symbol, in your case it
is probably the fact that the function is (a) a member and (b)
a public or private/protected one. If in your project the
access rights to the symbol make such a difference as to
justify having a different naming convention for the functions,
then the difference is only known to those who are involved in
the project...
[color=blue]
> 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.[/color]

Then you have to talk to those who established such naming
convention. And unless one of your colleagues reads this NG
as well, you're better off off-line. Without seeing more
of the code or even working on it for some time, how could
any of us successfully guess the intentions of the author
of the convention?
[color=blue]
> 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?[/color]

I can't say that I've _used_ such convention, but there is
probably something there, otherwise why would people keep
using it? But, alas, I can't say I see it. :-)

V

[Derek]

Re: Naming of private functions

Bret Pehrson wrote:
[color=blue]
> What is the convention if a previously protected/private
> method is 'promoted' to public? Search-and-replace name
> change?[/color]

Yup. Elegant, isn't it? :)

[Victor Bazarov]

Re: Naming of private functions

"Bret Pehrson" <bret@infowest. com> wrote...[color=blue]
> What is the convention if a previously protected/private method is[/color]
'promoted'[color=blue]
> to public? Search-and-replace name change?[/color]

In fact, the compiler should help with that. You change the name in
the class definition, recompile the relevant modules, and suddenly
you have some undefined members (unless there is another member with
the same name and convertible argument types, that would be nightmare).

Perhaps such convention was specifically introduced to prevent such
migrations of private/protected members to public...
[color=blue]
>
> Derek wrote:[color=green]
> >
> > 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 somePublicMembe rFunction();
> > protected:
> > void hello_i_am_prot ected();
> > private:
> > void this_one_is_pri vate();
> > };
> >
> > 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?[/color]
>
> --
> Bret Pehrson
> mailto:bret@inf owest.com
> NOSPAM - Include this key in all e-mail correspondence <<38952rglkwdsl >>[/color]

[Derek]

Re: Naming of private functions

Derek wrote:
[color=blue]
> Bret Pehrson wrote:
>[color=green]
>> What is the convention if a previously protected/private
>> method is 'promoted' to public? Search-and-replace name
>> change?[/color]
>
> Yup. Elegant, isn't it? :)[/color]

Sorry...replied to the wrong message.

[Claudio Puviani]

Re: Naming of private functions

"Derek" <me@nowhere.spe cial.com> wrote[color=blue]
> 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, [...]
>
> The other developers swear that this convention makes code
> easier to understand, but not one of can give me a concrete
> justification.
>
> Anyone see the benefits?[/color]

Without being a psychic, I can't tell you the benefits in your context, but I
can imagine a context in which that may be beneficial. It often happens, in
high-level classes, that public methods perform all manners of validations,
locking, parameter translation (symbolic to index, for example), etc. either to
provide easier interfaces or to protect the client programmer from him/herself.
The private member functions, on the other hand, can be free to make assumptions
about the arguments, the state of the object, etc. and are therefore much
lighter and efficient, but also less safe. In that kind of scenario, it may be
desirable or even required to only call private methods from other methods and
the different naming conventions would help you to visually identify deviations.

Even without semantic differences like I just described, it may still serve a
purpose. Determining whether a method is public or private isn't a question of
whim. It's fundamental to the design of a class. It may well be that they have
that naming convention to discourage people from frivolously altering the
visibility of the methods just because it seems convenient at a given moment.

Whether or not anyone likes the aesthetics of the code, one can certainly make a
software engineering case for doing that.

Claudio Puviani

[Derek]

Re: Naming of private functions

Derek wrote:[color=blue]
> Sorry...replied to the wrong message.[/color]

Hmmm. Acually I didn't. It appears Thunderbird doesn't sort
messages in threads correctly until I refresh. Odd. And
off-topic.

[Victor Bazarov]

Re: Naming of private functions

"Derek" <me@nowhere.spe cial.com> wrote...[color=blue]
> Bret Pehrson wrote:
>[color=green]
> > What is the convention if a previously protected/private
> > method is 'promoted' to public? Search-and-replace name
> > change?[/color]
>
> Yup. Elegant, isn't it? :)[/color]

Elegance is often the last thing on the mind of a naming
convention inventor, I bet.

V

[Derek]

Re: Naming of private functions

Victor Bazarov wrote:[color=blue]
> Naming conventions are intended to give the reader a way
> to quickly understand something about the symbol, in your
> case it is probably the fact that the function is (a) a
> member and (b) a public or private/protected one. If in
> your project the access rights to the symbol make such
> a difference as to justify having a different naming
> convention for the functions, then the difference is only
> known to those who are involved in the project...[/color]

This a company-wide C++ naming rule. It applies to all
projects, from low-level system code to application-level
GUI code. There is no domain-, industry-, or project
specific need for it that I can see.
[color=blue]
> Then you have to talk to those who established such
> naming convention.[/color]

As I said in my original post, they offer hand-waving and
"gut feelings" in the way of explanation. They just "like
it" and aren't sure who originally proposed it way back
when. They can't justify it rationally to me, which is why
I turned to this broader forum for opinions.
[color=blue]
> And unless one of your colleagues reads this NG as well,
> you're better off off-line. Without seeing more of the
> code or even working on it for some time, how could any
> of us successfully guess the intentions of the author of
> the convention?[/color]

Again, there is no resident author the other developers
are just "used to it." I've been working with the code
for months with no clear benefit in sight. 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.
[color=blue]
> I can't say that I've _used_ such convention, but there
> is probably something there, otherwise why would people
> keep using it? But, alas, I can't say I see it. :-)[/color]

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. :)

[Phlip]

Re: Naming of private functions

Derek wrote:
[color=blue]
> 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?[/color]

Generally, I call things and references aThing, pointers or smart pointers
pThing, and members m_pThing.

I give important classes and functions a capital leading letter, and
unimportant ones a lowercase leading letter. Few _ because they are hard to
type.

But fixating on completely different styles for public and private members
makes refactoring difficult. Programmers should change designs as a program
grows and they learn. But changing names as something becomes private slows
down refactoring.

Encapsulation is hierarchical. That means some entire classes should be
private to a file, or to another class. These would also have to participate
in your naming scheme.

--
Phlip

http://www.xpsd.org/cgi-bin/wiki?TestFirstUserInterfaces

[Phlip]

Re: Naming of private functions

Derek wrote:
[color=blue]
> This a company-wide C++ naming rule. It applies to all
> projects, from low-level system code to application-level
> GUI code. There is no domain-, industry-, or project
> specific need for it that I can see.[/color]

Do they also require:

that every line of code have a unit test?

that no function be longer than 8~12 lines?

that all variable names are pronouncable and intention-revealing?

that all functions use verbs?

that all data members are private?

that code duplicates no behavior?

that nobody pack more than 2~3 operations on one line?

that everything has the narrowest scope possible?

that everything compile with as many warnings turned on as possible?

that the integration process have complete and robust build scripts?

that no function contain more than 3 levels of nested blocks?

that no function have >5 arguments?

that the object model follow the Liskov Substitution Principle, Model View
Controller, Law of Demeter, Dependency Inversion Principle, Interface
Segregation Principle?

that the first #include for file Thing.cpp should be Thing.hpp?

that each header file use as few nested includes and as many forward
declarations as possible?

that every member function declare out-of-line unless profiling moves it in?

that every rule in /Effective C++/, /Exceptional C++/, and /Large Scale C++
Software Design/ is followed?

Love those empty specifications that made some spec author feel important!
[color=blue]
> As I said in my original post, they offer hand-waving and
> "gut feelings" in the way of explanation. They just "like
> it" and aren't sure who originally proposed it way back
> when. They can't justify it rationally to me, which is why
> I turned to this broader forum for opinions.[/color]

Is the code more readable because of it?

Whether it is or not, useless esthetic style guidelines, such as where to
put {} braces, are a Good Thing. They help people read the source. But they
work best in the presence of real technical standards that improve code
robustness.
[color=blue]
> ...now everyone keeps
> doing it for no reason other than to keep the code looking
> consistent. :)[/color]

Right. Keep doing it. It's not slowing you down, right?

--
Phlip

http://www.xpsd.org/cgi-bin/wiki?TestFirstUserInterfaces

[lilburne]

Re: Naming of private functions

Derek wrote:
[color=blue]
> 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 somePublicMembe rFunction();
> protected:
> void hello_i_am_prot ected();
> private:
> void this_one_is_pri vate();
> };
>
> The other developers swear that this convention makes code easier to
> understand, but not one of can give me a concrete justification.[/color]

Its a pity that the rationale for the decision wasn't
recorded, and quite possible that the rationale doesn't hold
today. However, if other developers are saying that within
their codebase this naming convention makes the code easier
to understand then that is justification enough.
[color=blue]
>
> Anyone see the benefits?[/color]

As I don't generally like private functions in classes, this
particular naming convention isn't one I'd personally find
beneficial.

[E. Robert Tisdale]

Re: Naming of private functions

Derek wrote:
[color=blue]
> 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 somePublicMembe rFunction(void) ;
> protected:
> void hello_i_am_prot ected(void);
> private:
> void this_one_is_pri vate(void);
> };
>
> 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?[/color]

These are classic symptoms of a dysfunctional software engineering team.
A megalomaniacal team leader or oligarchy attempts to mold every thought
of every team member so they behave as a single super programmer.
(Physicist call particles that behave this way *bosons*.)
The team wastes most of its time in an unending sequence of meetings
where most of the teams members must listen patiently to subjects
that don't concern them or their contribution to the task.
They are compelled to write all of their code from scratch
because their "style" rules preclude importation and reuse
of any code written elsewhere. Their goal is to write code
which any team member can checkout and modify at any time --
a policy which, if actually practiced, leads quickly to chaos
and eventual collapse of the entire project.
They turn *guidelines* to good programming practice in to *rules*
which are thoughtlessly applied to every circumstance.

If you find yourself in such a software development team,
you have good reason to be alarmed.

[Cy Edmunds]

Re: Naming of private functions

"Derek" <me@nowhere.spe cial.com> wrote in message
news:bvu5kn$10g 8aa$1@ID-46268.news.uni-berlin.de...[color=blue]
> 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 somePublicMembe rFunction();
> protected:
> void hello_i_am_prot ected();
> private:
> void this_one_is_pri vate();
> };
>
> 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?[/color]

I don't.

--
Cy

http://home.rochester.rr.com/cyhome/