Simplify complex code while preserving exact behavior

Code Simplification reduces implementation complexity while preserving exact behavior. Its success criterion is whether a new teammate would understand the result faster. Fewer lines alone do not establish an improvement. Inputs, outputs, edge cases, error behavior, side effects, and their ordering must remain identical.

The process begins with understanding the code's responsibility, callers, dependencies, tests, and historical constraints. Read project conventions and neighboring implementations before editing. Git blame can explain why an apparently unnecessary structure exists. If its purpose or behavior is unclear, gather more context before removing it.

Five principles guide the work: preserve behavior, follow project conventions, choose clarity over cleverness, avoid over-simplification, and scope changes to recently modified code. Helpers that name a useful concept and abstractions that support testability or extensibility deserve consideration before inlining. Combining unrelated functions can make a system harder to follow even when it reduces repetition.

Use after a working feature has passing tests but feels unnecessarily complex, when review identifies readability problems, or when time pressure has left nesting, duplication, unclear names, or scattered related logic. Changes introduced by a merge may also benefit from a focused consistency pass.

Skip already readable code, code whose behavior you do not understand, and a module about to be replaced. A proposed simplification is unsuitable if it measurably slows performance-critical code. Avoid unrelated cleanup unless broader scope was explicitly requested. Keep feature changes and bug fixes separate from refactoring so each diff can be reviewed and reverted independently.

Inputs include the code in scope, existing tests, local style rules, and enough surrounding context to understand behavior. The output is an incremental, reviewable refactoring rather than a broad rewrite. Structural signals include deep nesting, long functions, nested ternaries, boolean flags, and repeated conditionals. Possible responses include guard clauses, focused helpers, lookup objects, options objects, and named predicates.

Naming review replaces vague or misleading identifiers with names that describe content and effects. Universal abbreviations can remain. Comments that merely repeat an obvious operation add little; comments explaining intent should remain. Redundancy review examines duplicated logic, confirmed dead code, valueless wrappers, excessive patterns, and redundant type assertions.

A TypeScript example replaces a verbose boolean branch with the same condition:

function isValid(input: string): boolean {
  return input.length > 0 && input.length < 100;
}

Make one simplification, run tests, and reconsider or revert if they fail. Avoid accumulating several untested edits. Refactors touching more than 500 lines call for automation such as codemods or AST transforms rather than large manual passes.

Language guidance covers TypeScript and JavaScript, Python, and React or JSX. These examples require checking semantic preconditions. Removing async is safe only when the called function always returns a Promise and never throws synchronously; otherwise rejected promises can become synchronous exceptions. Replacing a record-shaped accumulator with a Map changes the API and is not an equivalent simplification.

Python examples use dictionary comprehensions and early returns while preserving error types and order. React guidance separates conditional values from rendering; prop drilling is a judgment call to flag rather than automatically restructure.

Final verification checks unchanged tests, a successful build without new warnings, formatting and lint, consistent conventions, preserved error handling, and a clean diff without unrelated changes or dead code. Compare the complete before-and-after result for comprehension and reviewability. If it became harder to understand, revert the attempt rather than defending a smaller line count.