Re: Hungarian notation
On 24 mar, 05:23, Andrey Tarasevich <andreytarasev...@hotmail.com>
wrote:
James Kanze wrote:
...
> Disagree. It's just another convention to learn.
There's _always_ a convention.
Yes. You agree on standard names for common concepts. In the
old days, when variable names were limited to six characters,
you established standard abbreviations as well. This shouldn't
be necessary for modern C++. (But might be appropriate in
contexts where the abbreviation was more frequently used than
the spelled out word. In a program dealing with certain types
of standards, for example, RFC1411 is probably preferable to
requestForComment1411.)
You base your argument on the assumption that the main and/or
only reason to strive some form of brevity in identifiers is
(or, more precisely, was) the limitation on the identifier
length specific to old compilers. To me this is an obviously
faulty argument. Even without any physical limitation on the
total length of the identifier, there always be some
non-precise intuitive limit after which the overly long
identifiers will severely hinder the readability of the code.
Sure. You don't express the entire contract of a function in
the function name (e.g.
lookupWhateverAndThrowNotFoundExceptionIfNotFound---I did once
encounter a programmer who did this, with function names often
over 100 characters). Still, a variable should represent one
thing, and a function should do one thing. If you need
abbreviations to avoid unacceptably long names, it's probable
that your functions are doing too much, or your variables are
too encompassing.
In general, a verb or a verbal phrase should suffice for a
function, and a qualified noun (a noun with an adjective) for a
variable. And there's no need to abbreviate in those cases.
In order to keep the code readable the identifiers have to be
reasonably long (and I personally stick with one that are
usually seen as excessively long by the other members of the
team I work in), but the lion's share of their lengths has to
allocated to describe things closely specific to the concrete
application and/or the field. This is exactly the reason why
the more universal concepts are better expressed in the
abbreviated form.
And no, the picture here is not as black-and-white as you are
trying to paint it ("standard" and "non-standard" prefixes).
It is also strange to see you use that argument against
prefixes specifically, while it is obvious that the same will
actually apply to all abbreviations in general.
Quite. I never restricted it to prefixes, or at least, I didn't
mean too. There are certain cases where abbreviations are
advisable, but that's because (as in the case of RFC above) the
abbreviation is actually better known than what it stands for.
And in practice any project of moderate level of complexity
will normally have a developed system of abbreviations, which
definitely will not be "standard". More precisely, it is of
course possible to get along without any abbreviations at all,
but it will be no more than an example of stubbornly bad
programming style.
Or simply writing good code, which expressively says what it
does.
Certain aspects of the variable semantics have to be
reflected in variable name. That's what variable names are
for, among other things. If you don't do it at all or do it
inconsistently (without any convention), your code isn't
worth much in my book.
Prefixing is no worse and no better than anything else.
Arbitrary conventions are worse than natural conventions.
Firstly, "arbitrary convention" is an oxymoron, if you think
about it.
Not necessarily. Not all conventions are arbitrary. The C++
standard is a convention, and while parts of it are more or less
arbitrary, others (relative precedence between addition and
multiplication) are based on wider conventions (which may be
arbitrary), and still others are based on pragmatic issues (a
different convention would be considerably more difficult to
implement, without any compensating advantage).
In the case of names, it's true that in a certain sense, all
spelling is an arbitrary convention. But it's also true that
the one described by Merriam and Webster is more widely known
and accepted (and thus more readable) than any other convention
you might establish in house.
Secondly, any convention is better than no convention. After
all, there one fundamental rule under all these different
views and approaches: whatever one chooses to do, one must be
consistent.
Totally agreed. Systematically using ptr for pointer may not be
as good as using pointer, but it's a lot better than sometimes
using one, sometimes the other.
The proper name of the variable to store a quantity of
polygons is 'n_polygons'. And no CamelCase, as you see.
The proper name is polygonCount or polygon_count. Or possibly
numberOfPolygons or number_of_polygons. (The choice of
camelCase or not is purely conventional.)
Absolutely not. 'numberOfPolygons' and 'number_of_polygons'
might seem OK only to those who fail to see the whole picture.
Once they do, it becomes obvious that 'number_of_polygons'
blatantly unacceptable in general. It is immediately clear to
anyone who ever have to deal with
'number_of_incomplete_table_based_mos_transistor_models' (it's
just one example).
And you're claiming that replacing number with n in the above
will somehow miraculously make it readable?
Of course, you can personally resolve to sticking to
'number_of_...' no matter what and tell everyone around that
your are perfectly happy with that, but don't be surprised if
from time to time people around you will give you polite hints
about the value of proper abbreviation.
I suspect rather than people will give me polite hints about the
value of proper abstraction and information hiding.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34