Code Quality
These standards define the baseline quality expectations for SDK code. They apply across all SDKs — specific tools and thresholds vary by language, but the principles are universal.
Every SDK repo MUST enforce linting and formatting in CI. Code that doesn't pass can't merge — no exceptions.
Type checking is also REQUIRED in CI for statically typed languages (Java, Kotlin, Swift, C#, Go, Rust, Dart) and dynamically typed languages with established type-checking ecosystems (TypeScript, Python, PHP, Elixir). Languages without mature type-checking tooling (e.g., Ruby) may be exempt.
Which linter, what rules, and how strict — that's up to each SDK. The standard is that automated checks exist and block merges.
The type of change determines what tests are needed:
- Bug fix: a regression test that fails without the fix and passes with it
- New feature: unit tests, plus integration tests where applicable
- Refactor: existing tests should still pass; add new tests only if coverage was missing
- Performance change: benchmark or measurable evidence
- Breaking change: update or remove old tests, add new ones
Tests should assert meaningful behavior. Ask yourself: what user-visible behavior would break if this test were deleted? If the answer is "nothing," the test isn't useful.
Some specific things to watch for:
- "No exception thrown" is only a valid assertion when exception handling is the behavior under test
- Snapshot tests need to be reviewed for correctness, not auto-accepted
- AI-generated tests need extra scrutiny — look for hardcoded values, implementation-detail testing, and tests that pass regardless of behavior
Adding a dependency is a decision that affects every user of the SDK, so it deserves scrutiny. New dependencies REQUIRE explicit justification in the PR description. Pin them to a version range — no floating versions.
Transitive dependencies matter too. If a transitive dependency changes behavior, that deserves the same review as adding a direct dependency. Run dependency audits at least quarterly.
See Adding a Dependency for the step-by-step evaluation and approval workflow.
Each SDK MUST define and track budgets for:
- Package/binary size (where applicable)
- Initialization time
- Memory overhead
The specific numbers are up to each SDK. The standard is that budgets exist, are tracked, and are visible in CI.
No secrets, credentials, or PII in code or commits. Data handling follows the data handling spec.
Security-sensitive changes REQUIRE review from someone with security context. Dependency vulnerability alerts MUST NOT be ignored or silently dismissed.
| Version | Date | Summary |
|---|---|---|
1.0.0 | 2026-02-19 | Initial Code Quality standard |
Our documentation is open source and available on GitHub. Your contributions are welcome, whether fixing a typo (drat!) or suggesting an update ("yeah, this would be better").