ProgramGuru

Static Analysis and Linting

Static Analysis and Linting — why it matters

Static analysis reviews code without executing every path. TypeScript type checking and lint rules detect different classes of defects, such as incompatible types versus suspicious patterns. Configure relevant rules for the project and handle noise deliberately, rather than disabling every difficult diagnostic.

What you’ll learn

  • Explain static analysis and linting and the problem it solves.
  • Identify the relevant compile-time checks and runtime responsibilities.
  • Run the example, predict its output, and try a realistic modification.

Understand the mechanism

readonly communicates that total should not mutate its input. TypeScript checks those operations. A linter can additionally enforce conventions and flag suspicious unused variables.

A lint warning is not necessarily a runtime failure; neither linting nor type checking replaces tests of actual behavior.

Follow the concept flow

Static Analysis and Linting — concept flowSource code → Compiler + linter → Feedback and fixesStatic Analysis and Linting1Source code2Compiler + linter3Feedback and fixesTests exercise behavior, while types check static contracts.
Follow the responsibilities from input to checked result.

Run the primary TypeScript example

Save as static-analysis-linting.ts. The following program passed strict TypeScript compilation, and the displayed output was captured by executing its emitted JavaScript with Node.js 22.16.0.

TypeScript source

function total(scores: readonly number[]): number {
  return scores.reduce((sum, value) => sum + value, 0);
}
console.log(total([4, 5, 6]));

Verified output

15

Compile: npx tsc --strict --target es2022 --module commonjs static-analysis-linting.ts; run: node static-analysis-linting.js. For Node.js API examples, install @types/node first. For browser projects, use the browser-specific instructions below.

The example demonstrates the code-level behavior; the related configuration or test commands are shown separately when needed.

Trace the result

readonly communicates that total should not mutate its input. TypeScript checks those operations. A linter can additionally enforce conventions and flag suspicious unused variables.

Predict what changes if you alter one input. Then run the code to compare your reasoning with the real output.

Common mistake and correction

A lint warning is not necessarily a runtime failure; neither linting nor type checking replaces tests of actual behavior.

Identify whether the failure is a type-checking issue, a configuration issue, or a runtime behavior issue before choosing a fix.

Practice the concept

Configure noUnusedLocals and a linter rule for unused variables, then compare the messages from both tools.

Write down your expected result first. For configuration examples, compare compiler output and diagnostics; for test examples, make the assertion fail deliberately to verify that the tool reports it.

Check your understanding

Which statement makes a trustworthy TypeScript testing practice?
Choose one answer. You can try again.

Answer and explanation

A test must exercise behavior and assert an expected outcome; compiler checks and test results provide different evidence.

readonly communicates that total should not mutate its input. TypeScript checks those operations. A linter can additionally enforce conventions and flag suspicious unused variables.

What to remember

Static analysis reviews code without executing every path.

Run the primary example, then complete the practice task or environment-specific lab.

Reaching the recap and completing the quizzes are separate milestones.

    Next lesson: Runtime Data Validation →