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

61–70 of 120 posts

Re: Never edit a method, always rewrite it?

#61

Post by tvst »

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.

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.

Re: Never edit a method, always rewrite it?

#62

Post by reificator »

qznc wrote: post #23

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

All other criticism of this wrapper approach aside, it does at least prevent a near worthless history. If you're forced to rewrite, that is.

Re: Never edit a method, always rewrite it?

#64

Post by koonsolo »

tvst wrote: post #61
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.

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.

Re: Never edit a method, always rewrite it?

#66

Post by reificator »

js8 wrote: post #9

I 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…

I've heard of a few systems that help you manage this kind of thing.

Most people use git, but there's also cvs, svn, hg, perforce, bzr, and probably some others in use that I'm forgetting.

Leave the history to those tools, they make it easy to change things as much as you'd like without losing work.

Don't work against them with policies like this.

Re: Never edit a method, always rewrite it?

#67

Post by weberc2 »

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.

That's remarkable. I typically find it harder to shoehorn some new idea into existing, often badly-written code than to reimplement something appropriately general. This isn't meant to rebut your point; simply another observation.

Re: Never edit a method, always rewrite it?

#68

Post by Can_Not »

EGreg wrote: post #13

I had a different rule, which I was advocating for PHP 5.3 back in the day: Have functions take regular parameters and the last one will always be an associative array of options. This matches how functions evolve. You have some required parameters, then introduce more but the old callers don't know about them so they're optional. I was trying to argue that PHP could unify the function call syntax and array definitio…

It's likely that you should upgrade that last options array into an object (and maybe even move the function there).

Re: Never edit a method, always rewrite it?

#70

Post by Klathmon »

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.

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 down your actual problem most of the time.

And that test (assuming it's not extremely slow to run), takes very little to maintain, so leaving it in the suite of tests is basically a positive only.

Post reply on HN