Ole Ersoy a écrit :
<snip/>
Incidentally I think we should apply this type of convention
to all java members and variables.
I'm not so incline to this kind of convention. People are smart enough
to figure out what is what with short names. 'i' is self-explicit, for
instance. And the fact is that long variable names (say, above 12 chars)
generate more problems than short ones (mispelling, confusion, case
problem, etc). I have read an interesting study about this aspect, I
don't remember where (may be Writing Solid Code, or a study done by
NASA, can't remember, it was 15 years ago) where it was clearly exposed
that there is a limit for variable length above which the developpers
are likely to generate more bugs ...
When creating an Attribute like this for instance;
Attribute objectClass = new BasicAttribute();
Some call it Attribute oc...
I call it
objectClassAttribute
Why ? Here, you *know* that objectClass is an Attribute, because its
type is Attribute. As we are not using 'vi' anymore (or only from time
to time), you have many ways to get this information.
<snip/>
Also, if it were called just objectClass...I might just wonder
whether it's an ObjectClass or Attribute...so by postfixing the
Type we avoid the "What is that thing again?" scenario.
Please, no more hungarian notation ! (I don't know if I should whish
that Soyouz don't come back to earth, and let Simonyi turn around the
planet for ever, to punish him for having added those stupid lpstrch and
zptrpch before or after every variable names ...)
As a rule this convention could be expressed as "Append the Type to
the end of a member". Sometimes it's really really obvious, but as
the code
base grows and more gets added to the file, it becomes less obvious.
Just use common sense, here. If it's not obvious when you write it, then
adopt another name. It should be enough as a convention. If it's not,
then you are lacking of common sense (and be sure that sometime, we are
all fools ...)
<snip>
When everyone follows conventions like this, it makes it a lot
easier to read code, because we know what the conventions are,
and thus we can immediately identify what someone is referring to...
You also have to consider anothe relement you are missing : using long
variable names, concatenating many words, could drive the code to be
full of meaningless names : many of us are not english natives, and we
may perfectly abuse the names so badly simply because we are not used to
them. It's more difficult to FU when using a simple name like 'context'
than something like partitionConfigurationServiceContext' which means
nothing at all (this is a clear example extracted from some code I just
committed this afternoon, and I'm not proud of it ... :(
Emmanuel.
Cheers,
- Ole
