Code review etiquette

Greetings! In this article, I will provide a concise overview of code review etiquette, based on personal experiences and relevant articles.

Reviewer Guidelines:

1. Clearly express your comments:
   When requesting modifications, provide specific details about the necessary changes for approval, such as highlighting a particular code snippet.
   
2. Use references in code reviews, if needed:
   Consider including links to articles or Stack Overflow threads for clarity.
   
3. Be suggestive, not decisive:
   Frame your comments as questions, for example: "What do you think about naming this user_id?” is nicer than "You should rename this variable to user_id", or use phrases like "Please consider..." instead of imposing directives. This approach encourages inquiry over criticism, fostering a friendlier atmosphere.
   
4. Positive feedback in code reviews:
   Recognize impactful modifications, like refactoring, code improvements and clean code, to cultivate a culture of appreciation. For example, "Wow! That's an amazing change!"
   
5. Code reviews for continuous improvement:
   Embrace code reviews for collaborative learning and knowledge exchange. Cultivate a culture where constructive feedback is shared to help colleagues enhance their skills.
   
6. Silent approval in code reviews:
   When genuinely impressed by code modifications, express succinct approval with a comment like "Looks good to me; I have nothing to comment on."
   
7. Maintaining scope in code reviews:
   Please comment on new code changes. Avoid involving authors in already-bad code unless directly related to the feature at hand.
   
8. Phrasing of your code review comments:
   Online communication can create misunderstandings, leading to hurt feelings during code reviews, provide actionable feedback by avoiding subjective statements like "I don't like it" or "This is bad.", and focus on specific, constructive suggestions.
   
9. Comment prefixes:
   Utilizing these prefixes can help streamline the code review process and foster constructive feedback exchange among team members.
   FYI: FYI is the abbreviation for "for your information.", A suggestion or informational note intended to enhance code quality or understanding without imposing a strict requirement. It offers an alternative solution.
   Convention: Identifying code that deviates from established organizational standards. Ideally this would be enforced automatically with a linter or some other tool.
   Nit: A nit is a small, insignificant issue spotted during a code review process that doesn't have a major impact on the overall quality of the code.
   Optional: Suggesting an idea that may enhance the code but is not obligatory to implement.

Author Guidelines:

1. Break down your changes to the smallest functional units:
   Optimize efficiency by breaking down PRs into manageable units, making the review more straightforward and enhancing the accuracy of the evaluation.
   
2. Fixing code comments with flexibility:
   Embrace a positive mindset during code review process by understanding that comments are directed at the code, not personal critique.
   
3. Respond to every comment for comprehensive improvement:
   Promote active engagement in the code review process by responding to each comment, including those that may not align with your initial preferences.
   
4. Acknowledging and implementing reviewer suggestions:
   Foster a positive code review culture by expressing gratitude for reviewer suggestions. For example If you agree with the comment, you can say: "Great decision. I'll implement that change."
   
5. Share the design doc ahead of review for large features:
   This method enhances code comprehension for the reviewer.
   
6. Avoid adding unnecessarily large number of reviewers:
   Selecting a focused and relevant group of reviewers, ensures concise and effective feedback.
   

I hope this article proves to be valuable for you and I welcome your feedback.