Database:
- Use timestamp for when something happened: updated_time, created_time.
- Use datetime for when something is scheduled to happen: reminder_time, renew_time - this is why datetime depends on the timezone; the point-in-time of the reminder depends on the daylight savings in that timezone at the point the reminder should fire.
- The commit message should explain WHY the change was needed, not WHAT the change does (because what the change does should already be apparent from the code and in-line comments).
- If you have an if/unless conditional you can fit on one line, use a post-fix:
- if ( $i == 3 ) { return $i }
- is better written as
- return $i if $i == 3;
- The second form is better because it discourages nested logic (which is harder to read and maintain)
- Generally prefer subroutines and "return" statements to control flow, instead of "if/then/else" statements. This way the code is factored into smaller chunks that are easier to understand, modify and test.
- Always include a dry-run option in stand-alone scripts meant for production.
- Every pull request must contain one and only one feature/behaviour that needed changing. This reduces cognitive drain on human reviewers who are required to scan everything and may therefore miss some details.
Posts
