Re: naming was: Using ReentrantLock
Pitch wrote:
Lew wrote:
A name whose every part contributes to understanding of the variable's role.
Pitch wrote:
You didn't answer my question. :)
Yes, I did. I said, "A name whose every part contributes to
understanding of the variable's role."
I agree mostly with what you say but maybe there should be exceptions:
Maybe there should be. Maybe those exceptions aren't so far outside
the box as you might think. though.
- IConfig vs Config: In Java we don't use "I" which makes very difficult
to distiguish a class from an interface.
Actually, it's simple. An interface is used as the type of the
variable, and a class is used in the 'new' expression.
Less dismissively, there are conventions that support the distinction
and give meaning to names. Where sensible, think of interfaces as
pure type, and their names should speak to that. This usually results
in a descriptive adjective as a type name, e.g., "Serializable" or
"Comparable". Sometimes it results in a noun that is clearly of very
general applicability, e.g., "List" or "Collection". Usually the
interface has a non-compound name.
If one must decorate a name to distinguish that it's a class, not an
interface, apply that decoration only to the class. There is no need
to prefix an interface with "I" - the lack of decoration and the
abstract simplicity of the name ("Config") suffice to do that.
Decorations for class names usually attempt to be in the problem
domain and allude to concrete characteristics, e.g., "HashSet",
":ConcurrentLinkedQueue". These examples also show that class names
tend to be compound words with the implemented interface as part of
the name, as in "ArrayList". If one absolutely cannot use a domain-
meaningful name, one convention in Java is to append "Impl" to the
type name, e.g., "AbstractMarshallerImpl", and the other is the
"Abstract" prefix to which you alluded. (See below.)
- Absence of "m" or "m_" forces us to uses "this.foo = foo" when we have
arguments of the same name. (Even though I mostly dislike C-like
naming).
And prepending "this." is a problem because ...?
- Even Java does not conform to this purpose-implementation rule; you
have "Abstract" for abstract classses.
Well, the purpose of "AbstractFoo" is to provide an abstract
implementation of a "Foo" type, so actually the "Abstract" prefix does
conform to the convention that the name reflect purpose. Unlike
"Object" or "Class" in a class name, "Abstract" does not duplicate
some already-obvious keyword in the language.
Not all purposes in a program are in the problem domain. A few are
specific to implementation, and that is why classes like
"AbstractList" exist.
--
Lew