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

 

[Bret Pehrson]

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

 

[Victor Bazarov]

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.

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

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.

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?

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?

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]

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

Yup. Elegant, isn't it?

 

[Victor Bazarov]

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

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

 

[Derek]

Yup. Elegant, isn't it?

Sorry...replied to the wrong message.

 

[Claudio Puviani]

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?

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]

Sorry...replied to the wrong message.

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

 

[Victor Bazarov]

Yup. Elegant, isn't it?

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

V

 

[Derek]

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

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.

Then you have to talk to those who established such
naming convention.

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.

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?

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.

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.

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]

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?

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]

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.

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!

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.

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.

...now everyone keeps
doing it for no reason other than to keep the code looking
consistent.

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

 

[lilburne]

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.

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.

Anyone see the benefits?

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]

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(void);
protected:
void hello_i_am_protected(void);
private:
void this_one_is_private(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?

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]

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?

I don't.

 

[Phlip]

I don't.

Any esthetic style guide, even a screwy one, if followed, is better than
none.

 

[Victor Bazarov]

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

Do you consider the underscore to be an uppercase or a lowercase letter?
What about them digits?

 

[E. Robert Tisdale]

Any esthetic style guide, even a screwy one, if followed,
is better than none.

aesthetic or esthetic

ADJECTIVE:
1. Relating to the philosophy or theories of aesthetics.
2. Of or concerning the appreciation of beauty or good taste:
the aesthetic faculties.
3. Characterized by a heightened sensitivity to beauty.
4. Artistic: The play was an aesthetic success.
5. Informal Conforming to accepted notions of good taste.

NOUN:
1. A guiding principle in matters of artistic beauty and taste;
artistic sensibility: “a generous Age of Aquarius aesthetic
that said that everything was art” (William Wilson).
2. An underlying principle, a set of principles, or a view
often manifested by outward appearances or style of behavior:
“What troubled him was the squalor of [the colonel's] aesthetic”
(Lewis H. Lapham).

"Beauty is in the eye of the beholder."
"There is no accounting for taste."

 

[Jonathan Turkanis]

Any esthetic style guide, even a screwy one, if followed, is better than
none.

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

Jonathan

 

[Jonathan Turkanis]

Do you consider the underscore to be an uppercase or a lowercase letter?
What about them digits?

I interpret my rule to outlaw underscores and digits. I'm going to try
it tonight. I'll let you know how it turns out.

Jonathan