Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Never edit a method, always rewrite it?

dave.cheney.net

Post reply on HN
Print view View original

71–80 of 120 posts

Re: Never edit a method, always rewrite it?

#71

Post by soVeryTired »

JulianMorrison wrote: post #60

It 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.

The 'Chesterton's Fence' school of engineering...

https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence

Re: Never edit a method, always rewrite it?

#72

Post by IncRnd »

This is an interesting thought experiment.

Following the rewrite-not-edit method rule forces one to either sink or swim. And the only maintainable way to swim is to write small focused orthogonal methods that do one thing only. Otherwise, it is impossible at any scale to follow rewrite-not-edit.

I like take on different perspectives like this. Doing so ensures one thinks about how to design and what to code before simply diving in.

Re: Never edit a method, always rewrite it?

#73

Post by MiyamotoAkira »

koonsolo wrote: post #64
tvst wrote: post #61

Earlier quoted context omitted.

I'm not convinced of the "always rewrite" thing, but what you're talking about would be solved by writing tests when you fix a bug.

It's not the first time someone proposes to write a test when fixing a bug, but you have to question the actual ROI. At my previous job, they checked how likely it is for a fixed bug to reappear again. Odds are really low. So we decided it wasn't worth the investment to write a test specific for the bugs use-case, because it's unlikely to appear again. We focused our efforts to other, more effective things.

Furthermore to Klathmon, there is an opportunity cost. Because you don't have the test, changing that method in the future becomes problematic. Is not the bug reappearing, is the refactoring that cannot longer take place.

Re: Never edit a method, always rewrite it?

#74

Post by mcphage »

GreaterFool wrote: post #56
jtlisi wrote: post #54

Earlier quoted context omitted.

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

Yes, but the author of this article, which is discussing the idea, was written by Dave Cheney.

Re: Never edit a method, always rewrite it?

#75

Post by allengeorge »

chx wrote: post #28

A 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 find that happens when one - or all - of the following are true:

1. Don’t have a good understanding of the existing system architecture

2. Have not thought through the design of whatever has to be added, both in terms of function expectations or overall flow

3. Overly (?) concerned with “getting it right”; that can lead to paralysis: somehow you have to both demand the best of yourself at that moment and yet accept that despite it all you may not make the best choices - and that’s ok

Re: Never edit a method, always rewrite it?

#77

Post by taneq »

koonsolo wrote: post #64
tvst wrote: post #61

Earlier quoted context omitted.

I'm not convinced of the "always rewrite" thing, but what you're talking about would be solved by writing tests when you fix a bug.

It's not the first time someone proposes to write a test when fixing a bug, but you have to question the actual ROI. At my previous job, they checked how likely it is for a fixed bug to reappear again. Odds are really low. So we decided it wasn't worth the investment to write a test specific for the bugs use-case, because it's unlikely to appear again. We focused our efforts to other, more effective things.

If you rewrite a method from scratch rather than editing it, then those odds go way up.

Re: Never edit a method, always rewrite it?

#78

Post by wruza »

thejosh wrote: post #37
MattHeard wrote: post #31

Earlier quoted context omitted.

def foo_with_edge_case(x): if x == EDGE_CASE: return 36 return foo(x) seems clearer to me than stuffing the edge case handling into the foo method

If only you could pattern match x in the function def, would remove the need for this whole thing.

Aside from compile-time optimization, pattern matching is just this additional if at runtime. It is questionable if pattern matches make code more readable since when you see foo(42) call and def foo(42) is defined elsewhere, you can spend some time on original function until realizing that it’s not what you’re looking for. The same for type-based and operator overloading. It only makes code beautifu^W hard to guess.

Though it does look nice for fib and fac.

Re: Never edit a method, always rewrite it?

#79

Post by taneq »

atsjie wrote: post #5

When writing functions often I end up deciding fairly quickly if the function I am writing is intended to be reusable or not. If it is reusable I'll write it as a utility function, helper, lib, ... whatever the project's convention and language paradigm might be. Usually similar reusable functions already exist within the project. A significant portion of functions fall in another category; functions that actually ge…

I'd call it "bricks" vs. "mortar". Write your bricks to be reusable and modular. Write your mortar to be simple but don't stress too much about it, because it really only exists to glue your bricks together.

Re: Never edit a method, always rewrite it?

#80

Post by hacker_9 »

Klathmon wrote: post #70
koonsolo wrote: post #64

Earlier quoted context omitted.

It's not the first time someone proposes to write a test when fixing a bug, but you have to question the actual ROI. At my previous job, they checked how likely it is for a fixed bug to reappear again. Odds are really low. So we decided it wasn't worth the investment to write a test specific for the bugs use-case, because it's unlikely to appear again. We focused our efforts to other, more effective things.

We use the test as a way to prove we know what the bug actually is. Our debugging "path" normally is: 1. Find out bug exists 2. Write a test that can reproduce the bug 3. Distill that test down to the minimum needed 4. Fix bug until test passes 5. Test bug is actually fixed by trying to reproduce it the same way the user/bugreport did. When done like that, the test isn't "extra work" but is just part of narrowing dow…

Whist I agree with this approach, sometimes it just isn't possible if the code was written in a non-testable way to begin with. Such as code that hits the database a lot or relies on network data. In this case, weighing up the ROI is a worthwhile endeavour, with a note to refactor more thoroughly at a later date.
Post reply on HN