Code Review in JavaScript: What to Check and How to Give Feedback for Beginners
\n\nCode review is the process of checking program code by one or more developers before it is merged into the main project branch. For beginners, this procedure often seems daunting: "What if I miss a bug?", "How do I tell a colleague their code is bad without ruining the relationship?".
\n\nIn this article, we will break down what to look for during a code review in JavaScript (including Node.js), and how to give feedback that is helpful rather than offensive. The material is aimed at beginner developers who are just starting to participate in reviews.
\n\nWhat to Check in JavaScript Code: A Checklist for Beginners
\n\nTo make the review structured, let's divide the check into several key blocks. Don't try to cover everything at once — start with the most critical points.
\n\n1. Functionality and Logic
\nFirst and foremost, make sure the code solves the given task. Run it locally (if possible) or mentally go through all execution paths. Here are typical questions:
\n- \n
- Are edge cases handled correctly (empty array,
null,undefined)? \n - Are there any "magic numbers" (numbers without explanation, e.g.,
if (x > 86400)instead ofconst ONE_DAY_IN_SECONDS = 86400)? \n - Does the asynchronous code work correctly (Promise, async/await)? \n
// Bad: magic number\nif (user.lastLogin < Date.now() - 86400000) { ... }\n\n// Good: named constant\nconst ONE_DAY_MS = 24 * 60 * 60 * 1000;\nif (user.lastLogin < Date.now() - ONE_DAY_MS) { ... }\n\n2. Code Style and Formatting
\nAlthough many projects use Prettier and ESLint, it's worth manually checking:
\n- \n
- Adherence to a consistent style (indentation, quotes, semicolons). \n
- Correct naming of variables, functions, and classes (camelCase for variables, PascalCase for classes). \n
- Absence of commented-out code — it only clutters the file. \n
// Bad: uninformative name\nconst d = new Date();\nconst arr = getData(d);\n\n// Good: name describes the essence\nconst currentDate = new Date();\nconst usersData = fetchUsersData(currentDate);\n\n3. Performance and Security
\nFor Node.js, the following are especially important:
\n- \n
- Avoiding blocking operations in the main thread (synchronous file reads, heavy loops). \n
- Checking for memory leaks (e.g., forgotten timers or event listeners). \n
- Validation of user input (protection against SQL injection, XSS). \n
// Bad: synchronous read blocks the Event Loop\nconst data = fs.readFileSync('bigfile.json', 'utf8');\n\n// Good: asynchronous read\nconst data = await fs.promises.readFile('bigfile.json', 'utf8');\n\nHow to Give Feedback: Principles of Constructive Review
\n\nNow that you know what to check, let's break down the main skill of code review — the ability to communicate comments. Your goal is to improve the code, not to assert yourself at the author's expense.
\n\n1. Be Specific and Reasoned
\nInstead of "This code is bad," write: "There is a potential performance issue here: calling Array.find() in a loop gives O(n²) complexity. Let's replace it with a Map." The author will understand exactly what is wrong and how to fix it.
2. Use "I" Statements and Ask Questions
\nPhrasings like "I'm not sure this code handles the case of an empty array. Can we add a check?" sound softer than "You forgot to handle the empty array." This reduces defensiveness and encourages dialogue.
\n\n3. Praise Good Solutions
\nCode review is not just about criticism. If you see an elegant solution or excellent architecture, be sure to note it. For example: "Great idea to extract