Code Review Tips For Any Language And Every Developer
Code review is not an easy task: it requires experience and, by experience, we don’t mean you have to be an experienced developer, but that you have to also be comfortable with code reviewing.
Code reviews go beyond pointing out the ‘bad’ and the ‘ugly’: good practices must be highlighted to avoid frustration. Someone who has their code reviewed on a daily basis doesn’t want to hear their job being criticised every time a mistake is found.
But how can you evaluate your own code if you already wrote it up to the top of your abilities?
The answer is simple: you follow these tips that work transversely across different programming languages.
The warnings your IDE gives you aren’t just for show. Your IDE might be detecting bad practices, outdated tech stack and possible security risks. Do not ignore them! Instead, focus on trying to have builds error free and with the least amount of warnings possible.
Follow the standards. Getting the naming conventions for your variables, classes and packages right helps you create easily red code which will also be easier to maintain. If everyone in a team follows the same rules, their outputs will be more consistent and reliable.
As for the conventions, if every team member is used to developing in a certain style, it will help when it’s time to clean mess ups.
Format your code – it makes your work look cleaner, easier to read and less messy.
Personally, I’ve seen code that didn’t follow the team’s style being modified and ending up introducing bugs. Keep in mind that software development is usually made in a hurry which results in bugs tainting your code and at a fast pace. As software engineers we must find strategies to minimize risks and complying with a code style is a practical solution and easy to apply.
Comments and Documentation
All public methods should be documented: include description of what they as well as their arguments and of what they return if applicable. Documentation is very important for maintainability. You may know what the method does and how it works, but if someone else needs to edit your method and it doesn’t have documentation, they’ll have to read its full implementation to fully understand it. That is just a waste of development time.
If you are developing an SDK that will be handed out to a client you can’t skip this step.
It’s also very useful to leave comments here and there with very brief summaries of what the code is doing for other team members to read. However, you shouldn’t overuse comments, only relevant ones should make the cut to keep files concise.
Arguments’ validation is a way to declare specific restrictions on function input arguments. Using arguments’ validation you can constrain the class, size, and other aspects of method input values without writing code in the body of the function to perform these tests and guarantee the methods are only used as they are meant to be. In some languages, such as Java, it’s common to throw IllegalArgumentExceptions (a type of RunTimeExceptions), when the argument contract is violated. The idea is to detect a few crashes in the development process and not later on, when the application was already delivered to a client or published to an app store.
Any kind of a goodly written test is better than no tests at all. There are several types of tests, each one with a different responsibility. You can check out one of my previous posts with everything you need to know about unit tests.
All of the tips above help in the maintenance of an application. Best practicing docs for your programming language are always a good source to be bookmarked. If you don’t know the best practices just check the docs. The goal is to minimize risks the best we can by following certain rules. Keep the code clean and care for what you write and its presentation. Have your critical thinking on whenever you check a stackoverflow link and don’t forget, defensive programming is key.
Comments are closed