Hacker News Reader

Comment by UglyToad | Hacker News Reader

I think this ties in to something I've been thinking, though it might be project specific.

Good code should be written to be easy to delete.

'Clever' abstractions work against this. We should be less precious about our code and realise it will probably need to change beyond all recognition multiple times. Code should do things simply so the consequences of deleting it are immediately obvious. I think your recommendations fit with this.

View on HN

>code should be written to be easy to delete

This article tends to make the rounds on here every once in a while: https://programmingisterrible.com/post/139222674273/how-to-w...

Aligns with my current meta-principle, which is that good code is malleable (easily modified, which includes deletion). A lot of design principles simply describe this principle from different angles. Readable code is easy to modify because you can understand it. Terse code is more easily modified because there’s less of it (unless you’ve sacrificed readability for terseness). SRP limits the scope of changes and thus enhances modifiability. Code with tests is easier to modify because you can refactor with less fear. Immutability makes code easier to modify because you don’t have to worry about state changes affecting disparate parts of the program.

Etc... etc...

(Not saying that this is the only quality of good code or that you won’t have to trade some of the above for performance or whatnot at times).

The unpleasant implication of this is that code has a tendency towards becoming worse over time. Because the code that is good enough to be easy to delete or change is, and the code that is too bad to be touched remains.

One of John Carmack's maxims is "Fight code entropy." As simple as that is it carries a lot of meaning imo.

Reply on news.ycombinator.com