Re: Shortened names
Frederick Gotham wrote:
This is mostly about my own personal taste, but still I'd like
to express my opinion:
I'd like to suggest to the Committee that they use identifiers
as short as possible for future additions to the standard.
For what definition of "possible"? For example, the committee
could have used v, instead of vector, i instead of iterator, c
instead of complex... It would certainly be easier to type:
m< s, s >
than std::map< std::string, std::string >. (Obviously, if we're
making names as short as possible, we'll have to get rid of all
this std:: junk.)
There are 32949 legal two character names. I don't think off
hand that the library defines more symbols than that, so
strictly speaking, as short as possible means no identifier with
more than two characters. Of course, some of the names will
have to be pretty arbitrary---there are considerably less
countries, and look at some of the two letter abbreviations for
those (zh for China, for example).
I like names such as:
pow
memcpy
fmod
qsort
strlen
puts
malloc
The C++ replacements actually shorten most of those: sort,
instead of qsort, new instead of malloc, copy instead of memcpy,
size instead of strlen, << instead of puts. That leaves pow and
fmod--pow is probably optimal, given history and extra-C++
usage. But who knows, off hand, what fmod means? Especially
in the C library, which generally uses an initial f as an
indication that the function deals with FILE*. That one should
be clearer.
In the current Standard, I particularly think the new-style
casts are monstrosities:
static_cast
dynamic_cast
reinterpret_cast
I think that's intentional. Tu discourage unnecessary use.
They take up a disproportionate amount of horizontal
screenspace, and are a lot less pleasant to have to type out
(particularly "reinterpret_cast").
I can make the window on my screen 200 and some characters wide.
And I don't know if you realize this, but C++ allows line breaks
in expressions as well, so you can even use them and keep the
line length under 80 characters (as I do). And of course,
they're not something that occurs often in the code.
Note too that these are keywords. There are no namespaces to
prevent conflicts, and they were added relatively late. At
least a minimum effort was required to avoid having them colide
with likely identifiers in user code.
I would prefer the likes of:
alignof
instead of:
alignment_of
Of course, this is just my own opinion, and others' opinions
may differ... but nonetheless I'd like to throw in my two
cents.
Readability is more important than writability---a program is
written once, but read many times. Readability is important.
Having said that, there are trade-offs involved. Something like
int is so frequent that anyone working in C or C++ will
recognize it immediately; very little, if any, readability would
be gained by replacing it with integer. On the other hand, C
experimented with replacing it with nothing---with the empty
string---in some contexts, and I don't think that that
experiment can be considered a success (although it's hard to
have an identifier with less than 0 characters in its name).
Similarly, I suspect that even you would object to using
arbitrary sequences just to get the name down to two characters.
In the end, the rule should be, first, consistency---you don't
call it getline (without an _) but find_end (with an _), and you
don't abbreviate something in one symbol, and not in another.
Beyond that, trying to find meaningful short names for
frequently used identifiers is probably a good idea: find is
probably a better name than
find_the_first_value_equal_to_the_third_argument, even if the
latter is arguably clearer. For something as little used as
alignment_of, however, who cares.
--
James Kanze GABI Software
Conseils en informatique orient9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S9mard, 78210 St.-Cyr-l'cole, France, +33 (0)1 30 23 00 34
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]