mirror of
https://github.com/go-gitea/gitea.git
synced 2026-11-09 17:37:20 -06:00
Some useful rules from my past experiences, feel free to suggest more. Dark theme screenshots is subjective of course, but I prefer them. --------- Signed-off-by: silverwind <me@silverwind.io>
3.2 KiB
3.2 KiB
- Never assume, verify before claiming
- List development targets with
make help - Before working on code, read the
docsguides for every area touched:guidelines-backend.mdfor Go,guidelines-frontend.mdfor TS, CSS and Vue, both for templates,testing.mdfor tests,development.mdfor config options and migrations,guidelines-refactoring.mdfor refactors - Before designing a feature or behavior, check prior art in GitHub and GitLab
- Don't add code for theoretical edge cases, only for ones that can realistically occur
- Write docs concisely and user-facing, skip implementation details
- PR descriptions: minimal, only what and why, no task or file listings, no headings. Aim for less than 1000 characters. References go at the end of the description like
Fixes: <url>. - PR descriptions and update comments: Include screenshots for UI changes, before and after side by side. Take them at 4x scale in dark theme, cropped to the changes with some padding, and embed them at half CSS size
- Reference issues and PRs by full URL, not by number
- Use Conventional Commits for commit messages and PR titles, plus Gitea's
enhancetype for user-facing enhancements - Add an
Assisted-by: AGENT_NAME:MODEL_VERSIONtrailer to commit messages and PR descriptions, neverCo-Authored-ByorSigned-off-by - Attribute agent authorship on one trailing line in issue and PR comments, never as a PR description section
- Never rewrite git history unless asked, update PRs with new commits and normal push
- Comments: write almost none, short and preferably same-line, explaining why for a future reader. Never narrate code, the change or the prompt. Preserve existing ones that still apply. If you need to write a paragraph-long comment, rethink your implementation, it is likely too complicated
- Add the current year to copyright headers of new
.gofiles - In
options/locale, only editlocale_en-US.json, other locales are synced automatically - In TS, use
!instead of?./??when a value always exists - In Go, prefer to use modern language features wherever possible
- In Go, function-name prefixes in errors like
fmt.Errorf("Foo: %w", err)must always name the function they are in - Write sizes as multiplications like
64 * 1024, not bit shifts like64 << 10 - Prefer
tw-*utilities over inlinestyleandflex-*helpers over per-childtw-ml-*/tw-mr-*margins, falling back totw-*where specificity requires!important - Run
make fmtafter.goedits,make tidyaftergo.modedits,make generate-swaggerafter API changes, and lint what changed withmake lint-go,lint-js,lint-cssorlint-templates - Fix the cause rather than disabling a linter or weakening a test. Where unavoidable, use the narrowest scope with a trailing comment giving the reason
- Run single tests with
go test -run '^TestName$' ./modulepath/for Go,pnpm exec vitest <path-filter>for TS andGITEA_TEST_E2E_FLAGS='<filepath>' make test-e2efor e2e - Write the fewest, fastest tests covering the behavior, extending an existing one where possible. Prefer unit tests where logic is testable in isolation
- Aim for sub-2s per integration test and sub-4s per e2e test. Wait on a deterministic condition rather than
sleep, and prefer semantic locators in e2e tests