code-quality-foundations

스타0

포크0

업데이트2026년 2월 24일 06:45

Code quality pillars, goals, abstraction layers, and tradeoff thinking. Use when evaluating code quality, setting quality goals, choosing abstraction levels, making design tradeoffs, or auditing code against quality pillars. Covers readability, modularity, testability, reusability, and the principle of least astonishment.

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

출처

smileynet

smileynet/code-spice

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Code Quality Foundations

The Four Goals of High-Quality Code

Goal	Question to Ask	Failure Mode
It works	Does it solve the problem correctly?	Bugs, unhandled edge cases, unmet requirements
It keeps working	Will it survive changes around it?	Brittle dependencies, no tests, hidden assumptions
It's adaptable	Can requirements change without a rewrite?	Rigid coupling, over-engineering, hardcoded assumptions
It doesn't reinvent the wheel	Are we reusing proven solutions?	Custom code for solved problems, duplicated effort

The Six Pillars of Code Quality

Pillar	What It Means	Key Technique
Readable	Other engineers can understand it quickly	Descriptive names, clean layers, consistent style
No surprises	Behavior matches expectations (POLA)	Explicit contracts, no magic values, no hidden side effects
Hard to misuse	Difficult to use incorrectly	Type safety, immutability, validated construction
Modular	Components can be swapped independently	Interfaces, DI, separation of concerns, cohesion
Reusable & generalizable	Solves problems broadly, not just one case	Focused parameters, generics, avoiding assumptions
Testable	Can be verified in isolation	Modularity enables testability; design for it from the start

POLA = Principle of Least Astonishment. If a function does something a reasonable caller wouldn't expect, it's a bug in the design, even if it "works."

Modern Additions (2024-2026 Industry Consensus)

Concern	Why It's Now Explicit	Original Coverage
Secure	Shift-left security; threat model at design time	Implicit in "works"
Efficient	Resource optimization is a design choice, not afterthought	Subsumed under "works"
Reliable	Explicit error recovery and graceful degradation	Subsumed under "keeps working"

Decision Tables

"Should I Abstract This?"

Signal	Action
Same logic appears in 2+ places	Extract to shared function/class
Function can't be described in one sentence	Split into smaller functions
Class has method groups that use different fields	Consider splitting into separate classes
Changing one feature requires touching many files	Improve modularity and layer boundaries
Only one use case exists	Wait — don't abstract prematurely

"Where Should I Invest Quality Effort?"

Situation	Focus On	Rationale
Greenfield project	Modularity, clean interfaces	Foundation decisions compound; structure early
Legacy codebase	Testing, readability	Understand before changing safely
High-traffic service	Reliability, efficiency, testing	Production failures are expensive
Prototype / spike	Working code, speed	Validate the idea; plan to rewrite
Shared library / API	Hard to misuse, no surprises	You can't predict how consumers will use it
Security-sensitive code	Security, testability	Breaches are catastrophic and trust-destroying

Checklists

Before Writing Code

Problem clearly understood (requirements, constraints, edge cases)
Existing solutions checked (libraries, shared code, prior art)
Testing strategy considered (how will this be verified?)
Key tradeoffs identified (what are we choosing, and what are we giving up?)

Code Quality Self-Review

Functions translate to single sentences
No surprises: behavior matches names and types
Hard to misuse: invalid states are unrepresentable where possible
Modular: changes are localized, not scattered
Testable: can be unit tested without complex setup
Clean abstractions: API doesn't leak implementation details

이 저장소의 다른 Skills

같은 저장소

code-antipatterns

smileynet/code-spice

Antipattern catalog with categorized patterns, symptoms, examples, and fixes. Use when reviewing code for quality issues, detecting bad patterns during plan-audit or scope, evaluating whether a pattern is an antipattern or acceptable tradeoff, or fixing existing code smells. Covers surprise, misuse, complexity, and premature antipattern categories with severity classification.

2026-02-240

code-naming

smileynet/code-spice

Naming decisions for variables, functions, classes, constants, and APIs. Use when choosing names, reviewing naming quality, refactoring unclear names, or establishing naming conventions. Covers descriptive naming, naming as documentation, language-specific conventions, and common naming antipatterns.

2026-02-240

code-plan-audit

smileynet/code-spice

Plan quality auditing with completeness scorecard, antipattern risk detection, and readiness checks. Use when auditing implementation plans, evaluating plan completeness, checking error handling strategy, assessing naming and readability pre-checks, reviewing testing strategy, evaluating tradeoff documentation, or running plan-audit on a software project. Covers the 10-point completeness scorecard, code quality pre-checks, antipattern risk assessment, and build-readiness decision.

2026-02-240

code-pruning

smileynet/code-spice

Dead code detection strategies, safe removal processes, dependency pruning, and bloat metrics for systematically reducing codebase dead weight. Use when evaluating codebase health during architecture-audit, performing cleanup during cook, reviewing unused dependencies, removing commented-out code, or measuring code bloat.

2026-02-240

code-readability

smileynet/code-spice

Code readability patterns covering comments, function decomposition, nesting, naming conventions, and code structure. Use when evaluating whether code is easy to understand, deciding when and how to write comments, decomposing functions, reducing nesting depth, improving code structure, or reviewing code for readability. Covers comment strategy, function length, abstraction level mixing, nesting reduction, anonymous function readability, and making bad code visually obvious.

2026-02-240

code-review

smileynet/code-spice

Code review process, effective feedback, PR best practices, team working agreements, review automation, AI-augmented review, and review antipatterns. Use when reviewing code, preparing PRs, giving review feedback, setting up review processes, writing review comments, or conducting code reviews during serve phase.

2026-02-240

name	code-quality-foundations
description	Code quality pillars, goals, abstraction layers, and tradeoff thinking. Use when evaluating code quality, setting quality goals, choosing abstraction levels, making design tradeoffs, or auditing code against quality pillars. Covers readability, modularity, testability, reusability, and the principle of least astonishment.