fisher
3a6fafb5c7
Replaces the per-project deploy scripts and self-contained webhook receivers with one manifest-driven implementation that lives outside the application repositories and can be updated independently of them. First targets: domaindingo test and prod on s5.
33 lines
1.3 KiB
Markdown
33 lines
1.3 KiB
Markdown
# Working Style Checklist
|
|
|
|
Decision ladder before writing code or tooling (from [Ponytail](https://github.com/DietrichGebert/ponytail)):
|
|
|
|
1. **Does this need to exist?** → No: skip it (YAGNI)
|
|
2. **Already in this codebase?** → Reuse, don't rewrite
|
|
3. **Stdlib does it?** → Use it
|
|
4. **Native platform feature?** → Use it
|
|
5. **Installed dependency?** → Use it
|
|
6. **One line?** → One line
|
|
7. **Only then:** the minimum that works
|
|
|
|
Lazy about the solution, never about reading the problem first.
|
|
|
|
## Math & Arithmetic
|
|
|
|
For numeric calculations in shell scripts, pick the simplest rung:
|
|
- Shell arithmetic `$(( ))` — fixed-width integers, one line
|
|
- `bc` — arbitrary precision when needed
|
|
- Python `python3 -c "print(...)"` — complex logic or exact precision
|
|
- Always validate edge cases (overflow, division by zero)
|
|
|
|
## Plain English
|
|
|
|
Write in plain English for system administrators:
|
|
- Prefer short, direct sentences.
|
|
- Use concrete verbs: check, read, write, test, stop, ask.
|
|
- Avoid management and policy terms such as leverage, align, facilitate, ensure, optimize, stakeholder, outcome, and workflow.
|
|
- Say who should act and under which condition.
|
|
- Keep necessary technical terms, but explain unfamiliar ones.
|
|
- Remove repetition and text that does not change the action.
|
|
- Preserve the exact meaning and all safety requirements.
|