This page contains an archived post to the Design Forum (formerly called the Flexible Java Forum) made prior to February 25, 2002. If you wish to participate in discussions, please visit the new Artima Forums.

Message:

Naming methods: no simple answers

Posted by Bill Venners on 13 May 1998, 1:49 AM

John,

> I think this question is at least slightly related to
> your column and find it to be the challenging part for
> me in arranging my code into methods.

> My question is how to you name private methods differently
> than public methods?

> To use your doSomething(Component c) example, suppose
> we wanted:
>

> public void doSomething(Component c) {
> 	if(c.isVisible()) {
> 		//call some private method
> 	} else {
> 		//call some other private method
> 	}
> }
> 

> Now what should we name the private methods?
> Verbose names could be:
> private void doPrivateSomethingNotVisible(Component c);
> and
> private void doPrivateSomethingVisible(Component c);

> This is a little long for my taste, but clear. Is
> adding the "Private" qualifier good?

> I often find that I want a public method with a name
> and I private one(s) with the same name, where the
> public method uses queries to handle control
> and requirements rules while the private one(s) does
> the actual work.
>
I've run into the same kind of problem before, and have ended
up with some clumbsy names at times. I've never put the word
"private" in the method name I don't think. I have usually
tried to just describe in more detail what the method does.
So in your example, I might have gone with doSomethingWhenVisible()
and doSomethingWhenNotVisible() or something like that. Pretty
ugly.

I have always tended to make long names for methods and classes
and variables and so on, because I felt it helped make the code
more self-documenting. But the problem is that then it is a pain
to type and to fit anything else on the same line. So the ideal
name is one that is short, but extremely clear.

Sometimes, trouble coming up with a name for a method can be
a sign that the method isn't cohesive enough to begin with. If
I find myself wanting to name a method
doSomethingOrDoSomethingElseOrDoSomethingElse()
then I may have a method that isn't very cohesive. But nicely
cohesive methods can be hard to name sometimes as well.

I guess I would just try and use the same approach to naming
private methods as I do methods with any other access level.
Use a name that describes what the method does as clearly as
possible in as few characters as possible (but don't be
afraid of relatively long names, if that's what it takes to
be clear).

bv