Re: Reference question
On 2009-01-29 12:57:15 -0500, Jeff Schwab <jeff@schwabcenter.com> said:
Pete Becker wrote:
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;
(1) That's only two names per line, with a single statement spanning
three lines.
Sigh. Yes, because the names were, cumulatively, too long to fit on a
single line. Since what should be one line is now three, there are two
fewer lines available to see the rest of the source code. That makes it
harder to get an overview of the code.
(2) No individual piece of code should have to refer to lots of
different long names. Nobody here is defending that.
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.
Java's a different language with very abstraction mechanisms. In Java,
you haven't even got typedef.
Sigh. Nevertheless, it shows what happens when long names take over.
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.
They're going to have to learn your code and conventions anyway.
Sigh. Sure: since they have to learn some stuff, why not dump even more in?
It's the application domain, not the library, that seems (in my
finite experience) to be the biggest hurdle for developers new to a
particular code base.
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.
Right. We agree. In my opinion, MolType is a bad name, and
chemistry::molecule is a better one. If your code is even reasonably
modular, you don't have to type chemistry::molecule all over the place.
Hmm, interesting: the names I refered to were, obviously, "eptime" and
"timsinep". But somehow you ended up talking about MolType, which
neither of us had mentioned. Bait and switch, anyone?
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.
OK... Sigh, too.
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.
Let me get this straight: We should tie our code to crappy library
interfaces, because some developers are already familiar with them?
Give me a break. If your application is doing anything interesting,
it's going to require layers on top of those libraries, anyway.
What I said was a pet peeve was inappropriate abbreviation. You seem
to have taken this as some kind of defense of long names. I'm not sure
how to make this any clearer, so unless you have something new to add,
I think we're through here.
It's quite obvious that we're through here.
--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)