In this article, I have listed the 5 golden rules for a developer, which can be practiced by any platform programmer at any experience level so as to improve their coding.
Test first programming
Write unit test first, then write your actual code. It may sound somewhat awkward, but it will help a lot.
When you write your code first, and then write your unit tests (this is what most of us do; accept it frankly!), you are writing your unit tests to justify the code you have written. In most cases, your unit tests will always pass and you won’t be able to derive a failure scenario, and thus, there is no chance for any refactoring.
Write self-explanatory code
Code comments are fine but they need to be maintained as and when we refactor the code. As the time goes by, it becomes difficult to maintain comments per code and then comments lose their meaning.
You should have a habit of writing the code which is self-explanatory, thus requiring minimum efforts in understanding it and thus resulting in minimum comments.
Don’t ignore/suppress code analysis warnings
Most modern day IDEs now point to any non-conformance in your code as and when you build it. But as most of us do, you will ignore it or suppress it.
Take care of the warnings pointed out by these tools and fix them as and when you commit the code. Consider your coding is complete only when it has zero code analysis warning.
Don’t eat up exceptions
Write code which handles every possible error suiting the business scenario, and if any unexpected exception arises, don’t eat it up in my code, but better throw it, so that it is logged/reported somewhere in the Application and someone can take care of it later.
It is always better to gracefully handle the exception and tell the user that something bad has happened, rather than hide it behind the curtain.
Get your code reviewed by a peer
No matter how experienced a developer you may be, a second look by someone else always helps. You cannot always see your obvious/silly mistakes while someone else quickly can. It has nothing to do with the other person’s expertise or experience, it’s just human nature.
Not only this, you can also review code written by others, and you don’t have to be an expert for this. You can always learn something new reviewing others’ code, maybe a better use of some design pattern, better performing code, a new OO principle usage, etc.
Note: This article was published on my LinkedIn page here.