[Prev][Next][Index][Thread]

Re: Long names are doom ?


"Mark Wilden" <mark@mwilden.com> wrote in message
news:thvgoto9bgur7b@news.supernews.com...
> "Reinout Heeck" <reinz@Desk.org> wrote in message
> news:3B1FBC28.6FCD7029@Desk.org...
>
> > That is debatable,
> > one can think of situations during code maintanance that programmers
> > without domain knowledge will need to adjust the code.
> > If they only see 'greek' they won't be as productive.

My meager living is made by doing just that--cleaning up other people's
uncommented code, the point of which was forgotten long before. It's a
nightmare, and a few hints (that admittedly cost the original coder some
time) would make my job (and so many others') easier. They seem obvious, but
maybe that's why they keep getting forgotten. Or maybe there's a false
economy attitude that comments don't get the work done. :(  Anyway...

[1] Pull as much generic code as possible into a separate function where
variables like a, b and c are reasonable. Keep the domain-specific names in
the higher-level code. A trivial example is no write a generic sorting
routine rather than inlining the code. This approach seems easier to do in
languages like lisp, but in any language, try to go as far as possible in
this direction. There may even be a design patterns tie-in to make this
sound important enough to try. :)

[2] Maintain locality of explanations: Abbreviate only as far as you can
without having to move descriptions into another file, or worse, into
another subproject. The closer together the symbol and its definition, the
easier it is to see that an NMP (or whatever) is actually an
N<etc>M<etc>P<etc>.

[3] Sophisticated IDEs can help tremendously, as long as they display the
information you (might) need without the programmer having to switch mental
contexts to go hunt for it. On the other hand, as someone stuck with a
lesser editor still needs to be able to do the work, it's still preferable
(from my viewpoint) to have the code and explanations close enough for a
plain text viewer to be usable.


The first two points are synergistic, in that the more one separates the
generic from the specific, the more the generic code can be put out of sight
in some library, and domain-specific code with the special names can be kept
close together.

It all boils down (for me) to minimizing how much time is spent changing
mental gears looking for explanations, minimizing time spent on separating
the domain-specific from the generic, and therefore maximizing the time
spent on understanding the intent of the code.

> First of all, the thought of someone diving into code without domain
> knowledge is rather scary. Second, if it's possible to work on code
without
> domain knowledge (debatable), then it should be possible to work on code
> with "NMP" in it without needing to know what it means. Would it help to
> expand it to nextMatherizingPropersipper if the programmer doesn't know
what
> matherizing is or what the proper sipper does?

Not much (you knew that), unless there's a place to find the long name
explained. Even google can't help much with NMP. :) Type declarations in the
top-level code can help here, I think:

    NextMatherizingPropersipper* nmp = nil;

    if (nmp==nil) {...}

for example.

I hope this adds to the conversation...

Eric
Follow-Ups: