Re: Reference question
On 2009-01-29 12:08:39 -0500, Jeff Schwab <jeff@schwabcenter.com> said:
Pete Becker wrote:
How would you refactor a name like time_since_epoch(), which takes up
20% of my line every time I have to use it?
Why does 20% concern you? Just how many names per line are you trying
to achieve?
As many as are needed.
sumOfTheThingsICareAbout = firstThingICareAbout
+ secondThingICareAbout
+ thirdThingICareAbout;
sum = first + second + third;
sum = a + b + c;
In that last one, the numbering is implicit in the names. No need to be
longwinded.
Have you ever tried to read Java code? The long-names-are-good
designers had a field day there, and the result is often quite hard to
read.
Oh, and I can't change it: it's part of the interface to a library that
I don't control.
Boo hoo. Nobody ever taught you about inline wrapper functions?
Oh, good idea: I'll just write a new class that provides the interface
that I prefer. Everyone who maintains my code can then learn my
interface as well as the library's interface.
If the meaning is already clear from context, use a simple name like
"time". Are you really claiming that you would have preferred an
interface with names like eptime, or timsinep?
No, certainly not. The fact that you can make up bad names doesn't mean
that names have to be too long.
Every time you add a dependency on some external library, do you really
just start using the library directly, from all over your code base,
without any insulation or compile-time wrapper layer? That seems...
Brittle.
Sigh.
I know that when I write code that uses libraries whose interfaces were
designed with "use long names" the result is unreadable.
Plenty of useful libraries have horrid interfaces, and "long names" are
hardly the worst part. The solution I tend to use is to build my own
little bridge layer that exposes the parts of the library I actually
use. It doesn't actually take that long, relative to the time saved in
not letting the poorly designed interface infect the rest of my code.
If it's strictly your code, knock yourself out. If you're part of a
project there's the cost of everyone else, including future
maintainers, having to learn an additional interface to something they
may already know well.
--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)