coding-standards

name	coding-standards
description	コーディング規約とベストプラクティスを適用するスキル。コードレビューやコード生成時に参照される。
metadata	{"short-description":"コーディング規約の適用"}

Coding Standards

Code Style

• Prefer immutability: use spread operators, map/filter/reduce instead of mutating operations
• File size: 200-400 lines recommended, 800 lines max
• Function size: 20 lines recommended, 50 lines max
• Use early returns to reduce nesting depth
• One file, one responsibility (Single Responsibility Principle)
• Group imports at the top of the file
• Use explicit exports; avoid barrel export overuse

Naming

• Names must accurately describe purpose
• Abbreviations allowed only for common terms: id, url, config
• Booleans: prefix with is/has/can/should
• Collections: use plural forms (users, items)

Error Handling

• Never use empty catch blocks (silent catch) -- always log or rethrow
• Always catch errors at external boundaries (API calls, DB operations, file I/O)
• Include "what happened" and "what was expected" in error messages
• Distinguish recoverable from unrecoverable errors

Input Validation

• Always validate user input
• Validate at system boundaries (API endpoints, CLI arguments)
• Avoid over-validation between internal trusted functions

Testing

• Follow TDD: RED (failing test) -> GREEN (minimal implementation) -> REFACTOR
• Line coverage: 80% minimum
• Test behavior, not implementation details
• Mocks are limited to external dependencies (API, DB) only
• Test names should state: what, under which condition, expected result
• Tests must be independent and executable in isolation

Prohibited Patterns

• any type abuse -- use proper types or generics
• Magic numbers -- define named constants
• Nesting 3+ levels deep -- use early return, guard clauses, or extract functions
• Copy-paste code -- extract shared logic
• Functions with 5+ parameters -- use object arguments or builder pattern
• God classes/modules -- split by responsibility
• Mutating global state -- use dependency injection
• Code without tests -- always write tests first

Git

• Use Conventional Commits: feat: / fix: / refactor: / test: / docs: / chore:

Security

• Never hardcode secrets (API keys, passwords, tokens)
• Use parameterized queries for SQL (no string concatenation)
• Escape HTML output to prevent XSS
• Apply path traversal protection on file paths
• Lock dependency versions and audit regularly