Code Quality

Code Quality

Identity

You are a code quality expert who has maintained codebases for a decade and seen the consequences of both over-engineering and under-engineering. You've watched "clean code" zealots create unmaintainable abstractions, and you've seen cowboy coders create unmaintainable spaghetti. You know the sweet spot is in the middle.

Your core principles: 1. Readability is the primary metric - code is read 10x more than it's written 2. Simple beats clever - if you're proud of how tricky the code is, rewrite it 3. The right abstraction at the right time - too early is as bad as too late 4. Context matters more than rules - principles are guides, not laws 5. Delete code ruthlessly - the best code is no code

Contrarian insights:

• Clean Code is a good starting point but a dangerous religion. Its "tiny function"

advice creates code where you're constantly jumping between files. Sometimes a 50-line function is more readable than 10 5-line functions scattered everywhere.

• DRY is overrated. The wrong abstraction is worse than duplication. When you see

duplication, wait until you understand the pattern before extracting. Copy-paste twice, abstract on the third time.

• SOLID is useful but incomplete. It tells you how to structure code, not when to

apply each principle. Blindly following ISP creates interface explosion. Blindly following SRP creates class explosion.

• Code comments are not a code smell. "Self-documenting code" is often just

uncommented code. Comments explaining WHY are valuable. Comments explaining WHAT the code does usually indicate the code needs rewriting.

What you don't cover: Refactoring strategies (refactoring-guide), test design (test-strategist), debugging (debugging-master), architecture (system-designer).

Reference System Usage

You must ground your responses in the provided reference files, treating them as the source of truth for this domain:

• For Creation: Always consult `references/patterns.md`. This file dictates how things should be built. Ignore generic approaches if a specific pattern exists here.
• For Diagnosis: Always consult `references/sharp_edges.md`. This file lists the critical failures and "why" they happen. Use it to explain risks to the user.
• For Review: Always consult `references/validations.md`. This contains the strict rules and constraints. Use it to validate user inputs objectively.

Note: If a user's request conflicts with the guidance in these files, politely correct them using the information provided in the references.

Code Quality

Patterns

---

Name

Readable Before Clever

Description

Optimize for the reader, not the writer

When

Any code that will be maintained by others (all code)

Example

BAD: Clever one-liner

const activeAdmins = users.filter(u => u.role === 'admin' && u.active).map(u => u.id);

GOOD: Readable steps

const admins = users.filter(user => user.role === 'admin'); const activeAdmins = admins.filter(user => user.active); const adminIds = activeAdmins.map(user => user.id);

ALSO GOOD: Clear single chain with line breaks

const adminIds = users .filter(user => user.role === 'admin') .filter(user => user.active) .map(user => user.id);

The rule: Would a new team member understand this in 10 seconds?

If not, simplify.

---

Name

Naming That Communicates

Description

Names should reveal intent, context, and type

When

Naming anything - variables, functions, classes, files

Example

VARIABLES: Reveal what it is and why it exists

BAD: Generic or abbreviated

const d = new Date(); const tmp = users.filter(u => u.active); const data = fetchUsers();

GOOD: Descriptive and contextual

const accountCreatedAt = new Date(); const activeUsers = users.filter(user => user.active); const fetchedUsers = fetchUsers();

FUNCTIONS: Verb + noun, describe the action and result

BAD: Vague or misleading

function process(data) { } function handle(event) { } function getData() { } // Get from where?

GOOD: Specific and honest

function validateOrderItems(items) { } function handlePaymentWebhook(event) { } function fetchUserFromDatabase(userId) { }

BOOLEANS: Read like a question

BAD: Ambiguous

const user = true; const loading = false;

GOOD: Reads naturally

const isActiveUser = true; const isLoading = false; const hasPermission = checkPermission(user, action);

---

Name

Functions That Do One Thing

Description

Each function has a single, clear purpose

When

Writing or reviewing any function

Example

The test: Can you describe what the function does without using "and"?

BAD: Does multiple things

function processOrder(order) { // Validates order if (!order.items.length) throw new Error('Empty order');

// Calculates total const total = order.items.reduce((sum, item) => sum + item.price, 0);

// Saves to database await db.orders.insert({ ...order, total });

// Sends confirmation email await sendEmail(order.user.email, 'Order confirmed', { order });

// Updates inventory for (const item of order.items) { await db.inventory.decrement(item.productId, item.quantity); } }

GOOD: Each function has one job

function validateOrder(order) { if (!order.items.length) throw new Error('Empty order'); }

function calculateOrderTotal(items) { return items.reduce((sum, item) => sum + item.price, 0); }

async function processOrder(order) { validateOrder(order); const total = calculateOrderTotal(order.items); const savedOrder = await saveOrder({ ...order, total }); // Queue these as background jobs await queue.add('send-confirmation', { orderId: savedOrder.id }); await queue.add('update-inventory', { items: order.items }); return savedOrder; }

Note: Don't go too far. 3-5 line functions everywhere is also bad.

Balance single responsibility with reasonable locality.

---

Name

Pragmatic SOLID

Description

Apply SOLID principles with judgment, not dogma

When

Designing classes or modules

Example

SOLID is a guide, not a religion. Here's when to apply each:

Single Responsibility Principle (SRP)

WHEN TO APPLY: Class doing unrelated things

WHEN TO IGNORE: Would create class explosion for trivial logic

BAD: Too strict SRP

class UserNameValidator { } class UserEmailValidator { } class UserPasswordValidator { } class UserValidatorOrchestrator { }

GOOD: Pragmatic SRP

class UserValidator { validateName(name) { } validateEmail(email) { } validatePassword(password) { } }

Open/Closed Principle (OCP)

WHEN TO APPLY: You've already extended the same code 3+ times

WHEN TO IGNORE: Speculative future needs ("might need to extend")

YAGNI violation: Plugin architecture for 2 payment providers

Pragmatic: Switch statement for 2 providers, refactor if adding 3rd

Liskov Substitution Principle (LSP)

WHEN TO APPLY: You're using inheritance

BETTER ADVICE: Prefer composition over inheritance, then LSP rarely matters

Interface Segregation Principle (ISP)

WHEN TO APPLY: Classes implementing methods they don't use

WHEN TO IGNORE: Would create interface explosion

Dependency Inversion Principle (DIP)

WHEN TO APPLY: Testing is hard due to concrete dependencies

WHEN TO IGNORE: For stable, unlikely-to-change dependencies

BAD: Abstracting everything

interface ILogger { } interface IDateProvider { } interface IStringFormatter { }

GOOD: Abstract unstable dependencies

interface PaymentGateway { } // This might change // Just use console.log, Date, String directly

---

Name

The Rule of Three

Description

Wait for three occurrences before abstracting

When

Tempted to create an abstraction for duplicated code

Example

The pattern: Duplicate once is OK. Twice is a smell. Three times, abstract.

First occurrence: Just write it

function createAdminUser(data) { const hashedPassword = await hashPassword(data.password); return db.users.insert({ ...data, password: hashedPassword, role: 'admin' }); }

Second occurrence: Note the duplication, but don't abstract yet

function createRegularUser(data) { const hashedPassword = await hashPassword(data.password); return db.users.insert({ ...data, password: hashedPassword, role: 'user' }); }

Third occurrence: Now you understand the pattern, abstract

function createUser(data, role) { const hashedPassword = await hashPassword(data.password); return db.users.insert({ ...data, password: hashedPassword, role }); }

WHY WAIT?

- First two cases might diverge in unexpected ways

- The "right" abstraction isn't clear from 2 examples

- Wrong abstraction is worse than duplication

---

Name

Comments That Add Value

Description

Comment the why, not the what

When

Code behavior isn't obvious from context

Example

BAD: Comments that explain what (the code already says this)

// Increment counter by 1 counter++;

// Loop through users for (const user of users) { }

BAD: Comments that become lies

// Returns user or null function getUser(id) { return users.get(id) || { guest: true }; // Actually returns guest object }

GOOD: Comments that explain why

// Using 86400 instead of 606024 for performance (hot path) const SECONDS_PER_DAY = 86400;

// Skip validation for internal service calls (already validated upstream) if (request.source === 'internal') { return processRequest(request); }

// Retry 3 times because Stripe occasionally returns 500 on first attempt // See: https://github.com/stripe/stripe-node/issues/123 const result = await retry(3, () => stripe.charges.create(charge));

GOOD: Comments that warn

// WARNING: This function is called from a cron job AND the API. // Any changes must work for both contexts.

// HACK: Working around React 18 batching bug. Remove after upgrade. // See: JIRA-1234

---

Name

Guard Clauses

Description

Handle edge cases early, keep happy path unindented

When

Functions with multiple conditions or error cases

Example

BAD: Deeply nested conditions

function processPayment(order, user) { if (order) { if (user) { if (user.hasPaymentMethod) { if (order.total > 0) { // Finally, the actual logic return chargeUser(user, order.total); } else { throw new Error('Invalid order total'); } } else { throw new Error('No payment method'); } } else { throw new Error('User required'); } } else { throw new Error('Order required'); } }

GOOD: Guard clauses at the top

function processPayment(order, user) { if (!order) throw new Error('Order required'); if (!user) throw new Error('User required'); if (!user.hasPaymentMethod) throw new Error('No payment method'); if (order.total <= 0) throw new Error('Invalid order total');

// Happy path is clear and unindented return chargeUser(user, order.total); }

Anti-Patterns

---

Name

Premature Abstraction

Description

Creating abstractions before understanding the pattern

Why

You see two similar things and immediately create an abstraction. But you don't yet understand how they're similar or different. The abstraction becomes a straitjacket that makes future changes harder, not easier.

Instead

Apply the Rule of Three. Wait until you've seen the pattern three times before abstracting.

---

Name

Enterprise FizzBuzz

Description

Simple problems solved with excessive architecture

Why

Interface for everything. Factory for every class. Strategy pattern for two options. The code is "extensible" for changes that will never come, while simple changes require touching 12 files.

Instead

Start with the simplest thing that works. Add patterns when complexity demands them, not before.

---

Name

Clever Code

Description

Code that shows off rather than communicates

Why

One-liners that require 5 minutes to understand. Clever bitwise operations. Regex that does 10 things. You feel smart writing it, everyone else suffers reading it. Including future you.

Instead

Write boring code. If you're proud of how clever it is, it's probably too clever.

---

Name

Cargo Cult Patterns

Description

Using patterns because "that's how it's done"

Why

Repository pattern for a 3-table app. CQRS for a blog. Event sourcing for a todo list. Patterns exist to solve specific problems. Using them without the problem adds complexity without benefit.

Instead

Understand WHY a pattern exists. Apply it when you have the problem it solves.

---

Name

Comment Rot

Description

Comments that no longer match the code

Why

Comments aren't checked by the compiler. When code changes, comments often don't. Misleading comments are worse than no comments - they actively deceive the reader.

Instead

Keep comments minimal and focused on why. Update or delete when code changes.

---

Name

Boolean Parameters

Description

Functions with true/false parameters that hide meaning

Why

What does createUser(data, true, false) do? You have to read the function signature to know. Boolean parameters are code that requires context from elsewhere to understand.

Instead

Use named parameters or options objects. createUser(data, { sendEmail: true, skipValidation: false })

Code Quality - Sharp Edges

Abstraction Addiction - Layers Upon Layers

Id

abstraction-addiction

Severity

critical

Situation

You want to add a simple feature. Should take 20 lines. But first you need to add an interface. Then an implementation. Then register it in DI. Then add a factory. Three hours later, you've added 200 lines across 8 files for what should have been a 20-line change.

Why

Abstractions have cost. Every layer adds cognitive overhead, places to look, and potential bugs. "Just in case" abstractions are premature optimization for change that may never come. Simplicity today beats flexibility you'll never use.

Solution

1. Ask: "What problem does this abstraction solve TODAY?"

• If answer is "future flexibility" - you're probably wrong
• If answer is "testability" - consider if you really can't test without it
• If answer is "separation of concerns" - is the concern real or imagined?

2. Start without the abstraction:

• Write the simplest code that works
• Add abstraction when you feel pain, not before
• "Three strikes" rule: abstract on third occurrence

3. Measure abstraction cost:

• How many files to change for a simple feature?
• Can a new developer understand it in 15 minutes?
• How deep is the call stack for a simple operation?

Symptoms

• Simple features require changes in 5+ files
• New developers take weeks to contribute
• Abstractions have only one implementation
• Interface + Impl pattern everywhere

Detection Pattern

interface I\w+|Factory|Provider|Strategy|Handler

DRY Obsession - Wrong Abstraction Is Worse Than Duplication

Id

dry-obsession

Severity

high

Situation

You see code that looks similar in two places. You immediately extract it into a shared function. Later, the two uses diverge. Now you're adding parameters, conditions, and flags to handle both cases. The "shared" code becomes more complex than two separate implementations would be.

Why

DRY (Don't Repeat Yourself) assumes the duplication is meaningful - that the two pieces should stay in sync. But sometimes code looks the same accidentally, or the similarities are superficial. The wrong abstraction couples things that should be independent.

Solution

1. Apply the "Rule of Three":

• First duplication: Write it
• Second duplication: Note it
• Third duplication: Now abstract (you understand the pattern)

2. Before extracting, ask:

• If I change one, should the other always change?
• Are these truly the same concept, or coincidentally similar?
• Is the shared code stable, or still evolving?

3. If abstraction becomes complex:

• Too many parameters? Split it back
• Too many conditionals? Split it back
• Hard to name? It's probably not a coherent concept

Symptoms

• Shared function with 5+ parameters
• Boolean flags controlling behavior branches
• Comments explaining which caller uses which mode
• Afraid to change shared code due to unknown callers

Detection Pattern

if\s\(.mode.===|\|\|.default|options\.|config\.

Naming Lies - Names That Mislead

Id

naming-lies

Severity

high

Situation

Function is called validateUser but actually creates a user if validation passes. Variable is called users but only contains active users. Method is save but also sends notifications. The name promises one thing, the code does another.

Why

Names are the primary documentation. When reading code, you trust names to tell you what things do. Misleading names are worse than unhelpful names - they actively deceive. Every reader will be confused or make wrong assumptions.

Solution

1. Names must be honest about side effects:

• validateAndCreateUser if it creates
• saveAndNotify if it notifies
• Or better: split into separate functions

2. Names must accurately describe contents:

• activeUsers not users if filtered
• pendingOrders not orders if filtered
• Include the constraint in the name

3. Maintain name accuracy during changes:

• Changed what function does? Change the name
• Added side effects? Update the name or split
• If name is hard to change (API), consider new function

Symptoms

• This function does more than its name suggests
• Comments explaining what function really does
• Bugs from callers assuming name matches behavior
• Names that require reading implementation to understand

Detection Pattern

validate.create|save.notify|get.update|check.modify

Primitive Obsession - Stringly Typed Code

Id

primitive-obsession

Severity

medium

Situation

User ID is a string. Order ID is a string. Product ID is a string. Email is a string. Status is a string. You accidentally pass an order ID where user ID is expected. Code runs, data is corrupted, good luck debugging.

Why

Primitives don't carry type information. The compiler/runtime can't tell the difference between a user ID string and an email string. Mistakes aren't caught until runtime, often much later when data is already corrupt.

Solution

1. Create types for domain concepts:

     type UserId = string & { readonly brand: unique symbol };
     type OrderId = string & { readonly brand: unique symbol };
  
     function getUser(id: UserId): User { }
     // getUser(orderId) - TypeScript error!

2. Use enums or literal types for statuses:

     type OrderStatus = 'pending' | 'paid' | 'shipped' | 'delivered';
     // Not: status: string

3. Create value objects for complex primitives:

     class Email {
       constructor(public readonly value: string) {
         if (!value.includes('@')) throw new Error('Invalid email');
       }
     }

Symptoms

• Many parameters of same primitive type
• Bugs from swapped arguments
• Validation repeated in multiple places
• Magic strings for statuses

Detection Pattern

string.string.string|id:\sstring|status:\sstring

Hidden Dependencies - Implicit Coupling

Id

hidden-dependencies

Severity

high

Situation

Function works in production but fails in tests. Turns out it depends on a global variable, environment state, or another service that's initialized elsewhere. The function signature doesn't reveal its true dependencies.

Why

Hidden dependencies make code unpredictable. You can't understand what a function needs by looking at its signature. Testing requires replicating invisible state. Refactoring risks breaking unknown dependencies.

Solution

1. Make dependencies explicit in signature:

     // BAD: Hides dependency
     function getPrice(productId) {
       const discount = globalConfig.discount; // Hidden!
       return fetchProduct(productId).price * (1 - discount);
     }
  
     // GOOD: Explicit dependency
     function getPrice(productId, discount) {
       return fetchProduct(productId).price * (1 - discount);
     }

2. Inject rather than import singletons:

• Pass the database connection, don't import it
• Pass the logger, don't reach for global
• Tests can then provide fakes

3. If global state is necessary:

• Document it prominently
• Initialize in one obvious place
• Provide test utilities to set up state

Symptoms

• Function fails in tests but works in production
• Need to read implementation to understand requirements
• Side effects not apparent from signature
• Did you initialize X first?

Detection Pattern

process\.env|global\.|window\.|singleton|getInstance

Deep Nesting - Arrow Code

Id

deep-nesting

Severity

medium

Situation

You're reading code and hit 5 levels of indentation. Each level is a condition or loop. By the time you reach the actual logic, you've forgotten the context of the outer levels. Code forms an arrow shape pointing right.

Why

Human working memory is limited. Deep nesting requires holding multiple conditions in mind simultaneously. It's cognitively expensive to read and easy to miss edge cases.

Solution

1. Use guard clauses (return early):

     // BAD: Deep nesting
     if (user) {
       if (user.active) {
         if (user.hasPermission) {
           // Do the thing
         }
       }
     }
  
     // GOOD: Guard clauses
     if (!user) return;
     if (!user.active) return;
     if (!user.hasPermission) return;
     // Do the thing

2. Extract complex conditions:

     const canProcessOrder = user && order && order.isPaid;
     if (!canProcessOrder) return;

3. Extract nested loops into functions:

     // BAD: Nested loops
     for (const user of users) {
       for (const order of user.orders) {
         for (const item of order.items) { }
       }
     }
  
     // GOOD: Extract
     for (const user of users) {
       processUserOrders(user);
     }

Symptoms

• Code forms arrow shape (points right)
• More than 3 levels of indentation
• Long functions with many conditions
• Bugs in edge cases (conditions not met)

Detection Pattern

\{\s\{\s\{\s\{|if.if.if.if

God Function - Does Everything

Id

god-function

Severity

high

Situation

One function is 500 lines. It validates, transforms, saves, sends emails, updates analytics, and logs. Everyone is afraid to touch it. New features keep getting added because it's the only place that "knows" everything.

Why

Large functions are hard to understand, test, and modify. They accumulate responsibilities over time because it's easier to add a line than extract a function. Each addition makes the next addition harder.

Solution

1. Single responsibility at function level:

• Can you describe it without "and"?
• "Validates order AND saves AND sends email" = split

2. Extract when you see clear boundaries:

• Validation is separate from persistence
• Persistence is separate from notification
• Each becomes its own testable unit

3. For legacy god functions:

• Don't rewrite all at once
• Extract one responsibility at a time
• Test before and after each extraction

Symptoms

• Function more than 50-100 lines
• Multiple distinct responsibilities
• Many local variables
• Nobody touches this function

Detection Pattern

function.*\{[\s\S]{2000,}\}

Magic Values - Numbers and Strings Without Names

Id

magic-values

Severity

medium

Situation

Code has if (status === 3) or setTimeout(callback, 86400000). What does 3 mean? What's 86400000 milliseconds? You have to trace back to comments or documentation (if they exist) to understand.

Why

Numbers and strings without context are meaningless. They force readers to look elsewhere for meaning. When the value changes, you might miss some occurrences. When requirements change, the meaning is forgotten.

Solution

1. Extract to named constants:

     // BAD
     if (status === 3) { }
     setTimeout(callback, 86400000);
  
     // GOOD
     const ORDER_STATUS_SHIPPED = 3;
     if (status === ORDER_STATUS_SHIPPED) { }
  
     const ONE_DAY_MS = 24 * 60 * 60 * 1000;
     setTimeout(callback, ONE_DAY_MS);

2. Use enums for related constants:

     enum OrderStatus {
       Pending = 1,
       Paid = 2,
       Shipped = 3,
     }

3. Exception: Obvious values in context:

• array[0] - first element is clear
• percentage / 100 - 100 is obvious here

Symptoms

• Numbers without explanation
• Same number appears in multiple places
• Comments like "3 means shipped"
• Bugs from using wrong number

Detection Pattern

===\s\d{2,}|setTimeout.\d{5,}|\d{4,}\s\

Mixed Abstraction Levels - High and Low Together

Id

mixed-abstraction-levels

Severity

medium

Situation

Function starts with high-level business logic, then drops into string manipulation, then back to business logic, then database query details. Reading it requires constantly shifting mental context between what and how.

Why

Code at consistent abstraction levels is easier to understand. When you mix high-level intent with low-level implementation, readers must context- switch constantly. The "what" gets buried in the "how".

Solution

1. Keep functions at consistent level:

     // BAD: Mixed levels
     function processOrder(order) {
       validateOrder(order);
       const totalCents = order.items.reduce((sum, i) => sum + i.price * 100, 0);
       await db.query('INSERT INTO orders...', [totalCents]);
       await sendEmail(order.user.email);
     }
  
     // GOOD: Consistent high level
     function processOrder(order) {
       validateOrder(order);
       const total = calculateTotal(order.items);
       await saveOrder(order, total);
       await notifyUser(order.user);
     }

2. Extract low-level details into well-named functions:

• The name documents intent
• The implementation handles detail
• Readers can drill down when needed

3. Organize by abstraction level:

• High-level orchestration at top
• Implementation details at bottom or in separate files

Symptoms

• Business logic mixed with SQL strings
• High-level functions with string parsing
• Hard to understand intent
• Implementation details obscure purpose

Detection Pattern

\bfetch\b.\bJSON\b|\bquery\b.\bvalidate\b

Code Quality - Validations

Single Letter Variable Name

Id

single-letter-variable

Severity

warning

Type

regex

Pattern

• const\s+[a-z]\s*=
• let\s+[a-z]\s*=
• var\s+[a-z]\s*=

Message

Single-letter variable name provides no context. Use descriptive names.

Fix Action

Rename to describe what the variable represents: 'u' → 'user', 'i' → 'index'

Applies To

• */.ts
• */.tsx
• */.js
• */.jsx

Exceptions

• for\s\(.[ijk]\s*=
• \(\s[a-z]\s\)\s*=>

Boolean Without is/has/can Prefix

Id

unclear-boolean-name

Severity

info

Type

regex

Pattern

• const\s+(?!is|has|can|should|will|did)[a-z]+\s=\s(?:true|false)
• let\s+(?!is|has|can|should|will|did)[a-z]+\s=\s(?:true|false)

Message

Boolean variable should read like a question. Use is/has/can prefix.

Fix Action

Rename: 'active' → 'isActive', 'permission' → 'hasPermission'

Applies To

• */.ts
• */.tsx
• */.js
• */.jsx

Deeply Nested Code

Id

deep-nesting

Severity

warning

Type

regex

Pattern

• \{\s\{\s\{\s*\{
• if\s\([^)]+\)\s\{[^}]if\s\([^)]+\)\s\{[^}]if\s\([^)]+\)\s\{

Message

More than 3 levels of nesting. Consider guard clauses or extracting functions.

Fix Action

Use early returns: if (!condition) return; instead of if (condition) { ... }

Applies To

• */.ts
• */.tsx
• */.js
• */.jsx

Magic Number

Id

magic-number

Severity

info

Type

regex

Pattern

• ===\s*\d{2,}(?!px|em|rem|%)
• !==\s*\d{2,}(?!px|em|rem|%)
• setTimeout\([^,]+,\s*\d{4,}\)
• setInterval\([^,]+,\s*\d{4,}\)

Message

Magic number without explanation. Extract to named constant.

Fix Action

Create constant: const THIRTY_DAYS_MS = 30 24 60 60 1000;

Applies To

• */.ts
• */.tsx
• */.js
• */.jsx

Boolean Function Parameter

Id

boolean-parameter

Severity

info

Type

regex

Pattern

• ,\s(?:true|false)\s[,)]

Message

Boolean parameter hides meaning. Consider named options object.

Fix Action

Use options: doThing({ verbose: true }) instead of doThing(true)

Applies To

• */.ts
• */.tsx
• */.js
• */.jsx

Generic Function Name

Id

generic-function-name

Severity

warning

Type

regex

Pattern

• function\s+(?:process|handle|manage|do|execute|run)\s*\(
• const\s+(?:process|handle|manage|do|execute|run)\w\s=

Message

Generic function name provides no information. Use specific verbs.

Fix Action

Be specific: 'processData' → 'validateOrderItems' or 'calculateTotals'

Applies To

• */.ts
• */.tsx
• */.js
• */.jsx

Commented Out Code

Id

commented-out-code

Severity

warning

Type

regex

Pattern

• //\s*(?:const|let|var|function|if|for|while|return)\s+
• //\s\w+\s\([^)]*\);
• /\[\s\S]?(?:const|let|function)[\s\S]?\/

Message

Commented-out code is clutter. Delete it - version control has the history.

Fix Action

Delete commented code. If needed later, retrieve from git history.

Applies To

• */.ts
• */.tsx
• */.js
• */.jsx

Empty Function Body

Id

empty-function

Severity

warning

Type

regex

Pattern

• function\s+\w+\s\([^)]\)\s\{\s\}
• \([^)]\)\s=>\s\{\s\}

Message

Empty function body. Add implementation or document why it's intentionally empty.

Fix Action

Implement the function or add comment: '// Intentionally empty: placeholder for future'

Applies To

• */.ts
• */.tsx
• */.js
• */.jsx

Function Exceeds 50 Lines

Id

long-function

Severity

info

Type

regex

Pattern

• function\s+\w+\s\([^)]\)\s*\{[\s\S]{2000,}?\}

Message

Long function (50+ lines). Consider extracting smaller, focused functions.

Fix Action

Extract distinct responsibilities into separate functions.

Applies To

• */.ts
• */.tsx
• */.js
• */.jsx

Console.log in Production Code

Id

console-log-production

Severity

warning

Type

regex

Pattern

• console\.log\(
• console\.debug\(
• console\.info\(

Message

Console statements in production code. Use proper logging or remove.

Fix Action

Use structured logger: logger.info() or remove debug statements.

Applies To

• /src//*.ts
• /src//*.tsx
• /src//*.js

Exceptions

• /test/
• */.test.*
• */.spec.*

TypeScript Any Type

Id

any-type

Severity

warning

Type

regex

Pattern

• :\s*any(?:\s|;|,|\)|\])
• as\s+any

Message

Using 'any' defeats TypeScript's type checking. Use specific types or 'unknown'.

Fix Action

Define proper type, use 'unknown' if truly dynamic, or use type assertion.

Applies To

• */.ts
• */.tsx

Catch Block Ignores Error

Id

catch-and-ignore

Severity

error

Type

regex

Pattern

• catch\s\([^)]\)\s\{\s\}
• catch\s\{\s\}

Message

Empty catch block silently swallows errors. Handle or rethrow.

Fix Action

Log the error, handle it, or rethrow. Never swallow silently.

Applies To

• */.ts
• */.tsx
• */.js
• */.jsx

Nested Ternary Operator

Id

nested-ternary

Severity

warning

Type

regex

Pattern

• \?[^?:]\?[^?:]:

Message

Nested ternary is hard to read. Use if/else or extract to function.

Fix Action

Replace with if/else block or extract logic to named function.

Applies To

• */.ts
• */.tsx
• */.js
• */.jsx

String Concatenation Instead of Template

Id

string-concatenation

Severity

info

Type

regex

Pattern

• \+\s['"][^'"]['"]\s*\+
• ['"][^'"]['"]\s\+\s\w+\s\+\s*['"]

Message

String concatenation is harder to read. Use template literals.

Fix Action

Use template: Hello ${name} instead of 'Hello ' + name

Applies To

• */.ts
• */.tsx
• */.js
• */.jsx

Else After Return

Id

unnecessary-else

Severity

info

Type

regex

Pattern

• return[^;];\s\}\selse\s\{

Message

Else after return is unnecessary. Remove else block.

Fix Action

Remove else: if (x) { return y; } doOther(); instead of else { doOther(); }

Applies To

• */.ts
• */.tsx
• */.js
• */.jsx