Live data from Hacker News

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

programmingisterrible.com

1–10 of 32 posts

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

#2
How to write good code:

1. Comment as much as possible, stating intention.

2. Don't duplicate code. You need a function that does something similar to another one, but slightly differs? Do not duplicate it. Less code is less maintenance.

3. Don't circlejerk over code quality, your goal as a programmer should be to write the best software you can. The end goal is the software, not the code. Stop circlejerking in pull requests, issue threads, wherever. Make the best software you can and move on to the next problem.

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

#7
The best code is the code you don't write.

I'll sometimes spend a couple of hours on a method, removing unnecessary code.

It does NOT always end up with more performant code (sometimes, the opposite), but it does reduce the "I don't wanna remove all that code" surface, and it usually* makes the code easier to understand.

* I write Swift. Sometimes, less code is more obscure code, and I often have to go back and put code I removed back in, to make it more understandable.

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

#9

The best code is the code you don't write. I'll sometimes spend a couple of hours on a method, removing unnecessary code. It does NOT always end up with more performant code (sometimes, the opposite), but it does reduce the "I don't wanna remove all that code " surface, and it usually* makes the code easier to understand. * I write Swift. Sometimes, less code is more obscure code, and I often have to go back and put…

> The best code is the code you don't write.

I envision your comment will be taken out of context to literally justify adding mountains of code written by other people. Invented Here Syndrome

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

#10
One of the hardest aspects about maintaining an in-house system at a small company can be refraining yourself from removing code that would decrease the company's tech debt. Most managers don't want to admit the smart code they wrote three years ago causes more problems than it solves, and it can get really awkward.
Post reply on HN