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

41–50 of 120 posts

Re: Never edit a method, always rewrite it?

#41

Post by nitrogen »

smt88 wrote: post #24
adamnemecek wrote: post #8

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

Yes, please just do this. Maybe this thread is full of Poe's Law irony, but if not, I don't look forward to refusing to work on any code developed with the practice of strewing almost-the-same methods all over the place.

Simple code scales. Write simple code.

Re: Never edit a method, always rewrite it?

#42

Post by timthelion »

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?

Single-file coding is an entire subculture. See leo [1] and org-mode [2] programming.

[1] http://leoeditor.com/

[2] http://orgmode.org/worg/org-contrib/babel/intro.html#literat...

Re: Never edit a method, always rewrite it?

#43

Post by cdoxsey »

robbiep wrote: post #7

The metaphor that biological systems undergo continuous renewal and so therefore code should be rewritten not edited i think is actually off, code is the dna and thus undergoes evolution not replacement

This is spot on. We actually do have immutable binaries and rebuild and replace them when making changes. (Unless you're Microsoft apparently)

A more apt metaphor might be running multiple versions of the same binary which are similar enough to coexist.

Re: Never edit a method, always rewrite it?

#44

Post by GreaterFool »

Saw the headline, first though "I'll bet this is about dynamically typed languages", and lo and behold

> At a recent RubyConf...

EDIT: just wanted to add that when I code in dynamically typed languages I'm inclined to do the same thing. Without rigidity provided by a strong type system it's too easy to mess things up. That's why I prefer strongly typed languages so I can benefit from the structure they enforce.

Re: Never edit a method, always rewrite it?

#45

Post by lloeki »

adamnemecek wrote: post #8

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

For some hairy stuff that require live data you can also reverse the practice: call both yet return the old one, and gather data in production before switching.

Obviously this does not work for side-effectful methods (beware of caches!).

Re: Never edit a method, always rewrite it?

#46

Post by lloeki »

conradk wrote: post #18
adamnemecek wrote: post #8

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

That's interesting ! Will try that sometime. One question though: how do you deal with mutating methods? Like methods that would persist a value to storage and only should do so once?

In some cases you can mutate one of them to a noop (like /dev/null for a file, a stub class...).

Re: Never edit a method, always rewrite it?

#47

Post by timthelion »

mhomde wrote: post #39
seizethecheese wrote: post #16

Earlier quoted context omitted.

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

Code bubbles is hands down the most awsome thing I've seen in months! Where can I get it? I'll switch to JAVA for this? Thanks for sharing.

Edit: to answer my question, yes this really exists http://cs.brown.edu/~spr/codebubbles/

Re: Never edit a method, always rewrite it?

#49

Post by crb3 »

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.

Fill out the comment-header first, then; that's what I do. That informal-prose chatty summary of what the code does and why, what it takes in and what its output is, becomes in my mind the spec for the code while I'm writing it, even in casual one-shot Perl filters. It makes it easier for me to choose variable names which inform rather than mystify, because the master reference is staring me in the face as I write. It's also an attitude-anchor for specific tail-end comments to expand on the summary explanation by detailing why a line is as it is and does what it does. YMMV, but, for me, the payoff is an easier time of drawing thoughts together into code, plus, months down the road, an easier time of deciphering why I wrote the code that way.

Re: Never edit a method, always rewrite it?

#50

Post by adaml_623 »

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 totally understand that. Expanding and modifying an existing system is 1000 times easier than starting from scratch.
Post reply on HN