name: Code Quality Standards description: This skill should be used when the user asks about "code quality", "formatting", "linting", "lint rules", "code style", "error handling", "unsafe code", "documentation comments", "doc comments", "rustfmt", "prettier", "eslint", "clippy", or needs guidance on code quality enforcement and configuration. version: 1.0.0
Code Quality Standards
Guidance for implementing code quality requirements including formatting, linting, error handling, and documentation.
Tooling
Available Tools: If using Claude Code, the
pr-review-toolkit:code-revieweragent can assess code quality against these standards. Use/pr-review-toolkit:review-prfor comprehensive PR review.
Formatting Requirements
Automated Formatting (MUST)
- All source code MUST pass automated formatting checks before merge
- Projects MUST define and commit formatting configuration files
- Import/include statements MUST be automatically sorted and grouped
Formatting Standards (MUST)
| Standard | Requirement |
|---|---|
| Line length | MUST be 100 characters maximum |
| Indentation | MUST be consistent (spaces or tabs, not mixed) |
| Line endings | MUST be Unix-style (LF) |
| Trailing whitespace | MUST be removed |
| Final newline | MUST be present |
Formatter Configuration by Language
| Language | Tool | Config File |
|---|---|---|
| Rust | rustfmt | rustfmt.toml |
| TypeScript/JS | Prettier | .prettierrc |
| Python | Black/Ruff | pyproject.toml |
| Java | google-java-format | .editorconfig |
| Go | gofmt | (built-in) |
Linting Requirements
Static Analysis (MUST)
- Projects MUST use static analysis tools appropriate to the language
- CI pipelines MUST run linting with warnings treated as errors
- Lint rule exceptions MUST be documented with justification
Lint Categories
| Category | Enforcement |
|---|---|
| Correctness | MUST be enabled |
| Performance | MUST be enabled |
| Style | SHOULD be enabled |
| Complexity | SHOULD be enabled |
| Documentation | SHOULD be enabled |
| Pedantic | SHOULD be enabled |
| Nursery/Experimental | MAY be enabled |
Linter Configuration by Language
| Language | Tool | Config File |
|---|---|---|
| Rust | Clippy | clippy.toml, Cargo.toml |
| TypeScript | ESLint | eslint.config.js |
| Python | Ruff | pyproject.toml |
| Java | SpotBugs, PMD | spotbugs.xml, pmd.xml |
| Go | golangci-lint | .golangci.yml |
Documenting Lint Exceptions
When disabling a lint rule, document the justification:
// Rust
#[allow(clippy::too_many_arguments)]
// Justification: This function wraps an external API that requires these parameters
fn external_api_wrapper(...) {}
// TypeScript
// eslint-disable-next-line @typescript-eslint/no-explicit-any
// Justification: Third-party library returns untyped data
const data: any = externalLib.getData();
Error Handling Requirements
Library Code (MUST NOT)
Library code MUST NOT:
- Panic, abort, or terminate the process unexpectedly
- Use unchecked unwrapping of optional/nullable values
- Use unchecked type assertions/casts
- Leave exceptions unhandled
- Call process exit functions
Structured Error Handling (MUST)
All error conditions MUST be handled via structured error types or result types:
| Language | Pattern |
|---|---|
| Rust | Result<T, E>, Option<T> |
| TypeScript | Result type, explicit error returns |
| Python | Custom exceptions, explicit raises |
| Java | Checked exceptions, Optional<T> |
| Go | Multiple return values (T, error) |
Exceptions for Test/CLI Code
Test code and CLI entry points MAY use simplified error handling where appropriate (e.g., .unwrap() in tests, panic! at CLI boundaries).
Unsafe Code Requirements
Minimization (MUST)
Unsafe code blocks MUST be minimized.
Documentation (MUST)
All unsafe code MUST be:
- Documented with safety invariants
- Encapsulated in safe abstractions
- Reviewed by at least one additional maintainer
Compiler Warnings (MUST)
Projects MUST enable compiler/linter warnings for unsafe code usage:
// Rust - in Cargo.toml or lib.rs
#![warn(unsafe_code)]
Documentation Comments
Public API Documentation (MUST)
All public APIs MUST have documentation comments including:
- Brief description of purpose
- Parameter descriptions
- Return value descriptions
- Error conditions (what errors can occur and when)
Recommended Documentation
Documentation SHOULD include:
- Usage examples (preferably as tested code)
- References to related APIs
- Notes on thread safety or concurrency
Documentation Validation (MUST)
Documentation MUST be validated as part of CI:
- No broken links
- Valid examples (doc tests where supported)
Implementation Checklist
- Configure formatter with config file committed
- Set up linter with strict rules
- Enable all MUST lint categories
- Configure unsafe code warnings
- Establish error handling patterns
- Document all public APIs
- Add CI checks for formatting and linting
Compliance Verification
# Verify formatting passes
make format-check
# Verify linting passes (strict)
make lint-strict
# Check for unsafe code (Rust example)
grep -r "unsafe" src/ --include="*.rs"
# Verify doc coverage (language-specific)
cargo doc --no-deps # Rust
Additional Resources
Reference Files
-
references/linter-configs.md- Comprehensive linter configurations -
references/error-patterns.md- Error handling patterns by language
Examples
-
examples/clippy.toml- Rust Clippy configuration -
examples/eslint.config.js- TypeScript ESLint configuration -
examples/pyproject-ruff.toml- Python Ruff configuration
chat Comments (0)
Sign in to join the discussion and leave a comment.
Skill Details
Related Skills
Build your own?
Join 12,000+ developers contributing to the Claude ecosystem.
No comments yet. Be the first to share your thoughts!