Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Write code that is easy to delete, not easy to extend (2016)

programmingisterrible.com

Post reply on HN
Print view View original

61–70 of 102 posts

Re: Write code that is easy to delete, not easy to extend (2016)

#61

Post by pjturpeau »

ainiriand wrote: post #58
chikere232 wrote: post #55

Earlier quoted context omitted.

Because building for extensibility adds real complexity for a hypotetical need If you want the code to do something different later, change, replace or extend it then... when you actually know what it needs to do

I am not sure that is something that applies 100%, but I understand the concern. It is my understanding that we should try to build solutions to current problems, and be open to future use cases that could involve small additions in functionality. It would be stupid to design an unmodifiable system just because some parts can be deleted and we are not sure what future needs are. Code should always be easy to extend,…

If it is easy to understand, then it is easy to extend.

Re: Write code that is easy to delete, not easy to extend (2016)

#62

Post by bunderbunder »

zokier wrote: post #18
jumploops wrote: post #12

My favorite saying: “simple is robust” Similar in spirit to Lehman’s Law of Continuing Change[0], the idea is that the less complexity a system has, the easier it is to change. Rather than plan for the future with extensible code, plan for the future with straightforward code. E.g. only abstract when the situation requires it, encourage simple duplication, use monoliths up front, scale vertically before horizontally,…

Sure, but when applying "simple is robust" principle it is extremely important to understand also intrinsic complexity. Not handling edge-cases etc does not make for robust code, no matter how much simpler it is.

This is where the advice in the article is excellent.

If you start with code that's easy to delete, it's often possible to alter your data representation or otherwise transform the problem in a way that simply eliminates the edge cases. With the result being a design that is simpler by virtue of being more robust.

If you start with code that's hard to delete, usually by the time you discover your edge and corner cases it's already too late and you're stuck solving the problem by adding epicycles.

Re: Write code that is easy to delete, not easy to extend (2016)

#63

Post by lttlrck »

Hasu wrote: post #56
mherrmann wrote: post #48

Glaring mistake in the first paragraph: > The problem with code re-use is that it gets in the way of changing your mind later on. This is simply incorrect, especially in the generality in which it is stated. If you change your mind and the code was copy-pasted to ten places, then you have to change ten places. On the other hand, if the code is in a function, then you only need to change it once. And if you do find th…

> On the other hand, if the code is in a function, then you only need to change it once. And if you do find that one of the ten invocations should not be changed, then you can still copy-paste - or make the function more general. Ah yes, but what happens if you have to change 3 of the function invocations in one way, 5 in another, and the other two need to be completely rewritten because those aren't even using the s…

There is no one size fits all.

In a many cases I'd still rather have three or more versions of a function, many which may just be very thin shims to accommodate that scenario than 10 copy/pastes of variations. Or shim at the call site and keep one function if that suits.

Re: Write code that is easy to delete, not easy to extend (2016)

#65

Post by nightowl_games »

mherrmann wrote: post #48

Glaring mistake in the first paragraph: > The problem with code re-use is that it gets in the way of changing your mind later on. This is simply incorrect, especially in the generality in which it is stated. If you change your mind and the code was copy-pasted to ten places, then you have to change ten places. On the other hand, if the code is in a function, then you only need to change it once. And if you do find th…

Many times the code is reused in places where it is the correct code, so then you when you change it you have to slow down and split those places up. We have a git submodule of common UI widgets, changing one of those is impossible now, easier to copy the component into the project and change it locally. It's a problem! The "shared code" needs to be as minimal as possible because the sharing makes it harder to change.

Re: Write code that is easy to delete, not easy to extend (2016)

#66

Post by treflop »

braden-lk wrote: post #49
mherrmann wrote: post #48

Glaring mistake in the first paragraph: > The problem with code re-use is that it gets in the way of changing your mind later on. This is simply incorrect, especially in the generality in which it is stated. If you change your mind and the code was copy-pasted to ten places, then you have to change ten places. On the other hand, if the code is in a function, then you only need to change it once. And if you do find th…

In my experience, bad copy pasted code results in an annoying afternoon of tech debt repayment and fixes. Badly abstracted code results in months of tech debt repayment. Of course, the answer is “don’t make bad abstractions”, but we all know how that one goes with a team and changing product reqs.

If only that were the case on a project at work. The badly copy pasted code has diverged over the years so you have 10 different versions of the same looking code that individually have differing edge cases, half of them by mistake because they forgot about the other 9.

I would trade that for one piece of mediocre abstracted code any day.

Oh yeah and everything in the codebase is copy and pasted.

Re: Write code that is easy to delete, not easy to extend (2016)

#67

Post by Skeime »

zokier wrote: post #18
jumploops wrote: post #12

My favorite saying: “simple is robust” Similar in spirit to Lehman’s Law of Continuing Change[0], the idea is that the less complexity a system has, the easier it is to change. Rather than plan for the future with extensible code, plan for the future with straightforward code. E.g. only abstract when the situation requires it, encourage simple duplication, use monoliths up front, scale vertically before horizontally,…

Sure, but when applying "simple is robust" principle it is extremely important to understand also intrinsic complexity. Not handling edge-cases etc does not make for robust code, no matter how much simpler it is.

Yes, but I definitely also see the opposite quite a bit: Somebody several layers down thought that something was an edge case, resolved it in a strange way, and now you have a chain of stuff above it dealing with the edge case because the bottom layer took a wrong turn.

The most common examples are empty collections: either disallowing them even though it would be possible to handle them, or making a strange choice like using vacuous falsity, i.e.

  all [] == False
(Just for illustration what I mean by "vacuous falsity", Python's all correctly returns True).

Now, every layer above has to special-case these as well, even if they would be a completely normal case otherwise.

Re: Write code that is easy to delete, not easy to extend (2016)

#68

Post by sfn42 »

Hasu wrote: post #56
mherrmann wrote: post #48

Glaring mistake in the first paragraph: > The problem with code re-use is that it gets in the way of changing your mind later on. This is simply incorrect, especially in the generality in which it is stated. If you change your mind and the code was copy-pasted to ten places, then you have to change ten places. On the other hand, if the code is in a function, then you only need to change it once. And if you do find th…

> On the other hand, if the code is in a function, then you only need to change it once. And if you do find that one of the ten invocations should not be changed, then you can still copy-paste - or make the function more general. Ah yes, but what happens if you have to change 3 of the function invocations in one way, 5 in another, and the other two need to be completely rewritten because those aren't even using the s…

This is such a strange argument. You want to copy and paste code 10 times rather than making a function, because if the requirements change and if the person assigned to fix it is a moron, then it might prevent the moron from choosing one specific way of making a mess?

You can't prevent future morons from doing moronic stuff in the future. They'll just find another moronic thing to do.

Re: Write code that is easy to delete, not easy to extend (2016)

#69

Post by SoftTalker »

lttlrck wrote: post #63
Hasu wrote: post #56

Earlier quoted context omitted.

> On the other hand, if the code is in a function, then you only need to change it once. And if you do find that one of the ten invocations should not be changed, then you can still copy-paste - or make the function more general. Ah yes, but what happens if you have to change 3 of the function invocations in one way, 5 in another, and the other two need to be completely rewritten because those aren't even using the s…

There is no one size fits all. In a many cases I'd still rather have three or more versions of a function, many which may just be very thin shims to accommodate that scenario than 10 copy/pastes of variations. Or shim at the call site and keep one function if that suits.

If a function does different things in different circumstances it should usually be split into different functions.

Languages like Erlang which can have different versions of a function, selected by pattern matching (with optional guards) make this convenient:

    Name(Pattern11,...,Pattern1N) [when GuardSeq1] ->
        Body1;
    ...;
    Name(PatternK1,...,PatternKN) [when GuardSeqK] ->
        BodyK.
Post reply on HN