Code Review best practices

Everyone has there own set of best practices. Here are the few points which I would like to share with you regarding the code review.

The aim of the code review is to build the team spirit, improve the code quality and collaborative learn the best practices.

One feature at a time

Make sure your CRR or commits are based on single feature or story or bug fix. Keeping multiple feature or bug fixes in a single code review request will create more confusion. So keep it simple.

Add members to review

Add everyone from team into in your code review request. At least 2 reviewers should review your code before it has been merged to the remote repository.

Information about what has been changed

Add information about what has been changed in the CRR. Add the related tickets/story/bug link in the CRR (in most of the cases). This will help the peer reviewers to get an insight or information about the task.

Notify the team

Send an Instant message to your team when the CRR request is sent or when the individual completes reviewing a particular request.

If you have any automated system like web hook or slack notification, thats fine. Otherwise, it’s OK to maintain a seperate channel or group to discuss about CRR.

Write it simple and clean

Keep the commit message concise & clear (if it is a bug fix mention it clearly).

When you are reviewing, look into the code and make sure you understand what code does actually; if there is any doubts/clarification needed highlight the code and add comments for clarification.

The aim is to have a readable code, so that remaining team members can also understand.

Be a advisor

If you find the code is difficult to understand or it could be even simpler feel free to suggest the better way to do that.

It’s a good habit to suggest something good instead of just mentioning that particular piece of code can be improved.

Maintain patience

Don’t urge to get your code get reviewed; Give some time to the reviewer and add a gentle reminder if it takes too long.

Be gentle

Stay humble, all these processes are to improve ourselves in a better way.

Code review process is to improve the code quality and build the team spirit in a better way. Collaboratively we can learn more from Code Reviews.

Happy Coding!

Advertisements

The art of readable code – review

I’m not sure whether we can call this blog post as review or summary of a book. After reading please decide yourself which name suits very well.

Book Name : The Art of Readable Code
Authors : Dustin Boswell and Trevor Foucher

cat

 

The book has been divided into 4 parts

  • Surface-level improvements
  • Simplifying loops and logic
  • Reorganizing your code
  • Selected topics

And then each parts discussing various important topics in details in the entire book.

Every chapter starts with a cartoon image which is fun and loads with deep meaning related to the topic. The cartoon image gives a quick view on what information the entire chapter had in it.

The author is discussing the topics with code examples which he himself and his team coded in the past. And also examples are very clear on how we can improve our coding standards and styles. The examples includes various programming languages like Java, JavaScript, Python, and C++.

The ultimate aim of this book is to discuss about “how we can make code more readable”. So that whenever we revisit our own code, we don’t have give a alien look to our code editor.

The author mentioned in the book as the goal is “to minimize the time
it takes someone else to understand your code.”

Part – I: Surface Level improvements

The topics under this part will help us make a small level changes in the code line by line which will results in a big form. The topics like choosing better name for variable & function names, writing more understandable comments, using common formatting for code across team are covered under this section.

My favorite topic under this part is loading information with names – like adding units in the arguments of a function, using concrete names.

Adding proper comment to the proper place in a proper way is a winning policy for every successful coder. (+ commit logs :)) There is no specific length for a good comment or log message, the message should precise and compact.

Part – II: Simplifying loops and logic

I have started my coding career by learning basic loops and logic. The various topic under this part is like revisiting our own memory and brush up some basic understanding of loops & logic.

The large number of variables, complicated loops, and giant expression in our code will create great confuse in our mind while going through the code for understanding. This part discuss various topics on how we can make our loops more readable. If loops looks so complicated, the bugs may likely go unnoticed. Sometimes our complicated loops will play Three-card monte trick with us.

My favorite topic under this part is shrink the scope of the variables. Too much global variables will create pretty good confusion at its best.

Part – III: Reorganizing your code

Topics under this part discuss about the functional level changes in our code – Extracting “unrelated sub problems”, Rearranging the code so that one task happening at a time, turning thoughts into code.

The ultimate aim of this part of code is to separate the generic code from the project specific code, and also to improve reusable of the code.

“Each new line of code needs to be tested, documented, and maintained. Further, the more code in your codebase, the “heavier” it gets and the harder it is to develop in.”

Part IV: Selected topics

In this part, author discussed about testing – how to write tests that are effective and readable at the same time.

Too long to read

Its really a nice book, I would like to recommend to all the people in Software field (especially young developers). Some of the Experienced people may already have more insight on above topics by gathering knowledge from their years of experience. We won’t accept some of the suggestions in the book, if we discuss these topics with our team we can get into more interesting discussions.

Happy reading 🙂