Code Review Best Practices

1. Expectation From Developer from code perspective:

1. Scope and size. Changes should have a narrow, well-defined, self-contained scope.
2. Only submit complete, self-reviewed (by diff), and self-tested PRs
3. Refactoring changes should not alter behavior; conversely, behavior-changing changes should avoid refactoring and code formatting changes.
4. Commit messages: Try to describe both what the commit changes and how it does

2. Expectation From code Reviewer: 

As a reviewer, it is your responsibility to enforce coding standards and keep the quality bar up. A review should be thorough enough that the reviewer could explain the change at a reasonable level of detail to another developer.

1. Purpose
   1. Does this code accomplish the author’s purpose? : Every change should have a specific reason (new feature, refactor, bugfix, etc). Does the submitted code actually accomplish this purpose?
   2. Ask questions. Functions and classes should exist for a reason. When the reason is not clear to the reviewer, this may be an indication that the code needs to be rewritten or supported with comments or tests.
   
2.  Implementation
   1. Think about how you would have solved the problem: If it’s different, why is that? Does your code handle more (edge) cases? Is it shorter/easier/cleaner/faster/safer yet functionally equivalent?
   2. Do you see the potential for useful abstractions?: Partially duplicated code often indicates that a more abstract or general piece of functionality can be extracted and then reused in different contexts.
   3. Think like an adversary but be nice about it
   4. Does the change follow standard patterns?
   
3. Legibility and style
   1.Think about your reading experience
   2. Does the code adhere to coding guidelines and code style?
   
4. Maintainability
   1. Does this change break backward compatibility?
   2. Leave feedback on code-level documentation, comments, and commit messages
   3. Was the external documentation updated? : SA, CHANGELOG
   
5. Rules
   1. Each PR review must have at least 2 same-team developer approvals. Manager approval does not count.
   2. Each PR must have a good description. From reading the description, the reviewer should be able to understand what the code is meant to do. This has to be true even if there is a Jira ticket or a requirements page.
   3.PR must have sufficient unit test and integration test coverage.
   4.If the PR is a bug fix, it must contain a test such that, should the bug fix be reverted, this test would fail.

Reference : Medium & Clean Code