TypeScript Code Review: 10 Mistakes That Annoy Seniors

Introduction: Why Does Your TypeScript Code Review Look Like a Red Light on a Control Panel?

Have you ever submitted a pull request, only to receive 20 comments from a senior developer an hour later, half of which started with "this could be done better"? Sounds familiar. If you write in TypeScript, but your code still makes colleagues want to rewrite it from scratch — this article is for you.

Here at PythonLib, we often encounter situations where developers, even knowing TypeScript syntax, make the same mistakes. These mistakes don't break the code, but they make it unreadable, unsafe, and hard to maintain. Today, I'll show you 10 typical comments that seniors write during a TypeScript code review, and how to avoid them. Get ready for some refactoring!

1. "Any" — Your Enemy, Not Your Friend

The most common complaint in any TypeScript code review is the use of any. It seems easier to write const data: any = await fetch(...) than to deal with types. But seniors see this as a red flag.

Bad:

function processUser(user: any) {  console.log(user.name.toUpperCase());}

Good:

interface User {  id: number;  name: string;  email: string;}

function processUser(user: User): void {  console.log(user.name.toUpperCase());}

Why is this important? TypeScript loses all its meaning if you use any. You are literally disabling the type system. If data comes from an API — create an interface. If the type is complex — use unknown with checks. This is one of the main TypeScript best practices.

2. Ignoring Strict Mode

Many projects disable strict mode in tsconfig.json because "it's faster" or "types are annoying". A senior TypeScript developer will immediately notice that your code doesn't check for null and undefined.

Bad (strict: false):

function getLength(str: string) {  return str.length; // str could be null, and this will crash}

Good (strict: true):

function getLength(str: string | null): number {  if (str === null) return 0;  return str.length;}

Tip: Enable strict: true in your tsconfig.json. This will force you to write safer code. During a TypeScript code review, this will be a plus, not a minus.

3. Type Magic: Excessive Complexity

Sometimes developers try to show off and write types that even seniors have to scratch their heads over. For example, conditional types with nested generics where a simple interface would suffice.

Bad (over-engineering):

type DeepReadonly<T> = {  readonly [P in keyof T]: T[P] extends object ? DeepReadonly<T[P]> : T[P];};

Good (simplicity):

interface Config {  readonly apiUrl: string;  readonly timeout: number;}

Seniors value code readability. If your type can be replaced with an interface with three fields — do it. Don't complicate things unnecessarily.

4. Incorrect Error Handling

A typical mistake in a TypeScript code review is a try-catch with any or an empty catch block. Seniors will point this out immediately.

Bad:

try {  const data = await fetchData();} catch (e) {  console.log('Error');}

Good:

try {  const data = await fetchData();} catch (error: unknown) {  if (error instanceof Error) {    console.error(error.message);  } else {    console.error('Unknown error', error);  }}

Use unknown for errors. This is