🗼 collection of software development tips and principles
“It is not enough for code to work.”
― Robert C. Martin
- DRY – Don’t Repeat Yourself
- KISS – Keep It Simple Stupid
- YAGNI – You Aren’t Gonna Need It
- SOLID:
- S – Single Responsibility Principle
- O – Open-Closed Principle
- L – Liskov Substitution Principle
- I – Interface Segregation Principle
- D – Dependency Inversion Principle
Ref: SOLID in wikipedia
Ref: Summary of 'Clean code' by Robert C. Martin
If you don't have your own guide, it's a good idea to adhere Google code style guides.
If you have your own guide, please keep it as general as possible.
Describe your changes in imperative mood, e.g. "make xyzzy do frotz" instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy to do frotz", as if you are giving orders to the codebase to change its behavior.
As is described at Documentation/SubmittingPatches in the Git repo
A specification for adding human and machine readable meaning to commit messages: https://www.conventionalcommits.org/en/v1.0.0/
TODOs should include the string TODO in all caps, followed by the name, or other identifier of the person who can best provide context about the problem referenced by the TODO, in parentheses.
Example:
// TODO(drew2a) Add todo convention to CONTRIBUTING.md
- Use OneFlow by default
- While merge, use
rebase + merge –no–ff(more information) - Merge or rebase
- Use slash to separate groups of branches
- Use a ticket key in a branch name
Example
feature/123
feature/657-add-travis-ci
fix/741
release/1.2
- PR should improve overall code health of the system, even if the CL isn’t perfect
- Instead of seeking perfection, what a reviewer should seek is continuous improvement
- Review should be fast (1 day maximum)
More information: Pull Request
- Key words for use in RFCs to Indicate Requirement Levels: https://datatracker.ietf.org/doc/html/rfc2119
- Large-Scale Scrum: https://less.works/
- Getting Real: https://basecamp.com/gettingreal