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

51–60 of 113 posts

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

#51

Post by jpalomaki »

slooonz wrote: 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…

”You aren’t gonna need it” (YAGNI)[1] is good to keep in mind.

When you are building the abstractions too early you are guessing the future needs. If you never need to change X then the code to make that change possible is just extra weight.

[1] https://en.m.wikipedia.org/wiki/You_aren%27t_gonna_need_it

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

#52

Post by smileypete »

ajuc wrote: post #41
BurningFrog wrote: post #27

Earlier quoted context omitted.

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…

Maybe

    drawColouredRectangle("red", x0, y0, x1, y1)

    decideHighlightColour(someDecidingFactor1, someDecidingFactor2)
then call separately? Depends on the number of calls to drawHighlightingRectangle I guess.

Something I've learned recently is to try to think in terms of behaviours, then compose them instead of mixing them together. Also it's easier to juggle the pieces by erring on the side of decomposition initially, then recompose a bit once they're organised, but only if it makes more sense.

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

#53

Post by gregkerzhner »

slooonz wrote: 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…

Just as a counterexample to this, my last gig (I got out after 4 months thankfully) was written with some of these "do copy and paste" and "write a big lump of code" principle and it was an absolute nightmare to work with. Most functions were hundreds of lines long and files were huge. The code had no architecture and was very hard to reason with or modify. Most of the work was to fix a steady inflow of bugs which had no concrete repro steps and happened sporadicly.

People rag on premature optimization but I will take it over no optimization at all. Someone who prematurely optimizes at least has good intentions in their heart and is trying to do better.

At the end of the day, every day, even every hour as a developer you constantly have a choice - be lazy or be good. If you are lazy you will add one more if then statement to the already huge function. If you are good, you will refactor it. Its OK to be lazy every once in a while, but thats a very slippery slope and years of laziness will crush a codebase in its own eight.

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

#54

Post by motakraxxer »

nxpnsv wrote: post #15
flohofwoe wrote: post #11

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).

It is like the Murphy's law of deletable code "Anything that can be made hard to delete will be made hard to delete".

"Anything that can be made hard to delete, will be made harder to delete, even when we try to make that specific part of code easier to delete."

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

#55

Post by mro_name »

flohofwoe wrote: post #11

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).

uh, indeed, sounds like thermodynamics.

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

#56

Post by mumblemumble »

tobr wrote: post #28
nxpnsv wrote: post #15

Earlier quoted context omitted.

It is like the Murphy's law of deletable code "Anything that can be made hard to delete will be made hard to delete".

More like a variant of the Peter principle: all code tends to be refactored to its level of unrefactorability.

Having just completed a change that should have been small, but ended up spanning ~75 files, I can attest to this. It would have been small, up until the point where one of the excitable members of the team discovered Uncle Bob and got excited.

Which, disclaimer, I generally like what Uncle Bob has to say. But there's this thing, and I don't quite understand how it happens, where it seems to be really easy to implement the cosmetic parts of the programming style he advocates while simultaneously achieving the diametric opposite of the fundamental goals that these techniques are supposed to achieve.

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

#57

Post by mumblemumble »

kqr wrote: post #39
agumonkey wrote: post #38

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.

They grow. They change. But they can't be killed or conquered.

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

#58

Post by yetanta »

flohofwoe wrote: post #11

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).

I have had pretty good luck with just dropping a comment where something would be expanded. I find for myself sometimes it is easy to add bunches of code for cases that never happen. Mostly because you are in the moment thinking about all the different cases and have in a crazy way missed the specific case you are working on. Sometimes (not always) it is better just to ack that you are being an over-engineer.

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

#59

Post by Uberphallus »

smileypete wrote: post #33

I think that one possible problem with the 'O' in SOLID (open closed principle) is spending excess time second guessing future modifications to the code. The examples are always clear cut, but in the real world it sometimes doesn't work out that way. OTOH I'd say that the 'L' is worthwhile (Liskov substitution principle) as inheritance can be abused as a kind of 'version control' for functionality, and LSP helps guar…

Some time ago I worked exposing an API that, given that it was constantly evolving and different partners adapted to it at different paces, we had to support a wide range of versions of it, which was basically what you say as version control.

I'm not gonna say it was pretty, actually from a design perspective it was disgusting, but from the perspective of handling a dozen versions of the same code in the same application, it was certainly very sane.

For example, at some point we supported versions 2.0, 3.0, 4.0, 4.1, 4.2, 4.3 and the freshly new 5.0. They inherited this way: 2.0 -> 3.0 -> 4.0 -> 4.1 -> 4.2 -> 4.3 -> 5.0, easy enough.

One day decide to deprecate version 2.0.

What happens is we consolidate 2.0 code in 3.0:

1. If a method calls super, copy + paste from 2.0 its place. 2. If it's overridden, there's nothing to do. 3. Run unit, regression tests, on the remainder of the versions and fix anything that might have been missed. 4. Delete 2.0 code.

The end.

If we need to fix a bug introduced in 4.1, you fix it there and it gets fixed automatically for the rest of the higher versions.

Post reply on HN