|
|
Re: Refactoring addicts and dynamic languages
|
Posted: Apr 3, 2008 7:42 AM
|
|
> > Having done (still doing, actually) my share of
> > maintenance, I can safely say that any code base that
> took
> > me weeks to grok was not due to horribly ambiguous
> names.
> > Bad pointers, poorly documented side effects, methods
> > doing too many things and stuff like that are usually
> the
> > cause of my maintenance angst. I've never run into a
> > project where things were so horribly named as to cause
> a
> > major delay in grokking the code base. And I've seen
> some
> > horribly named things.
>
> Even if the code is designed wonderfully, if a subroutine
> or method I don't need to change is well named, then I
> won't have to delve into its well-written logic. If it's
> poorly named, then I have to read it anyway, just to
> figure out what exactly _is_ that one thing it does. In a
> large system, that's a lot of extra code-reading.
Perhaps a skunk doesn't stink as bad if you call it a polecat?
If you don't read the code, how do you know it is well named? If you think the name is good, you are going to trust the author that the method does as advertised? I'm assuming by well named you mean something like 'GetFirstDerivative' vs. something like 'dX'. The thing is, the 'better' named method is just as likely to collect cruft and have side effects as the poorly named one.
Good method names are, at best, a signpost. In and of themselves they don't mean much. And as far as refactorings go, renaming is is probably least useful and easiest to do, which is why people probably spend a good deal of time on it.
Maybe I have trust issues, but I want to know what's going on with the code when I'm working with it. I'll read the methods, well named or not, if I'm doing something that either will affect them or I am depending on what they do. I may not delve, but I'll at least give it a once over. If the logic is hairy, I'll delve, wheter the method is well named or not.
|
|
Previous Topic
