Make sure these boxes are checked before submitting the PR
- The code works
- The code is easy to understand
- Follows coding conventions PSR-1 and PSR-2
- Declared variables are used
- Variable names are simple, short and spelt correctly
- No negatively named boolean variables
- Variable names contain units where applicable
- Variables are in the smallest scope possible
- There are no usages of magic numbers (see also)
- There is no code that can be replaced with library functions
- Code is not repeated or duplicated (https://en.wikipedia.org/wiki/Don%27t_repeat_yourself)
- “Dead Code” is removed or, if temporary hack, it should be identified as such
- Exceptions are not eaten if caught, unless explicitly documented otherwise
- == operator and === (and its inverse !==) are not mixed up
- Try to use constants in the left-hand side of the comparison (2 == $variable)
- Always try using single quote (') instead of double quotes (") when working with strings
- Floating point numbers are not compared for equality
- Blocks of code inside loops are as small as possible and have correct termination conditions
- Methods return early without compromising code readability
- Performance is considered
- Design patterns if correctly applied
- A class should have only a single responsibility
- Classes, modules, functions, etc. should be open for extension, but closed for modification
- Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program
- Many client-specific interfaces are better than one general-purpose interface
- APIs and other public contracts check input values and fail fast
- API checks for correct oauth scope / user permissions
- Any API change should be reflected in the API documentation
- APIs return correct status codes in responses
- Logging should be easily discoverable
- Required logs are present
- Frivolous logs are absent
- No print_r, var_dump or similar calls exist
- Comments should indicate WHY rather that WHAT the code is doing
- All methods are commented in clear language
- Comments exist and describe rationale or reasons for decisions in code (link task ID where possible)
- All public methods/interfaces/contracts are commented with describing usage
- All edge cases are described in comments
- All unusual behaviour or edge case handling is commented
- Data structures and units of measurement are explained
- All data inputs are checked (for the correct type, length/size, format, and range)
- No sensitive information is logged or visible in a stacktrace