[Cosmo-dev] Commit 5847

[Brian Moseley]

On 10/8/07, Matthew Eernisse <mde at osafoundation.org> wrote:
> At some level, I think
> it's a matter of taste -- one man's "longer and descriptive" might be
> another's "needlessly verbose and distracting."

i have been on both sides of this debate. i've found in over a decade
of working with other people that the vast majority prefer expressive
names to terse ones. it seems that is more comprehensible for most
people. i stopped fighting against long names a long time ago (except
in certain places where i think brevity is extremely useful, like with
query string parameters in URLs).

> It was easier for me to read
> before the refactoring, to see that "d" represented in each case "the
> DOM node container for the current layout item."

yes. loop variables and others that are tightly scoped are usually
fine. these are examples where the utility of verbose naming is not
great.

> In this case though, it doesn't really seem like a trip through the
> Swamps of Sadness. Unless I'm missing something totally obvious, I think
> it's actually pretty easy to search for even a terse variable name like
> "reg," at least in Vim or grep:
>
> Vim:
>
> /reg\W
>
> Grep:
>
> grep -r "reg\W"

i think that having to search for a symbol with a regular expression
is a "code smell".

> It might also be worth mentioning the idea that improved test coverage
> is supposed to make us more comfortable doing continuous refactoring to
> keep the codebase healthy. I know it's not entirely realistic to think
> it will catch every regression -- and you still have to fix the
> regressions after you catch them.

in general that's true, but we should have as little instability as
possible while preparing bugfix releases. i like to refactor all the
time too (did you notice that i rewrote the dav access control system
two days before the feature complete date?), but we have to be
disciplined and minimize or eliminate those changes when we're focused
on precision attacks against bugs.

if you're worried about forgetting to do some ambitious refactoring
work at the beginning of the next dev cycle, keep a task list. here's
mine: http://chandlerproject.org/bin/view/Journal/BrianMoseleyNotes