The Artima Developer Community
Sponsored Link

Weblogs Forum
Refactoring addicts and dynamic languages

16 replies on 2 pages. Most recent reply: Apr 3, 2008 7:42 AM by Merriodoc Brandybuck

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 16 replies on 2 pages [ « | 1 2 ]
Frank Silbermann

Posts: 40
Nickname: fsilber
Registered: Mar, 2006

Re: Refactoring addicts and dynamic languages Posted: Apr 3, 2008 7:12 AM
Reply to this message Reply
Advertisement
> 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.

Merriodoc Brandybuck

Posts: 225
Nickname: brandybuck
Registered: Mar, 2003

Re: Refactoring addicts and dynamic languages Posted: Apr 3, 2008 7:42 AM
Reply to this message Reply
> > 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.

Flat View: This topic has 16 replies on 2 pages [ « | 1  2 ]
Topic: Refactoring addicts and dynamic languages Previous Topic   Next Topic Topic: Math and the Current State of Coarse-Grained Parallelism in Python

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use