code review checklist

2019 Unicorn Enterprises Recruit Python Engineer Standards >>>

1. Code Review Process

• Merge RequestInitiate an Code Reviewapplication by
• Before code review, developers will 设计思路talk to reviewers (for remote teams, design ideas need to be documented)
• Review the code according to the code review checkpoints, Gitlaband leave the problems on the topcomment
• The developer modifies the code according to the review comments and initiates another review
• After the code review is passed, merge the code into the main branch

2. Code Review Checkpoints

2.1 Clean code

list item	Classification
Use names that express the actual intent (Intention-Revealing)	meaningful name
Use only one word for each concept	meaningful name
Use Scenario/Problem Domain Name	meaningful name
Classes should be relatively small!	kind
The function should be relatively small!	function
only do one thing	function
DRY (Don't Repeat Yourself) principle, (refuse to repeat)	function
Use code to explain your approach	Notes
Make sure code formatting is applied	Format
Use exceptions instead of return codes	abnormal
Do not return Null	abnormal

2.2 Safety

list item	Classification
Make the class final if not used for inheritance	Base
avoid duplication of code	Base
Privilege Restrictions: Programs should run in least privilege mode to ensure proper functionality.	Base
Minimize the accessibility of classes and members	Base
Annotate safety-related information	Base
The input to the system must be checked for validity and within the allowable range	Denial of Service
Avoid excessive logging of unusual behavior	Denial of Service
Release resources (streams, connections, etc.) in any case	Denial of Service
Clear sensitive information from exceptions (exposed file paths, system internal related, configuration) P	Confidential Information
Do not write highly sensitive information to the log	Confidential Information
Consider clearing highly sensitive information from memory after use	Confidential Information
Restrict the accessibility of packages, classes, interfaces, methods and fields	Accessibility Extensibility
Restrict extensibility of classes and methods (by making them final)	Accessibility Extensibility
Check input (valid data, size, range, edge cases, etc.)	Input Validation
Test output from untrusted objects as input	Input Validation
Define wrapper classes for native methods (instead of defining native methods as pulibc)	Input Validation
Treat output from untrusted objects as input	variability
Make the public static field final (to prevent the caller from modifying its value)	variability
Avoid exposing sensitive class constructors	object construction
Avoid serialization of security-sensitive classes	Serialization Deserialization
Protect sensitive data with serialization	Serialization Deserialization
Carefully cache the results of potentially privileged operations	Serialization Deserialization
Use JNI only when needed	restriction of visit

2.3 Performance

list item	Classification
Avoid excessive synchronization	Concurrency
Keep the sync area small	Concurrency
Know the performance of string concatenation	Comprehensive programming
Avoid creating unwanted objects	Create and destroy objects

2.4 General

list item	Classification
Use checked exceptions for recoverable situations and runtime exceptions for program errors	abnormal
More use of standard exceptions	abnormal
Don't ignore exceptions	abnormal
Check the validity of parameters	method
Returns an empty array or collection, not null	method
Minimize the accessibility of classes and members	classes and interfaces
In public classes, use accessor methods instead of public fields	classes and interfaces
Minimize the scope of local variables	Comprehensive programming
Referencing an object through an interface	Comprehensive programming
Follow widely accepted naming conventions	Comprehensive programming
Avoid finalizers	Create and destroy objects
Always override hashCode when you override equals	Comprehensive programming
always override toString	Comprehensive programming
Use enums instead of int constants	Enumerations and Annotations
Use marker interface to define types	Enumerations and Annotations
Use synchronous access to shared mutable data	Concurrency
Use executors instead of tasks and threads	Concurrency
Thread safety is described in comments	Concurrency
Valid JUnit/JBehave test cases exist	test

3. Code Review Checklist

• General item

  • Does the code work? Does it implement the expected function, whether the logic is correct, etc.
  • Is all the code simple and easy to understand?
  • Does the code conform to the programming conventions you follow? This usually includes the position of curly braces, variable and function names, line length, indentation, formatting, and comments.
  • Is there redundant or duplicate code?
  • Is the code as modular as possible?
  • Are there global variables that can be replaced?
  • Is there any code that is commented out?
  • Does the loop have a set length and correct termination condition?
  • Is there code that can be replaced by library functions?
  • Is there a log or debug code that can be removed?

• Safety

  • Are all data inputs checked (detecting correct type, length, format and range) and encoded?
  • Where are 3rd party tools used and are the returned errors caught?
  • Are the output values ​​checked and encoded?
  • Can invalid parameter values ​​be handled?

• Documentation

  • Are there comments and describe the intent of the code?
  • Are all functions annotated?
  • Are there descriptions for unusual behavior and edge case handling?
  • Is there documentation for the use and functions of third-party libraries?
  • Are data structures and units of measure explained?
  • Is there unfinished code? If so, should it be removed, or marked with a suitable marker like 'TODO'?

• test

  • Is the code testable? For example, don't add too many or hidden dependencies, can't initialize objects, test frameworks can use methods, etc.
  • Are there tests and are they understandable? For example, at least achieve your satisfactory code coverage (code coverage).
  • Do unit tests really test that the code does what it's supposed to do?
  • Is the array checked for "out of bounds" errors?
  • Is there test code that can be replaced by an already existing API?

Reprinted in: https://my.oschina.net/eonezhang/blog/3045911