Tips to write a better code

Coding is part of my life. That’s what I do the most, for living. While I was reading something on Hacker News, I came across that someone had mentioned somewhere in the comments about something to consider on writing a better code. I don’t really remember which post, to be exact. But I did some quick notes on those. Since then, I have been practicing the following mental model in my coding, and it helped a lot in improving my code. I think this is something good to share here.

Working, simple, correct, optimized


The first thing you want to ask yourself whenever you are writing your code, is it working? It doesn’t matter how you do it, the code just needs to work the way it is expected to be. The code represents a proof of concept. It does at least 90% of the things, some part may look ugly and messy but it validates a hypothesis. This is maybe your Alpha version!


A good code should be read like a story, not like a puzzle. The best documentation is self-explainable code. You have to review, simplify and refactor your code so it’s readable and embracing DRY principle. If reviewers don’t understand the “why” of some code, a comment is left. Learn about KISS principle may help you to understand better on the code simplicity.


Edge cases are covered, tests are written, internal users have validated that the feature is working as expected. Correctness is the destination of any piece of software (ultimately the goal of any piece of software is to work). There are some hot debates going on over which comes first between simplicity and correctness, and it has no winner, so I may want to leave this one for you to discover.


This is where mostly you polish your code. To avoid premature optimization, you should be measuring/benchmarking your code performance as earlier as possible. Your algorithm may need to be changed/updated if it’s slow. If something doesn’t look right on the design, you may want to optimize your design earlier before the lines of code starts to increase.