Review Checklist
When reviewing patches in Apache JIRA or GitHub pull requests, cover the following areas. This checklist is adapted from the project’s legacy development documentation.
Critical
-
Are all data inputs and outputs checked for the correct type, length, format, and range?
-
Where third-party utilities are used, are returned errors being caught?
-
Are invalid parameter values handled?
-
Are any
ThrowableorExceptioninstances passed toJVMStabilityInspector? -
Do exceptions propagate to the appropriate level in the code?
-
Are errors well-documented, and do they tell the user how to proceed?
-
Do tests exist for the behavior, and do they cover the intended functionality?
-
Is the patch passing CI for all affected branches?
-
If the patch affects the read/write path, was it tested for performance regressions?
Important
-
Does it conform to the code style guidelines?
-
Is the code as modular as possible?
-
Can any singleton be avoided?
-
Can any of the code be replaced with library functions?
-
Are units of measurement used in the code consistent, both internally and with the rest of the ecosystem?
-
Do comments describe the intent of the code, not just the implementation?
-
Are Javadocs added where appropriate?
-
Is any unusual behavior or edge-case handling described?
-
Are data structures and units of measurement explained?
-
Is there any incomplete code that should be removed or flagged with
TODO? -
Does the code self-document via clear naming, abstractions, and flow control?
-
Have
NEWS.txt, the CQL docs, and the native protocol spec been updated if needed? -
Is the ticket tagged with
client-impactinganddoc-impactingwhere appropriate? -
Has
lib/licensesbeen updated for third-party libs, and are they Apache License compatible? -
Is the Component on the JIRA ticket set appropriately?
-
Is the code testable, with no hidden dependencies that block reuse in tests?
-
Could test code use common functionality such as CCM, dtest, or
CqlTesterhelpers? -
If the code may be affected by multi-node clusters, are there dtests?
-
If the code may take a long time to test properly, are there continuous verification harness (CVH) tests?
-
If adding a new feature, were tests added for the expected SLA or use case?
Nice-to-have
-
Is there any redundant or duplicate code?
-
Are logging statements at the right level?
-
Are there logs in the critical path that could affect performance?
-
Is there any log that could be added to communicate status or troubleshoot potential problems?
-
Can any unnecessary logging statements be removed?