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

101–110 of 120 posts

Re: Never edit a method, always rewrite it?

#101

Post by TeMPOraL »

taeric wrote: post #94
allengeorge wrote: post #63

The headline is misleading IMO. The author is proposing “Never rewrite a method” _as a thought experiment_ to guide you to writing better code. Even the original proponent walked back from that idea moments after he proposed it.

Funny, a modern day waterfall method example.

Seems like Poe's law could be generalized into a heuristic about memetic hazards - no matter how much you guide and warn people, any idea you speak or put in writing can be taken in a way you did not intend. The chances increase with the size of the audience.

Re: Never edit a method, always rewrite it?

#102

Post by onlyrealcuzzo »

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.

Hey Julian, I have a startup that attempts to address this in a developer friendly way. I'd love to get your feedback if you'd like to see it. Reach out to me at yahn007 @ Gmail dot com. Hope to chat soon!

Re: Never edit a method, always rewrite it?

#103

Post by swlkr »

I’m not sure rewrite is the right word here. Always write a new version from scratch, use a different namespace, and never delete old code is a better idea. You can’t cause regressions if you never change old code that’s in use.

Re: Never edit a method, always rewrite it?

#104

Post by mpweiher »

cptskippy wrote: post #88
mcherm wrote: post #84

Earlier quoted context omitted.

Unit tests can only test certain kinds of behavior of the function under test. To give other kinds of examples, the current implementation might have used a clever trick to achieve faster execution (this cannot be evaluated with unit tests). Alternately, it might have been implemented so as to share common functionality with a different piece of code by calling a common subroutine. That sharing of functionality is pr…

> the current implementation might have used a clever trick to achieve faster execution (this cannot be evaluated with unit tests). Sure it can. I worked on a project with a pubic API with many time sensitive routines and we most definitely had unit tests measuring performance. The test failed if the execution time exceeded the acceptable threshold. > Alternately, it might have been implemented so as to share common…

> The test failed if the execution time exceeded the acceptable threshold.

In order to not be beholden to specific hardware/execution environment and absolute times, you can also compare an unoptimized version against an optimized version, so the test can be: optimized version must be 2x faster than unoptimized.

Of course if you actually have real-time requirements, it is good to test against those.

Re: Never edit a method, always rewrite it?

#105

Post by kibwen »

DavidWoof wrote: post #99
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.

That's sort of the point of the suggestion, I think. If you always rewrite from scratch rather than edit, this sort of tacit knowledge won't get embedded undocumented and untested into the middle of a function. This is sort of the great contradiction of software development. Untested legacy software is hard to work with. So should our focus be on how to work with legacy software or how not to create it in the first p…

One thing the OP doesn't address is, is the rewrite intended to be black-box or not? If not, then every "rewrite" will just be someone copy-pasting the old code with the new fixes, which seems completely pointless. And if it is a black-box rewrite, then all that tacit knowledge will be lost, leading to having the exact same bugs over and over and over and over again, forever.

I understand that this is all just a thought experiment, but there has to be a better way of framing it that isn't so immediately farcical.

Re: Never edit a method, always rewrite it?

#106

Post by s73ver_ »

criddell wrote: post #59
lallysingh wrote: post #55

Earlier quoted context omitted.

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

That's where commit messages come in. Sadly, those can be just as poor as inline comments for telling you why something was done.

Re: Never edit a method, always rewrite it?

#107

Post by DavidWoof »

kibwen wrote: post #105
DavidWoof wrote: post #99

Earlier quoted context omitted.

That's sort of the point of the suggestion, I think. If you always rewrite from scratch rather than edit, this sort of tacit knowledge won't get embedded undocumented and untested into the middle of a function. This is sort of the great contradiction of software development. Untested legacy software is hard to work with. So should our focus be on how to work with legacy software or how not to create it in the first p…

One thing the OP doesn't address is, is the rewrite intended to be black-box or not? If not, then every "rewrite" will just be someone copy-pasting the old code with the new fixes, which seems completely pointless. And if it is a black-box rewrite, then all that tacit knowledge will be lost, leading to having the exact same bugs over and over and over and over again, forever. I understand that this is all just a thou…

> And if it is a black-box rewrite, then all that tacit knowledge will be lost,

This is a thought experiment on how to avoid that tacit knowledge, not how to deal with it. Consider approaching every edit in the same way you'd approach new code: is the function adequately tested, does the function have a single responsibility, is the intent clear, etc.? The idea is that if you do this, then you won't reach the point where you have a 200-line method with tons of hidden business rules.

I agree there's probably a better way of framing this. Still, as a thought experiment, it's worth thinking about when you can and/or should do this.

Re: Never edit a method, always rewrite it?

#110

Post by aidenn0 »

kibwen wrote: post #105
DavidWoof wrote: post #99

Earlier quoted context omitted.

That's sort of the point of the suggestion, I think. If you always rewrite from scratch rather than edit, this sort of tacit knowledge won't get embedded undocumented and untested into the middle of a function. This is sort of the great contradiction of software development. Untested legacy software is hard to work with. So should our focus be on how to work with legacy software or how not to create it in the first p…

One thing the OP doesn't address is, is the rewrite intended to be black-box or not? If not, then every "rewrite" will just be someone copy-pasting the old code with the new fixes, which seems completely pointless. And if it is a black-box rewrite, then all that tacit knowledge will be lost, leading to having the exact same bugs over and over and over and over again, forever. I understand that this is all just a thou…

I'm glad it's immediately farcical because it should help people from not interpreting it as actual advice (even with as farcical as it is, I see many comments here that miss that point).
Post reply on HN