By Marcin Dubel, Appsilon

Clean R Code Is Critical

Over many years of experience delivering successful projects, I’ve found one common element in each implementation. A clean, readable, and concise codebase is the key to effective collaboration and provides the highest quality value to the client.

Code review is a crucial part of maintaining a high-quality code process. It is also a great way to share best practices and distribute knowledge among team members. At Appsilon, we treat code review as a must for every project. Read more about how we organize our work in Olga’s blog post on best practices recommended for all data science teams.

Having a well-established code review process does not change the fact that the developer is responsible for writing good, clean code! Pointing out all of the code’s basic mistakes is painful, time-consuming, and distracts reviewers from going deep into code logic or improving the code’s effectiveness.

Poorly written code can also harm team morale – code reviewers are frustrated while code creators might feel offended by a huge number of comments. That is why before sending the code to review, developers need to make sure that the code is as clean as possible. Also, note that there is not always a code reviewer that can come to the rescue. Sometimes you are on your own in a project. Even though you think the code is ok for you now, consider rereading it in a few months – you want it to be clear to avoid wasting your own time later on.

In this article, I summarize the most common mistakes to avoid and outline best practices to follow in programming in general. Follow these tips to speed up the code review iteration process and be a rockstar developer in your reviewer’s eyes!

Avoid Comments with Comments

Adding comments to the code is a crucial developer skill. However, a more critical and harder to master skill is knowing when not to add comments. Writing good comments is more of an art than a science. It requires a lot of experience, and you can write entire book chapters about it (e.g., here).

There are few simple rules that you should follow, to, well, avoid comments about your comments:

  • The comments should add external knowledge to the reader: if they’re explaining what is happening in the code itself, it is a red flag that the code is not clean and needs to be refactored. If some hack was used, then comments might be used to explain what is going on. Comment…

Continue reading: