# Rubric: L-CODE-QUALITY

**Lens:** `L-CODE-QUALITY` · **Density:** split D-HIGH / D-LOW · **Axes:** RDB, MNT

## D-HIGH (exhaustive)

Scan for discrete defects within scope:

- Magic numbers / unexplained literals (where constants or enums should exist)  
- Hardcoded secrets/credentials patterns  
- Banned/dangerous APIs (language-specific lists in adapters)  
- Inconsistent error-return conventions **when a dominant convention is detectable**  
- Dead/commented-out code blocks of material size  
- Copy-paste clones of non-trivial logic (rule of three)

## D-LOW (Top N)

- Naming clarity and ubiquitous language drift  
- File/module size outliers  
- Style inconsistency that impedes review (not formatter noise)

## Citations

| Work | Point |
|------|-------|
| Robert C. Martin — *Clean Code* | Meaningful names; small functions (use carefully; not dogma) |
| Josh Bloch — *Effective Java* | Prefer clear APIs; avoid public fields; builder where needed (if Java) |
| Google style guides / Effective Go | Language idioms |
| CISQ / ISO 5055 automated source measures | Reliability/security/maintainability weakness categories (conceptual) |

## Pros / cons

| Pros | Cons |
|------|------|
| Exhaustive literal/secret scans are high-signal | Clean Code absolutism causes false severity — adversarial must downgrade |
| Separates mechanical from philosophical | Clone detection without tooling is approximate |

## Pros of recommending constants for magic values

Reduces drift and review load (**MNT**). **Con:** over-constanting one-use literals adds indirection — require second occurrence or domain meaning before finding severity ≥ moderate.