Code review standards document

Photo by Farzad Nazifi on Unsplash

This is part three of the series on improving efficiency of code review process in my team. Earlier I wrote about a couple of free books on code review and a few articles where developers shared their experience in code reviews. I’m still exploring the practices of other teams and this time I want to post a few links to code review checklists that I found helpful.

• Stop More Bugs with…

The goal is not to define a formal definition of practices for code review but to give some checklist for reviewers.

Of course, it helps a developer to know how the reviewer does his code review. He can so focus on writing a better and simpler code.

Philosophy

Code Review is about the code not about the coder.

Basically, the code review focuses only on code written.

It's not the time to blame the author but to verify that the code meets the defined standards, best practices...

It means that no one escapes the code review: new hire, a senior, the lead developer or even CTO.

What must be understood is that there is no written well enough to not be seen code.

This is also the time to share development techniques, tips ... and why not initiate discussions or debate on a particular way of coding.

General

1. Does the code work?
2. Description of the project (status) is included in the docs.
3. Code is easily understand.
4. Code is written following the coding standarts/guidelines.
5. Code is in sync with existing code patterns/technologies.
6. DRY. Is the same code duplicated more than twice?
7. Can the code be easily tested?
8. Are functions/classes/components reasonably small?
9. Event listeners removed at teardown.
10. Naming conventions followed for variables, file names, translations.
11. Removed unused packages from NPM.
12. Separation of Concerns followed.
13. Avoid premature Optimization
14. Orthogonality
15. Single Responsibility Principle

Codestyle

1. No hardcoded values, use constants values.
2. Avoid multiple if/else blocks.
3. No commented out code.
4. No unnecessary comments: comments that describe the how.
5. Add necessary comments where needed. Necessary comments are comments that describe the why.

ECMAScript (ES6/ES7/ES8)

1. Use ES6/ES7/ES8 features.
2. Use fat arrow instead of var that = this. Be consistent in your usage of arrow function.
3. Use spread/rest operator.
4. Use default values.
5. Use const over let (avoid var).
6. Use import and export.
7. Use template literals.
8. Use destructuring assignment for arrays and objects.
9. Use Promises or Async/Await. Rejection is handled.

React code review

1. Are components have defined propTypes?
2. Keep components small.
3. Functional components for components that don't use state.
4. No api calls in containers, delegate to middleware
5. No state updates in loop.
6. No useless constructor.
7. Minimize logic in the render method.
8. Don’t use mixins, prefer HOC and composition or Hooks.

Third-Party Libraries

1. Use lodash/ramda functions instead of implementing itself.
2. Is YOUR_LIBRARY_NAME (e.g. Immutable.js) used correctly?
3. Why/Is any nice/useful library was used wich we didn't know before?
4. Use Rebase over merge.
5. Make sure no dist files, editor/IDE files, etc are checked in. There should be a .gitignore for that.

ESLint

1. Code has no any linter errors or warnings.
2. No console.logs.

CSS

1. Is any CSS preprocessor was used (SCSS, LESS, Stylus, PostCSS)?
2. Consistent naming conventions are used (BEM, OOCSS, SMACSS, e.t.c.).
3. Use mixin and css vars?
4. CSS selectors are only as specific as they need to be; grouped logically.
5. Use Hex color codes #000 unless using rgba().
6. Avoid absolute positioning.
7. Use flexbox/grid.
8. Avoid!important.
9. Do not animate width, height, top, left and others. Use transform instead.
10. Use same units for all project.
11. Avoid inline styles.

Testing

1. Tests are readable, maintainable, trustworthy.
2. Test names (describe, it) are concise, explicit, descriptive.
3. Avoid logic in your tests.
4. Don't test multiple concerns in the same test.
5. Cover the general case and the edge cases.
6. Test the behaviour, not the internal implementation.
7. Use a mock to simulate/stub complex class structure, methods or async functions.

Git

1. Commits are small and divided into logical parts.
2. Commits messages are small and understandable.
3. Use branches for new features.
4. Make sure no dist files, editor/IDE files, etc are checked in. There should be a .gitignore for that.

Other

1. Security.
2. Usability.

Useful links

• Front-End Checklist Application
• Code Review Checklist – To Perform Effective Code Reviews
• Code review checklist
• React code review checklist
• Checklist for reviewing your own React code
• Front-end Code Review & Validation Tools
• A guide to unit testing in JavaScript
• Unit Testing Checklist: Keep Your Tests Useful and Avoid Big Mistakes