Front-end JavaScript/TypeScript Code Review Checklist

javascript-review-checklist.md

Review checklist

General

1. Does the code work?
2. Description of the project status is included.
3. Code is easily understand.
4. Code is written following the coding standarts/guidelines (React in our case).
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 (don't forget about React components)?
8. Are functions/classes/components reasonably small (not too big)?
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 console usage, replace it by another logger lib
14. avoid long files, more than 400-500 lines are hard to support
15. build on the shoulders of giants (use well tested libraries instead of developing own)
16. avoid multiple returns in code (but be ok with a quick input params checks and quick return)
17. avoid nesting/scopes (more than 3 levels is usually problematic)

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.

ES6/7

1. Use ES6 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 Asyns/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 Sagas
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.
9. prefer arrow functions (es2015 syntax)
10. avoid this. usage

Third-Party Libraries

1. Use lodash/ramda functions instead of implementing itself.
2. Is Immutable.js was used correctly?
3. Is any nice/useful library was used wich we didn't know before?

ESLint

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

CSS/CSS in JS

1. Consistent naming conventions are used (BEM, OOCSS, SMACSS, e.t.c.).
2. CSS selectors are only as specific as they need to be; grouped logically.
3. Is any 'CSS in JS' library was used?
4. Use Hex color codes #000 unless using rgba().
5. Avoid absolute positioning.
6. Use flexbox.
7. Avoid !important.
8. Do not animate width, height, top, left and others. Use transform instead.
9. Use same units for all project.
10. Avoid inline styles.
11. Use clsx lib (or alternative) for composing styles
12. Document and test layout parent/container to child dependency (flex, grid, width, heights, etc)
13. Try to structure styles by categories:

• Layout responsive rules/media queries,
• visual styles, typography, colors, fonts, text size
• background images, background color
• animation

14. separate code from styles
15. do not mix different CSS styles libs (MUI, tailwind, bootstrap, etc)

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. Is test agnostic to component code changes?
7. Use a mock to simulate/stub complex class structure, methods or async functions.
8. Possitive and Negative tests available
9. Code coverage is higher 85%
10. Module isolated during test from external dependencies (avoid child components/libs testing)
11. Avoid "magic numbers" in tests (index of parameter, index of mock calls history, etc.)

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

• 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

Java Script Best Practices

• Java Script Best Practices
• W3 Best Practices === Js Best Practices from Opera Dev
• 5 Differences Between Arrow and Regular Functions
• ES.NEXT Finished Proposals
• ES.NEXT
• Common Mistakes
• Performacne Hints
• 24 Js Best Practices for Beginners

Tools

• babeljs.io

Books - https://blog.devgenius.io/top-12-javascript-books-to-read-in-2022-282dc630e0dc

Refs:

• https://medium.com/@dreamy-player/40-killer-javascript-one-liners-fc76edaf8439