Perhaps the "Second system effect" would not apply if methods are kept small, but is a method really a good unit of work for these kinds of ideas? Better rewrite units, classes, whatever can be isolated/encapsulated in a meaningful way.
Never edit a method, always rewrite it?
51–60 of 120 posts
Re: Never edit a method, always rewrite it?
#52A tangential thought but related: I would find this absolutely frightening. I understand the motivation behind it but I always like to start from something existing and editing it -- even if by the end nothing remains of the original. To some, an empty editor window is infinite possibility but to me, it's a "coders block", not sure how to phrase it. Infinite analysis paralysis perhaps.
I always split my editor window vertically, make some space over the method I want to replace and make sure the old version is visible on the other window, and then I rewrite it while referencing the old one. I only copy and paste stuff over if there's something I really don't wanna write again.
Re: Never edit a method, always rewrite it?
#53Devils advocate: If you make this a strict requirement for your code base people write wrappers all the time, which creates a huge mess: def newMethod(x): if x*2 == 42: return 36 return oldMethod(x) You cannot enforce the requirement anyway, because people will just copy-paste the code and edit it under a new name. You just cannot push this methodology unto developers.
Even if you could.... why not modify a method? What's wrong with modifying it? It's only bad if you don't fully understand what it does, and/or all the ways/contexts where it's used.
But, that's a sign, right? You can't ever hope to safely change that which you do not understand. If you're afraid of the codebase - I argue it's better to set aside time for making the codebase less intimidating, than to devise clever hacks/ "software process" for working around your lack of understanding. The latter will just make the codebase more intimidating, over time.
Re: Never edit a method, always rewrite it?
#54Saw the headline, first though "I'll bet this is about dynamically typed languages", and lo and behold > At a recent RubyConf... EDIT: just wanted to add that when I code in dynamically typed languages I'm inclined to do the same thing. Without rigidity provided by a strong type system it's too easy to mess things up. That's why I prefer strongly typed languages so I can benefit from the structure they enforce.
Dave Cheney is well known in the go community, and works at Heptio. I don't think dynamic typing has much to do with this article.
Re: Never edit a method, always rewrite it?
#55A tangential thought but related: I would find this absolutely frightening. I understand the motivation behind it but I always like to start from something existing and editing it -- even if by the end nothing remains of the original. To some, an empty editor window is infinite possibility but to me, it's a "coders block", not sure how to phrase it. Infinite analysis paralysis perhaps.
But this is different, because you already have: - the method's signature and spec - the changes in behavior you want
- tests
- history for file (and any bugs listed in there that had to get fixed more than once)
Re: Never edit a method, always rewrite it?
#56Saw the headline, first though "I'll bet this is about dynamically typed languages", and lo and behold > At a recent RubyConf... EDIT: just wanted to add that when I code in dynamically typed languages I'm inclined to do the same thing. Without rigidity provided by a strong type system it's too easy to mess things up. That's why I prefer strongly typed languages so I can benefit from the structure they enforce.
Dave Cheney is well known in the go community, and works at Heptio. I don't think dynamic typing has much to do with this article.
The author says Chad Fowler proposed this idea at RubyConf
Re: Never edit a method, always rewrite it?
#57[deleted]
Re: Never edit a method, always rewrite it?
#58I had a similar idea some time ago, that all the code should be write only. That is, you should always write new functions (and give them new names) instead of trying to rewrite them (if the spec changes, this assumes they were correct in the first place). I think it's only really doable in purely functional language (like Haskell), though. It sort of means versioning of individual functions, and also types. It's ver…
You should give PHP a try!
Re: Never edit a method, always rewrite it?
#59Earlier quoted context omitted.
But this is different, because you already have: - the method's signature and spec - the changes in behavior you want
- tests - history for file (and any bugs listed in there that had to get fixed more than once)
The first thing I thought when I read the title is what that would do to the history.
Looking at a diff and seeing a small modification to a method tells me more than a method that has entirely changed with for loops changed to while loops, indices replaced with iterators, different whitespace and brace placement, etc...
Re: Never edit a method, always rewrite it?
#60It has been my experience that after a substantial period of being in real use, methods embody tacit knowledge about the problem domain that isn't necessarily evident from their public interface. Because initially they didn't embody that, and it caused bugs, so people edited in fixes.
It has been my experience that rewrites from scratch typically lose all this tacit knowledge and re-implement the original bugs.