Live data from Hacker News

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

programmingisterrible.com

41–50 of 113 posts

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

#41
post #23

Earlier quoted context omitted.

That sounds like myriads of programmers have done it wrong for decades. Can you elaborate on this and maybe add a few sources?

If you have to change in 5 places to change one "thing", the code is probably not DRY.

You have 5 places in code where you draw a blue rectangle:

    drawRectangle("blue", x0, y0, x1, y1);
Do you refactor them into drawBlueRectangle(x0, y0, x1, y1)?

It seems you removed the duplication but you didn't. Because if you now have the requirement to draw red rectangles instead you surely won't leave it as

    def drawBlueRectangle(x0, y0, x1, y1):
        drawRectangle("red", x0, y0, x1, y1)
So instead of changing 5 places you now have to change the invocation in 5 places and implementation in 1 place.

You can argue it's because you named it wrongly, it should be "drawWhateverThingTheyHaveInCommonRectangle" instead, for example drawHighlightingRectangle. And you'll be right.

But you don't know if they will have that thing in common forever. And splitting the code is harder than refactoring it, so it often leads to code like this:

     def drawHighlightingRectangle(someDecidingFactor1, someDecidingFactor2, x0, y0, x1, y1):
         if someDecidingFactor == something && someDecidingFactor2 != somethingElse:
            drawRectangle("red", x0, y0, x1, y1)
         elif someDecidingFactor2 == somethingElse:
            drawRectangle("blue", x0, y0, x1, y1)
This code may seems ok, but it tends to grow business logic inside, and you don't immediately know what combinations of deciding factors are actually possible without looking at all the invocations. So either you look at all the invocations before implementing your change (and then the refactor didn't actually save you any work - what does it matter if you look at code and change it vs just look at code and change stuff elsewhere), or you ignore the invocations and add your change in isolation (probably writing code that is redundant and overcomplicated because you handle cases that cannot happen).

This is obviously oversimplified example, but I've done these exact mistakes several times :)

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

#42
post #39

Earlier quoted context omitted.

Actually, beside the facetious aspect of this, there is a subconscious value into having code-mass. Heavy means stable at times.

I'm not sure what you mean. Evidence indicates that code attracts more code, and big elements are frequently changed.

Not clear in my head either, but I just experienced the value of heavy structures at times.

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

#43
post #23

Earlier quoted context omitted.

That sounds like myriads of programmers have done it wrong for decades. Can you elaborate on this and maybe add a few sources?

If you have to change in 5 places to change one "thing", the code is probably not DRY.

In my last interdisciplinary role, I tried to simplify this as "you drew circles around the wrong parts". If many lines still cross the module boundary...

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

#44

The unfortunate side effect of this (very good) advice is that all code that's easy to delete will eventually be replaced with code that's hard to delete (and thus will eventually be impossible to delete in order to be replaced with something better).

Adverse selection at play

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

#45
post #39

Earlier quoted context omitted.

I'm not sure what you mean. Evidence indicates that code attracts more code, and big elements are frequently changed.

Not clear in my head either, but I just experienced the value of heavy structures at times.

I don't find the analogy working for software (a large structure is hard to change).

Software is always easy to alter, hack in some code here and there, move some functions around, add and rename files. The larger the software the more places to make changes.

It's unlike a physical structure where a 1000 tons wall really can't be moved.

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

#46

Earlier quoted context omitted.

Not clear in my head either, but I just experienced the value of heavy structures at times.

I don't find the analogy working for software (a large structure is hard to change). Software is always easy to alter, hack in some code here and there, move some functions around, add and rename files. The larger the software the more places to make changes. It's unlike a physical structure where a 1000 tons wall really can't be moved.

informational mass (complexity) is hard to change in a way

you can always delete for free but there's no system anymore, and if you change randomly the system might fail

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

#49
post #13
post #10

I wholeheartedly agree with "don't immediately jump on the modularize and abstract everything right away". I think that "modularization and abstraction is always and uniformly good" is one of the big lies of our profession. It’s easy to see how it’s attractive : programming is intellectual work, and displaying capacity of abstraction is rewarding. I was extremely enthusiastic about that stuff when I was young, too. T…

> Also, changing the slightest things required to go through 5-6 files. That is a sign it was incorrectly modularised. Good modularisation means high cohesion and low coupling. Having to make changes in multiple files means the opposite. Don't rack on modularisation (great concept!) when your only experiences are of bad implementations of it. (Which is not surprising, because most people do get it wrong.) Maybe the t…

[deleted]
Post reply on HN