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…
Never edit a method, always rewrite it?
21–30 of 120 posts
Re: Never edit a method, always rewrite it?
#22I 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 strongly disagree with this. I've been deleting thousands of lines of this sort of code recently.
It creates technical debt and someone else will have to clean it up
Re: Never edit a method, always rewrite it?
#23Devils 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 just cannot push this methodology unto developers.
Re: Never edit a method, always rewrite it?
#24I've been doing something similar. I name the new method Method, rename the old one as MethodOld and in Method, before the return value, I put an assert(MethodOld(args) == return value). It's one of the things that when I do, I appreciate the value of, but I'm not disciplined enough to do as much as I would like to lol.
There's a better way to do this. Write a unit test for Method and just edit Method as needed. Run your test to verify that the output is consistent.
This prevents cluttering your code with old methods and also allows you to figure out if a new environment breaks your code.
Re: Never edit a method, always rewrite it?
#25This is similar to what's happening to the functions in Ethereum contracts where there is an actual cost of updating code.
Re: Never edit a method, always rewrite it?
#26If only business requirements, specs and use cases didn't evolve.
For our Christmas campaign, calculateCostOfGadget() needs to account for the compounding discount. Preferably yesterday, as we need to complete this month's billing to make payroll.
Re: Never edit a method, always rewrite it?
#27I 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…
Why? Your revision history is already in version control.
You could see this proposal as tighter integration between version control and the language proper, which has the potential to solve a lot of problems. E.g. there's a common problem with diamond dependencies: if A depends on B and C, and B depends on D, and C depends on D, what do you do if the versions of D they depend on don't match?
Re: Never edit a method, always rewrite it?
#28A 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.
Re: Never edit a method, always rewrite it?
#29Devils 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.
So the point of a methodology like this is that it guides you into hopefully making better code by driving you away from certain decisions. Yes you can certainly sabotage attempts at doing so with patch methods and copy-paste, but the point is that if followed it'd set up an environment which discourages spaghetti.
Re: Never edit a method, always rewrite it?
#30When 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 think the point of this is to try and move towards a place where your "functions that get real work down" are composed from your reusable functions.
It's debatable if it actually helps with that intention.