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

31–40 of 120 posts

Re: Never edit a method, always rewrite it?

#31

Post by MattHeard »

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.

    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

Re: Never edit a method, always rewrite it?

#32

Post by oneeyedpigeon »

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.

You definitely could enforce it: isolate the developer from the codebase, give them a function contract to implement. It doesn't sound like a good idea, and I wouldn't want to work that way, but it could be done.

Re: Never edit a method, always rewrite it?

#34

Post by oneeyedpigeon »

MattHeard wrote: post #31
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.

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

I don't think the parent was supposed to be production-ready code, it was more illustrative of a different (more interesting, IMO) point.

Re: Never edit a method, always rewrite it?

#35

Post by skrebbel »

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.

But this is different, because you already have:

- the method's signature and spec

- the changes in behavior you want

Re: Never edit a method, always rewrite it?

#36

Post by Retric »

oneeyedpigeon wrote: post #32
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.

You definitely could enforce it: isolate the developer from the codebase, give them a function contract to implement. It doesn't sound like a good idea, and I wouldn't want to work that way, but it could be done.

Writing detailed method contacts is very much programming and has just as many risks for bug creation.

Re: Never edit a method, always rewrite it?

#37

Post by thejosh »

MattHeard wrote: post #31
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.

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.

Re: Never edit a method, always rewrite it?

#38

Post by cillian64 »

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…

This is basically the same as how many Python functions often have a long list of arguments with defaults. When calling you can ignore them or set them as you like using keyword arguments. I'm a big fan.

Re: Never edit a method, always rewrite it?

#39

Post by mhomde »

seizethecheese wrote: post #16
mhomde wrote: post #11

Earlier quoted context omitted.

That's actually a good idea, thanks! I'm not sure it would be feasible but it would be neat if methods was automatically versioned (in all but syntaxtic changes) and you could automagically compare results of the different versions. It kinda falls apart with refactoring but still :) I'm finding it more and more evident that file's as the default unit of storage and viewing of code is an obsolete concept

> I'm finding it more and more evident that file's as the default unit of storage and viewing of code is an obsolete concept Fascinating. Could you expand on this or link somewhere?

It's just a general thought I've been having. We're using text and files because it's the way things always have been. But it seems there should be benefits to perhaps move beyond that.

Things like with more canonical representations of code, rather than arguing over coding standards (although it can still text-based rather than completely graphical). Ability to more easily see related code and flows. Manage the meaning of code rather than its text (not changing text but changing symbols when you refactor).

There's been attempts to move in that this direction with things like code bubbles (https://www.youtube.com/watch?v=PsPX0nElJ0k) but yet there hasn't been an approach that's both visually attractive and offers enough benefits, but it's probably coming somewhere down the line

Post reply on HN