Right, so you’ve decided to write some TypeScript that doesn’t look like it was generated by a room full of cats walking on keyboards. Good. The first step is admitting you have a problem. The second step is realizing that while your personal style is fascinating, it’s also a nightmare for anyone else who has to read your code. This is where style guides come in. They’re the guardrails that keep you from driving your beautifully typed code off a cliff of inconsistency.

But which one? You’ve got the big ones: Google’s and Airbnb’s. You’ve got the built-in tslint.json and eslintrc templates. And you’ve got a million blog posts from people who are sure they’ve cracked the code. Let’s cut through the noise.

The Big Two: Google vs. Airbnb

First, a crucial piece of insider knowledge: these aren’t really TypeScript style guides. They’re JavaScript style guides that have been extended for TypeScript. This explains a lot of their quirks.

Google’s guide reads like a rigorous engineering specification from, well, Google. It’s comprehensive, often pedantic, and heavily influenced by their massive internal codebase and Closure Compiler heritage. They prefer things like const for everything that doesn’t change, and they have opinions on how you should use any.

Airbnb’s guide, on the other hand, is the popular kid. It’s widely adopted, extremely readable, and feels more pragmatic. It emerged from a real-world, large-scale React codebase, so its rules are battle-tested for modern web development.

Here’s a classic difference: semicolons. Google says yes. Airbnb says no. This is the kind of holy war that has ended friendships. My advice? Pick one and stick with it. The worst choice is no choice.

// Google & Old-School JS: Semicolons, always.
const x: number = 42;
const greet = (name: string): string => {
  return 'Hello, ' + name;
};

// Airbnb & The Semicolon-Hating Masses: No thanks, we're good.
const x: number = 42
const greet = (name: string): string => {
  return 'Hello, ' + name
}

The why here is about Automatic Semicolon Insertion (ASI), a truly absurd part of the JavaScript specification. Omitting semicolons can lead to subtle, horrifying bugs when lines are minified or concatenated in unexpected ways. Google’s rule is safer. Airbnb’s rule is cleaner. You see the dilemma.

The One Rule to Rule Them All: strict

If you take nothing else from this, take this: enable strict: true in your tsconfig.json. This isn’t a style suggestion; it’s a non-negotiable best practice. This single flag enables a whole suite of type-checking options that turn TypeScript from a friendly suggestion box into a rigorous type-proofing system. It will catch null pointers, implicit anys, and other horrors at compile time instead of letting them explode in your users’ faces at runtime.

Not using strict is like buying a sports car and then refusing to use the brakes because you think they slow you down. You’re not going faster; you’re just driving a deathtrap.

Taming the any Beast

Both major guides (and anyone with a shred of self-respect) treat any as a code smell. It’s the “get out of jail free” card that completely defeats the purpose of TypeScript. But sometimes, you genuinely don’t know the type, or you’re integrating with a wild JavaScript library. In those cases, don’t use any. Use unknown and then prove the type is what you expect.

// ❌ Bad: You've just turned off all type safety for this value.
function dangerousFunction(data: any) {
  console.log(data.whatEvenIsThis); // TS is cool with this. It shouldn't be.
}

// ✅ Better: You're forcing yourself to handle the uncertainty.
function saferFunction(data: unknown) {
  // Property 'whatEvenIsThis' does not exist on type 'unknown'.(2339)
  // console.log(data.whatEvenIsThis);

  // First, prove it's an object and has the property.
  if (typeof data === 'object' && data !== null && 'whatEvenIsThis' in data) {
    // Now TypeScript narrows the type and lets you proceed.
    console.log(data.whatEvenIsThis);
  }
}

The unknown type is basically “I’m not being lazy, I’m being honest about the fact that I don’t know what this is yet.” It’s a night-and-day difference in intent and safety.

The Community Consensus

Beyond the big guides, there are rules the broader community has largely settled on. These are the ones you’ll see in almost every modern project:

  • Use interface for public API definitions (it’s more extensible through declaration merging) and type for complex unions, tuples, or computed values. Though, honestly, the difference is minimal for most cases. Just be consistent.
  • Prefer const for everything until you have to use let. You almost never need var. That thing is a relic.
  • Use arrow functions over function declarations for callbacks and methods, as they handle this more predictably. This isn’t just style; it’s avoiding a whole category of bugs.
  • Enable noUnusedLocals and noUnusedParameters. Dead code is a liar. It tells everyone you might need it someday, but it’s just collecting dust and making your code harder to read. Delete it.

The goal of any style guide isn’t to stifle your creativity. It’s to eliminate pointless decisions so you can focus on the hard, interesting problems. It makes your code look like it was written by a single, competent person instead of a committee of warring ghosts. Pick one, automate it with ESLint and Prettier, and never think about semicolons again.