Compare commits
1
Commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
f791823d10 |
@@ -37,40 +37,39 @@ These rules MUST be followed at all times. This is very important.
|
||||
development, TDD). The test does not need to be very complex. Commit the test,
|
||||
then commit the feature.
|
||||
|
||||
- When adding a new feature, use a feature branch. A feature branch lands on
|
||||
`next` through a reviewed PR. The branch is merged, and then deleted, only
|
||||
when the feature is completely finished and the code passes `make check`. Only
|
||||
the owner merges `next` into `main`.
|
||||
- When adding a new feature, use a feature branch. The feature branch is merged
|
||||
into `next`, and then deleted, only when the feature is completely finished
|
||||
and the code is up to standards. The code is up to standards when it passes
|
||||
`make check`. Only the user merges `next` into `main`.
|
||||
|
||||
- Write `godoc` comments for all exported types and functions as you go along.
|
||||
|
||||
- ALWAYS be consistent in naming. If you name something one way in one place,
|
||||
use the EXACT SAME name in every other place.
|
||||
|
||||
- Be descriptive and specific in naming. `wl` is bad; `SourceHostAllowlist` is
|
||||
- Be descriptive and specific in naming. `al` is bad; `SourceHostAllowlist` is
|
||||
good. `ConnsPerHost` is bad; `MaxConnectionsPerHost` is good.
|
||||
|
||||
- This is not prototype or teaching code. It is designed for production. Any
|
||||
security issue (such as denial of service) or other web vulnerability is a P1
|
||||
bug, the highest priority. It must be added at the top of `TODO.md`.
|
||||
bug. It must be added at the top of `TODO.md`.
|
||||
|
||||
- Do not stub an implementation unless you are specifically instructed to. This
|
||||
is production code, and we need working implementations.
|
||||
|
||||
- NEVER silently fall back to a different setting when a user's parameter
|
||||
explicitly specifies a value. Return an error instead. For example, if a user
|
||||
requests `format=webp` and WebP encoding is not supported, return an error. Do
|
||||
NOT silently output PNG instead. If a user specifies `fit=invalid` and that
|
||||
fit mode does not exist, return an error. Do NOT silently default to `cover`.
|
||||
A silent fallback violates the principle of least surprise and masks bugs.
|
||||
Defaults are acceptable only for OMITTED parameters, never for INVALID
|
||||
explicit values.
|
||||
explicitly specifies a value. For example, if a user requests `format=webp`
|
||||
and WebP encoding is not supported, return an error. Do NOT silently output
|
||||
PNG instead. If a user specifies `fit=invalid` and that fit mode does not
|
||||
exist, return an error. Do NOT silently default to `cover`. A silent fallback
|
||||
violates the principle of least surprise and masks bugs. Defaults are
|
||||
acceptable only for OMITTED parameters, never for INVALID explicit values.
|
||||
|
||||
- Avoid vendoring dependencies unless specifically instructed to. NEVER commit
|
||||
the `vendor/` directory. NEVER commit compiled binaries. If such a directory
|
||||
or file exists and `.gitignore` does not list it, add it to `.gitignore`.
|
||||
Commit that `.gitignore` change. Keep the entire git repository, history
|
||||
included, under 20 MiB. Commit a larger file only when you specifically must.
|
||||
Media files used as test fixtures are one such case. Only OUR source code and
|
||||
its immediately supporting files, such as test examples, go into the
|
||||
included, under 20 MiB. Go over 20 MiB only when you specifically must commit
|
||||
a large file, such as a media file used as a test fixture. Only OUR source
|
||||
code and its immediately supporting files, such as test examples, go into the
|
||||
repository and its history.
|
||||
|
||||
Reference in New Issue
Block a user