Get your code review issues manual!

Code review lists are clear rules and guidelines for code reviews that can benefit your team and significantly speed up code reviews.

Studies have shown that reviewers who use code review lists perform better than reviewers who don’t. So whether you’re a new developer or an experienced developer, start thinking about using code review lists.

A list of things code authors should be concerned about

As the author of the code, you should ensure that:

  • Code compiles and passes static checks (no warnings)
  • Code passes all tests (unit, integration, and system tests)
  • You’ve checked for spelling errors and fixed them (comments, todo, etc.)
  • Outline why the code changed and where it changed

In addition, as a code author, you should review your code against the reviewer’s list before submitting it for review.

A list of things code reviewers should be concerned about

As a code reviewer, your job is to find the most important problems. Comments can be more valuable on structural or logical issues in your code, even if they can sometimes be critical.

You should know what good code feedback is. It is also important to note that the best code review feedback is not comments, but suggestions. So instead of saying “The variable name should be removeObject,” it’s better to say “How about calling the variable removeObject? “.

The following list is enough to help you provide good code review feedback.

implementation

  • Does this code change do what it’s supposed to do?
  • Is this the simplest solution?
  • Does this change introduce any unnecessary compile-time or run-time dependencies?
  • Are you using frameworks, apis, libraries, services that you shouldn’t be using?
  • Are there unused frameworks, apis, libraries, services that can enhance the solution?
  • Is the code at the right level of abstraction?
  • Is the code modularity good enough?
  • Do you have another solution that is better in terms of code maintainability, readability, performance, security?
  • Is there already a function that does something similar? If so, why not reuse it?
  • Are there best practices, design patterns, or language-specific patterns that can optimize your code?
  • Does the code follow object-oriented analysis and design principles, such as the single responsibility principle, open close principle, Richter substitution principle, interface isolation, dependency injection?

Logic error or Bug

  • Can you think of any use cases where the code doesn’t work as expected?
  • Can you think of any input or external events that might break the code?

Error handling and logging

  • Are errors handled correctly?
  • Is there any log or debug information that needs to be added or deleted?
  • Are error messages user-friendly?
  • Are there sufficient logs, and are they written in a way that is easy to debug?

Availability and accessibility

  • Is the proposed solution well designed from a usability perspective?
  • Is the API documentation good enough?
  • Is the proposed solution accessible?
  • Is the API/UI intuitive and easy to use?

Testing versus testability

  • Is the code up to testable standards?
  • Are there adequate automated tests (unit tests/integration tests/system tests)?
  • Do existing tests properly cover code changes?
  • Are there additional test cases, input or boundary cases for testing?

Rely on

  • If the change requires updating files outside the code, such as updating documentation, configuration, readme files. Are these updates complete?
  • Will this change affect the rest of the system? Is it backward compatible?

Secure and private data

  • Does this code open a security hole in the software?
  • Are permissions and authentication handled correctly?
  • Is sensitive data securely handled, such as user data, credit card information, etc.? Are encryption methods used correctly?
  • Did the code change reveal any private information (e.g. drugs, usernames, etc.)?
  • If the code handles user input, does it address security vulnerabilities such as cross-site scripting, SQL injection, and input cleansing and validation?
  • Is the data obtained from external apis or libraries checked accordingly?

performance

  • Does this code change have a negative impact on system performance?
  • Can code performance be further improved?

readability

  • Is the code easy to understand?
  • Which part puzzles you and why?
  • Can you improve code readability by reducing methods?
  • Can code readability be improved by using different function/method or variable names?
  • Is the code stored in the correct file/directory/package?
  • Do you think the method should be refactored to have a more intuitive control flow?
  • Is the data flow understandable?
  • Are there any extra comments?
  • Do some comments better convey the message?
  • Would more comments make your code easier to understand?
  • Is it possible to remove some comments and understand the code by making it more readable?
  • Is there commented out code?

Expert opinion

  • Do you think that specific experts (such as security experts or usability experts) should review the code before submitting it?
  • Will this code change affect other teams? Should they have an opinion, too?

So that’s a list of some of the most pressing issues.

Code style and conventions

It is important that your team or company have clear coding style guidelines. Because that’s the only way to enforce uniqueness in your code base. And consistency makes code reviews faster, makes it easier for people to change projects, and keeps your code readable and maintainable.

Google is a good example of this, and it certainly allows Google to do quick code reviews.

First, I recommend using off-the-shelf coding styles to support the many languages that Google provides. It’s important to set ground rules, but make sure they’re permanent. Don’t keep arguing.

Automate as much as possible

Once you’ve determined your code style, take some time to properly install and configure the tools so that you can format your code with one click.

There’s a lot more that can be done. For example, use static checks instead of some manual reviews. It’s worth fighting for.

Full list of questions

The original link

www.michaelagreiler.com/code-review…