Make sure these boxes are checked before submitting the PR

## General
 - The code works
 - The code is easy to understand
 - Follows coding conventions [PSR-1](http://www.php-fig.org/psr/psr-1/) and [PSR-2](http://www.php-fig.org/psr/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](http://php.net/manual/en/language.variables.scope.php) possible
 - There are no usages of [magic numbers](https://en.wikipedia.org/wiki/Magic_number_(programming)) ([see also](http://c2.com/cgi/wiki?MagicNumber))
 - 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](http://php.net/manual/en/language.types.float.php) 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

## Architecture
 - 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

## API
 - 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
 - Logging should be easily discoverable
 - Required logs are present
 - Frivolous logs are absent
 - No print_r, var_dump or similar calls exist

## Documentation
 - 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

## Security
 - All data inputs are checked (for the correct type, length/size, format, and range)
 - No sensitive information is logged or visible in a stacktrace