|
Getting your Trinity Audio player ready...
|
Recently, I have been stumbled upon a question by a Junior Developer on what coding best practices he must follow. I answered him the usual stuff like better readability of the method names (your code), proper documentation, etc., and then it made me conscious whether I have been following the norms or not. Human minds, you see. 🙄
Well, coding practices and standards differ from place to place. There have already been a plethora of articles covering this on the internet but unfortunately, there has been too much information, and sometimes it is damn overwhelming. At least, that’s what I felt when I was researching this. So it’s safe to say that whatever you read further are the best coding standards (or I would say, should be the best coding practices) every application developer must follow in my opinion.
Writing Readable-Documented Code
Of course, this would be my first point. What were you thinking? This is the foremost thing every developer must have on their mind. Why this is important? Well, when you start working for an organization, chances are that after working some years, you might move out to a different company and what you leave behind is your code. But if your code is not readable and you have not documented either, then it would become a real challenge for the new developer.
Moreover, the amount of time the new developer has to go through the clattered undocumented code is immense. When you write a method, just give them a meaningful name and it can be long enough to make you understand the method. Inline comments are equally important for describing the method, or controller, exception, etc. Hence, it should be mandated to write documented, readable code.
Writing Unit Test Cases For Code Coverage
Some programming enthusiasts argue that writing unit test cases is simply a waste of time. This is such a debated topic among some developers and project managers. But I can tell you that writing unit test cases can save you money and resources. End of discussion, ehh! 🤨
Unit tests are usually written in the form of functions and check the value and behaviour of these functions in various scenarios. It serves two purposes basically:
- The function will notify us that when you are doing something wrong in an invalid situation.
- The function will log the invalid situation.
For some developers, unit tests serve as documentation of the application. To learn what functionality is provided by one module or another, developers can refer to unit tests to get a basic picture of the logic of the module and the system as a whole.
But how does it save money, you may ask? Steve McConnell, in his book, ‘Code Complete’ shares a table with bugs and the cost of fixing them at different stages of the product lifecycle. When unit tests are written, many bugs are found at the application development stage, which prevents the transition of these bugs to the following stages, including after the release of the product. This saves the costs of fixing the bugs later in the development lifecycle and also brings benefits to end-users, who don’t have to deal with a buggy application.
Writing A Simple Code Is Always Better
No matter how much experienced you are, if you want to show your coding prowess, just learn to write simple code. Whether you are coding in Java, C++, or Python, the object-oriented programming concepts should always be used when needed and not unnecessarily, else it becomes challenging to debug an errored code.
This also applies to have proper naming conventions of variables, classes, functions (or methods), etc. for better readability.
Refactoring Is A Necessary Evil
Refactoring can be defined as a systematic process of improving existing code, without adding new functionality or changing the external behaviour of the code. The sole intention is to make the code more readable and maintainable without changing the functionality. Unfortunately, this doesn’t work well every time in your favour as it may lead to huge technical debt if done after a longer period of time and you may end up creating bugs in your code which might take up your time.
In my projects, I use SonarQube, a tool for detecting bugs, vulnerabilities, and code smells in the code. It also scans for the quality of the code also stating the technical debts to correct it. Hence, after every code change, the application can be scanned for issues and can be rectified then and there.
Read. Design. Code. Repeat.
When you get a task from the customer, you need to read the requirement properly, understand the acceptance criteria for the completion of the task. Then, you need to design (or architect) the application based on your requirements. Deciding on which design pattern to use, which database is required, which framework to use, everything depends on your design phase. Then comes the coding part.
Well, reading the official documentation of any new technology and learning the design patterns should be every developer’s practice.
It was indeed fun to write about this. These might not be all the best practices that developers follow, but I have mentioned some important ones (hopefully). I enjoyed going through CommitStrip’s Web Comics, you all must check out, it is so relatable and you will thoroughly enjoy it.
Disclosure: Bear in mind that some of the links in this post are affiliate links and if you go through them to make a purchase I will earn a commission. Keep in mind that I link these companies and their products because of their quality and not because of the commission I receive from your purchases. The decision is yours, and whether or not you decide to buy something is completely up to you.
You might also find the below articles worth your time.
Everything A Developer Must Know About Microservices
Comments are closed.