In a TypeScript review you see every local variable annotated, as in `const count: number = items.length`. Is that worth flagging, and where does an explicit annotation on a variable genuinely earn its place?

## The default: let inference work TypeScript infers a variable's type from its initializer. `const count = items.length` gives `count` the type `number` with no help from you, and unlike a comment the inferred type cannot go stale — it is recomputed from the code every build. Writing `const count: number = items.length` restates a fact the compiler already knows, which costs a line of reading and buys nothing. Worse, it rots. If `items.length` is later replaced by something returning a different type, the annotation does not describe the code any more, and the resulting error message points at the assignment rather than at the change that caused it. ## The hazard people miss: annotations launder `any` This is the argument that turns a style preference into a correctness one. An annotation on a variable is an **assignability check**, and `any` is assignable to every type. So this compiles: ```ts declare function getCount(): any; // untyped dependency, JSON.parse, etc. const count: number = getCount(); // no error, no check count.toFixed(2); // trusted; may explode at runtime ``` The annotation does not verify anything at runtime — it is erased — and it does not verify anything at compile time either, because the source type is `any`. What it *does* is stop the `any` from being visible downstream, so tools and readers looking for untyped values see a clean `number`. Compare with letting inference run: `const count = getCount()` gives `count` the type `any`, which is at least honest and is what a no-implicit-any style rule or a lint rule against unsafe assignment can catch. The fix is not to remove the annotation and accept the `any`. It is to convert at the boundary — validate, or write a wrapper that returns a real type — so the annotation reflects a check that actually happened. ## Where annotations genuinely earn their place **1. The initializer cannot tell the whole story.** An empty array or a nullish initializer describes only the variable's first instant: ```ts const ids: string[] = []; // otherwise the element type is unknown to you let current: Shape | null = null; // otherwise the declaration says only 'null' ``` A bare `let x;` is the extreme case: with nothing to infer from, you get an implicit `any`, and every later use is unchecked. **2. The inferred type is not the one you want.** Inference describes the initializer, not your intent. If a mutable variable will later hold a different member of a union, or if you deliberately want the widened primitive rather than the precise type the initializer produced, say so explicitly. The annotation is the tool for stating intent that the first value does not imply. **3. Boundaries you export.** A module-level or exported value is a contract. Annotating it pins the contract at the definition: if the implementation drifts, the error lands on that line. Without the annotation, the exported type silently changes shape and the errors appear scattered across every consumer — the same reasoning that makes annotated return types valuable on a public API surface. ## What a good review comment sounds like Rather than "annotations are bad", the useful review framing is a question: *does this annotation tell the compiler something it did not already know?* If yes, keep it. If no, it is either noise or — when the right-hand side is untyped — a mask, and the mask is the one worth arguing about. ## Erasure, and what that means for trust Every annotation in this discussion disappears at compile time. There is no runtime validation attached to `: number`, so the confidence a reader draws from seeing it is entirely borrowed from the compiler's check — and that check is only as strong as the type on the right-hand side. That is the whole reason `any` laundering matters: the reader's trust survives the compiler's check being vacuous. ## The short version Default to inference; it cannot rot. Annotate when inference has nothing to work with, when your intent is wider or different than the initializer implies, or when you are pinning an exported contract. Treat an annotation whose right-hand side is `any` as a defect, not as documentation.