TypeScriptベストプラクティス集 - 読みやすく保守しやすいコードのために

はじめに

TypeScriptを導入したものの、「どこまで型を厳密にすべきか」「anyを使っていいのはどんな場面か」「型定義が複雑になりすぎて読みづらい」といった悩みを抱えていませんか。本記事では、TypeScriptで読みやすく保守しやすいコードを書くためのベストプラクティスを体系的に解説します。

TypeScriptの型システムは非常に強力ですが、その力を最大限に活かすには適切な設計指針が必要です。型が緩すぎればTypeScriptを使う意味が薄れ、型が厳しすぎれば開発速度が低下し、可読性も損なわれます。本記事では、このバランスを取るための具体的なテクニックを紹介します。

この記事を読み終えると、以下のことができるようになります。

any型を避けて型安全性を高める具体的なテクニックを実践できる
型アサーション（as）を適切な場面でのみ使用できる
チームで統一された型の命名規則を設計できる
過度な型定義を避け、シンプルで保守しやすい型を設計できる
コンパイルパフォーマンスを意識した型設計ができる

前提条件

前提知識

本記事は、以下の知識を前提としています。

TypeScriptの基本的な型注釈（string、number、booleanなど）
interfaceとtypeの基本的な使い方
ジェネリクスの基本構文
ユニオン型と型ガードの基礎

動作確認環境

ツール	バージョン
Node.js	20.x以上
TypeScript	5.7以上
VS Code	最新版

本記事のサンプルコードは、TypeScript Playgroundで動作確認できます。strictモードを有効にした状態で試してください。

期待される結果

本記事のベストプラクティスを適用することで、以下の効果が得られます。

コンパイル時にバグを早期発見できる
コードの意図が型から読み取れるようになる
チームメンバー間でのコードレビューが効率化される
長期的な保守コストが削減される

TypeScriptでanyを避けるテクニック

any型は「あらゆる型を受け入れる」特殊な型です。TypeScriptの公式ドキュメントでも、anyの使用は「型チェックを無効にすることと同義」と明記されています。JavaScriptからの移行期間を除き、本番コードではanyを避けるべきです。

anyの問題点を理解する

anyを使用すると、TypeScriptの型チェックが完全にバイパスされます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


// 悪い例: anyを使用
function processData(data: any) {
  // どんな操作もエラーにならない
  console.log(data.nonExistentMethod()); // コンパイルエラーなし、実行時エラー
  return data.foo.bar.baz; // 危険な操作もコンパイルエラーなし
}

// 呼び出し側も型チェックされない
processData(123);
processData("hello");
processData({ completely: "different" });

このコードはコンパイルは通りますが、実行時に予期しないエラーが発生する可能性があります。anyを使った時点で、TypeScriptを使うメリットの大部分を放棄していることになります。

unknownを使う

外部から入力されるデータなど、型が不明な値を扱う場合はunknownを使用します。unknownはanyと同様にあらゆる値を受け入れますが、使用前に型の絞り込みが必須となります。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


// 良い例: unknownを使用
function processData(data: unknown) {
  // そのままではプロパティにアクセスできない
  // console.log(data.foo); // コンパイルエラー

  // 型ガードで絞り込む必要がある
  if (typeof data === "object" && data !== null && "name" in data) {
    // この時点でdataはオブジェクトであることが保証される
    console.log((data as { name: unknown }).name);
  }
}

unknownを使うことで、型の安全性を保ちながら、動的なデータを扱うことができます。

ジェネリクスで汎用性を確保する

「どんな型でも受け入れたい」という要件がある場合、anyではなくジェネリクスを使用します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


// 悪い例: anyで汎用性を確保
function identity(value: any): any {
  return value;
}

const result = identity("hello"); // result: any（型情報が失われる）

// 良い例: ジェネリクスで汎用性を確保
function identityGeneric<T>(value: T): T {
  return value;
}

const resultGeneric = identityGeneric("hello"); // resultGeneric: string（型が保持される）

ジェネリクスを使うことで、入力と出力の型の関係を維持したまま、さまざまな型に対応できます。

型ガードとアサーション関数を活用する

外部APIからのレスポンスなど、型が不明なデータを扱う場合は、型ガード関数を作成します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32


// APIレスポンスの型定義
interface User {
  id: number;
  name: string;
  email: string;
}

// ユーザー定義型ガード
function isUser(value: unknown): value is User {
  return (
    typeof value === "object" &&
    value !== null &&
    "id" in value &&
    typeof (value as User).id === "number" &&
    "name" in value &&
    typeof (value as User).name === "string" &&
    "email" in value &&
    typeof (value as User).email === "string"
  );
}

// 使用例
async function fetchUser(id: number): Promise<User> {
  const response = await fetch(`/api/users/${id}`);
  const data: unknown = await response.json();

  if (!isUser(data)) {
    throw new Error("Invalid user data");
  }

  return data; // data: User として安全に使用可能
}

型ガード関数を一度作成すれば、コードベース全体で再利用できます。

zodなどのバリデーションライブラリを活用する

実行時のバリデーションと型推論を同時に行うライブラリを活用することで、より堅牢なコードが書けます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


import { z } from "zod";

// スキーマ定義（バリデーションルールと型定義を兼ねる）
const UserSchema = z.object({
  id: z.number(),
  name: z.string().min(1),
  email: z.string().email(),
});

// スキーマから型を自動生成
type User = z.infer<typeof UserSchema>;

// 使用例
async function fetchUser(id: number): Promise<User> {
  const response = await fetch(`/api/users/${id}`);
  const data = await response.json();

  // バリデーションと型の絞り込みを同時に行う
  return UserSchema.parse(data);
}

zodを使用することで、型定義とバリデーションロジックの二重管理を避けられます。

型アサーションの適切な使用

型アサーション（as）は、TypeScriptコンパイラに「この値はこの型である」と伝える構文です。便利ですが、誤用すると型安全性を損ないます。

型アサーションが必要な場面

型アサーションは、「コンパイラより開発者の方が型について詳しい情報を持っている」場合にのみ使用すべきです。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


// 正当な使用例1: DOM要素の取得
const canvas = document.getElementById("myCanvas") as HTMLCanvasElement;
// getElementByIdはHTMLElement | nullを返すが、
// 開発者はHTMLCanvasElementであることを知っている

// 正当な使用例2: イベントハンドラ
document.addEventListener("click", (event) => {
  const target = event.target as HTMLButtonElement;
  // event.targetはEventTarget | nullだが、
  // 特定の要素のみがこのハンドラを発火することを開発者は知っている
});

型アサーションを避けるべき場面

型アサーションでコンパイルエラーを「黙らせる」ことは避けるべきです。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


// 悪い例: エラーを黙らせるための型アサーション
interface User {
  id: number;
  name: string;
  email: string;
}

const user = {} as User; // 空オブジェクトをUserとして扱う（危険）
console.log(user.name.toUpperCase()); // 実行時エラー

// 良い例: 適切に初期化する
const userCorrect: User = {
  id: 1,
  name: "John",
  email: "john@example.com",
};

型アサーションは型チェックをバイパスするため、実行時エラーの原因となります。

constアサーションを活用する

as constは、リテラル型を保持するための安全なアサーションです。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


// as constなし
const config = {
  apiUrl: "https://api.example.com",
  timeout: 5000,
};
// configの型: { apiUrl: string; timeout: number; }

// as constあり
const configConst = {
  apiUrl: "https://api.example.com",
  timeout: 5000,
} as const;
// configConstの型: { readonly apiUrl: "https://api.example.com"; readonly timeout: 5000; }

// リテラル型が保持されるため、より厳密な型チェックが可能
type ApiUrl = typeof configConst.apiUrl; // "https://api.example.com"

as constは型安全性を損なわず、むしろ強化するアサーションです。

satisfies演算子を活用する

TypeScript 4.9で導入されたsatisfies演算子は、型アサーションの代替として有用です。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29


// 型定義
interface Theme {
  colors: {
    primary: string;
    secondary: string;
  };
  fontSize: number;
}

// as constと組み合わせることで、リテラル型を保持しつつ型チェックも行う
const theme = {
  colors: {
    primary: "#007bff",
    secondary: "#6c757d",
  },
  fontSize: 16,
} as const satisfies Theme;

// リテラル型が保持される
type PrimaryColor = typeof theme.colors.primary; // "#007bff"

// 型チェックも行われる
const invalidTheme = {
  colors: {
    primary: "#007bff",
    // secondary が欠けている - エラー
  },
  fontSize: 16,
} as const satisfies Theme; // コンパイルエラー

satisfiesは型の互換性をチェックしながら、元の型情報を保持します。

TypeScript型の命名規則

一貫した命名規則は、コードの可読性と保守性を大幅に向上させます。

型名はPascalCaseを使用する

TypeScriptの慣例として、型名（type、interface、class、enum）にはPascalCaseを使用します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


// 良い例: PascalCase
interface UserProfile {
  id: number;
  displayName: string;
}

type ApiResponse<T> = {
  data: T;
  status: number;
};

enum HttpStatus {
  Ok = 200,
  NotFound = 404,
}

// 悪い例: camelCaseやsnake_case
interface userProfile {} // 避けるべき
type api_response = {}; // 避けるべき

Iプレフィックスは避ける

C#由来のIプレフィックス（例: IUser）は、TypeScriptコミュニティでは推奨されていません。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


// 避けるべき: Iプレフィックス
interface IUser {
  id: number;
  name: string;
}

// 推奨: プレフィックスなし
interface User {
  id: number;
  name: string;
}

TypeScriptの公式スタイルガイドでも、Iプレフィックスは使用しないよう推奨されています。

意図を表す名前をつける

型名は、その型が「何を表すか」を明確に示すべきです。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


// 悪い例: 抽象的すぎる名前
type Data = { /* ... */ };
type Info = { /* ... */ };
type Item = { /* ... */ };

// 良い例: 具体的で意図が明確な名前
type UserRegistrationForm = {
  email: string;
  password: string;
  confirmPassword: string;
};

type PaginatedResponse<T> = {
  items: T[];
  totalCount: number;
  currentPage: number;
  totalPages: number;
};

type ValidationResult = {
  isValid: boolean;
  errors: string[];
};

PropsとStateのサフィックス

ReactコンポーネントのPropsやStateには、サフィックスをつけて区別します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


// Reactコンポーネントの型定義
interface UserCardProps {
  user: User;
  onSelect: (userId: number) => void;
  isHighlighted?: boolean;
}

interface UserListState {
  users: User[];
  isLoading: boolean;
  error: Error | null;
}

// コンポーネントでの使用
function UserCard({ user, onSelect, isHighlighted }: UserCardProps) {
  return (
    <div onClick={() => onSelect(user.id)}>
      {user.name}
    </div>
  );
}

ジェネリクスの型パラメータ命名

型パラメータは、慣例的に単一の大文字が使われますが、意味のある名前をつけることも推奨されます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


// 一般的な慣例
type Result<T> = { value: T } | { error: Error };
type KeyValue<K, V> = { key: K; value: V };

// より意味のある名前（複雑なジェネリクスの場合）
type Repository<TEntity, TId = number> = {
  findById(id: TId): Promise<TEntity | null>;
  save(entity: TEntity): Promise<TEntity>;
  delete(id: TId): Promise<void>;
};

// 型パラメータの一般的な慣例
// T: Type（汎用）
// K: Key（オブジェクトのキー）
// V: Value（値）
// E: Element（要素）
// R: Return（戻り値）

過度な型定義の回避

TypeScriptの強力な型システムは、使い方を誤ると可読性を損なう原因にもなります。シンプルで保守しやすい型を心がけましょう。

型推論を活用する

TypeScriptの型推論は非常に優秀です。明らかな場合は型注釈を省略できます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


// 冗長な例: 型推論で十分な場合に型注釈を付ける
const name: string = "John";
const count: number = 42;
const isActive: boolean = true;
const users: User[] = fetchUsers();

// 良い例: 型推論に任せる
const name = "John"; // string と推論
const count = 42; // number と推論
const isActive = true; // boolean と推論
const users = fetchUsers(); // User[] と推論（fetchUsersの戻り値型から）

// 型注釈が必要な場面
// 1. 初期値がundefinedやnullの場合
let user: User | null = null;

// 2. 複数の型を持ちうる場合
let value: string | number;

// 3. 関数の引数と戻り値（推奨）
function calculateTotal(items: CartItem[]): number {
  return items.reduce((sum, item) => sum + item.price, 0);
}

ユーティリティ型を活用する

同じような型を何度も定義する代わりに、ユーティリティ型を活用します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


interface User {
  id: number;
  name: string;
  email: string;
  createdAt: Date;
  updatedAt: Date;
}

// 悪い例: 類似した型を個別に定義
interface UserCreateInput {
  name: string;
  email: string;
}

interface UserUpdateInput {
  name?: string;
  email?: string;
}

// 良い例: ユーティリティ型を活用
type UserCreateInput = Omit<User, "id" | "createdAt" | "updatedAt">;
type UserUpdateInput = Partial<Pick<User, "name" | "email">>;

// さらにシンプルに
type UserEditableFields = Pick<User, "name" | "email">;
type UserCreateInput = UserEditableFields;
type UserUpdateInput = Partial<UserEditableFields>;

深すぎるネストを避ける

型定義のネストが深くなりすぎると、可読性が著しく低下します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34


// 悪い例: 深すぎるネスト
type DeepNested = {
  level1: {
    level2: {
      level3: {
        level4: {
          value: string;
        };
      };
    };
  };
};

// 良い例: 中間型を定義して分割
interface Level4Data {
  value: string;
}

interface Level3Data {
  level4: Level4Data;
}

interface Level2Data {
  level3: Level3Data;
}

interface Level1Data {
  level2: Level2Data;
}

// または、フラットな構造を検討する
interface FlatData {
  level1_level2_level3_value: string;
}

条件付き型の複雑さを制限する

条件付き型は強力ですが、複雑になりすぎると理解が困難になります。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42


// 悪い例: 複雑すぎる条件付き型
type ComplexType<T> =
  T extends string
    ? T extends `${infer First}${infer Rest}`
      ? First extends Uppercase<First>
        ? Rest extends ""
          ? "single-uppercase"
          : "starts-with-uppercase"
        : Rest extends ""
          ? "single-lowercase"
          : "starts-with-lowercase"
      : never
    : T extends number
      ? T extends 0
        ? "zero"
        : "non-zero"
      : never;

// 良い例: 分割して名前をつける
type StartsWithUppercase<T extends string> =
  T extends `${infer First}${string}`
    ? First extends Uppercase<First>
      ? true
      : false
    : false;

type IsSingleChar<T extends string> =
  T extends `${string}${infer Rest}`
    ? Rest extends ""
      ? true
      : false
    : false;

// 組み合わせて使用
type StringCategory<T extends string> =
  IsSingleChar<T> extends true
    ? StartsWithUppercase<T> extends true
      ? "single-uppercase"
      : "single-lowercase"
    : StartsWithUppercase<T> extends true
      ? "starts-with-uppercase"
      : "starts-with-lowercase";

型とロジックを分離する

型定義に過度なロジックを詰め込まず、ランタイムのロジックと適切に分離します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


// 悪い例: 型でバリデーションロジックを表現しようとする
type ValidEmail<T extends string> =
  T extends `${string}@${string}.${string}` ? T : never;

// 良い例: ランタイムのバリデーションを使用
interface Email {
  readonly value: string;
}

function createEmail(value: string): Email {
  const emailRegex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
  if (!emailRegex.test(value)) {
    throw new Error("Invalid email format");
  }
  return { value };
}

// または、zodなどのライブラリを使用
const EmailSchema = z.string().email();
type Email = z.infer<typeof EmailSchema>;

パフォーマンスを意識したTypeScript型設計

大規模なプロジェクトでは、型設計がコンパイル時間とエディタのパフォーマンスに影響を与えます。TypeScript公式WikiのPerformanceガイドに基づいた最適化テクニックを紹介します。

インターセクション型よりinterfaceのextendsを優先する

複数の型を合成する場合、インターセクション型（&）よりもinterfaceのextendsを使用した方がコンパイラの効率が良くなります。

1
2
3
4
5
6
7
8
9


// 避けるべき: インターセクション型
type UserWithProfile = User & Profile & {
  additionalField: string;
};

// 推奨: interfaceのextends
interface UserWithProfile extends User, Profile {
  additionalField: string;
}

公式ドキュメントによると、interfaceは単一のフラットなオブジェクト型を作成し、プロパティの競合を検出できます。一方、インターセクション型はプロパティを再帰的にマージするため、場合によってはnever型が生成されることがあります。また、interface間の型関係はキャッシュされますが、インターセクション型全体はキャッシュされません。

複雑な型に名前をつける

複雑な型を名前付きの型エイリアスとして抽出することで、コンパイラがキャッシュを活用できます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


// 悪い例: インラインで複雑な型を定義
interface SomeType<T> {
  foo<U>(x: U):
    U extends TypeA<T> ? ProcessTypeA<U, T> :
    U extends TypeB<T> ? ProcessTypeB<U, T> :
    U extends TypeC<T> ? ProcessTypeC<U, T> :
    U;
}

// 良い例: 複雑な型を抽出して名前をつける
type FooResult<U, T> =
  U extends TypeA<T> ? ProcessTypeA<U, T> :
  U extends TypeB<T> ? ProcessTypeB<U, T> :
  U extends TypeC<T> ? ProcessTypeC<U, T> :
  U;

interface SomeType<T> {
  foo<U>(x: U): FooResult<U, T>;
}

名前付きの型は、コンパイラがより多くの情報をキャッシュできるため、コンパイル速度が向上します。

大きなユニオン型を避ける

要素数が多いユニオン型は、コンパイル時間に大きな影響を与えます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


// 悪い例: 巨大なユニオン型
type AllDomElements =
  | HTMLDivElement
  | HTMLSpanElement
  | HTMLParagraphElement
  | HTMLAnchorElement
  // ... 数十の要素が続く
  | HTMLVideoElement;

// 良い例: 基底型を使用
interface BaseElement {
  tagName: string;
  // 共通のプロパティ
}

interface DivElement extends BaseElement {
  tagName: "div";
  // div固有のプロパティ
}

// 関数は基底型を受け取る
function processElement(element: BaseElement): void {
  // 必要に応じて型ガードで絞り込む
}

ユニオン型の要素を比較する処理は、要素数の2乗に比例して計算量が増加するため、12要素以上のユニオン型は設計を見直すことを検討してください。

関数の戻り値型を明示する

関数の戻り値型を明示することで、コンパイラの推論負荷を軽減できます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


// 悪い例: 戻り値型を省略
import { otherFunc } from "other";

export function processData() {
  return otherFunc();
}

// 良い例: 戻り値型を明示
import { otherFunc, ResultType } from "other";

export function processData(): ResultType {
  return otherFunc();
}

特に、エクスポートされる関数や複雑な処理を行う関数では、戻り値型を明示することで型チェックの高速化とエラーメッセージの改善が期待できます。

プロジェクト参照を活用する

大規模なコードベースでは、プロジェクト参照（Project References）を使用してコードを分割します。

graph TD
    subgraph "モノレポ構造"
        Shared[Shared]
        Client[Client]
        Server[Server]
        Tests[Tests]
    end

    Client --> Shared
    Server --> Shared
    Tests --> Client
    Tests --> Server

tsconfig.jsonでプロジェクト参照を設定することで、変更された部分のみを再コンパイルできます。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


{
  "compilerOptions": {
    "composite": true,
    "declaration": true,
    "incremental": true
  },
  "references": [
    { "path": "../shared" }
  ]
}

skipLibCheckを有効にする

サードパーティライブラリの型定義ファイル（.d.ts）のチェックをスキップすることで、コンパイル時間を短縮できます。

1
2
3
4
5


{
  "compilerOptions": {
    "skipLibCheck": true
  }
}

ただし、この設定は.d.tsファイル間の整合性チェックを無効にするため、型定義ファイルに問題がある場合に見落とす可能性があります。

TypeScriptベストプラクティスのまとめ

本記事で紹介したベストプラクティスを、カテゴリごとにまとめます。

anyを避けるためのチェックリスト

型が不明な値にはunknownを使用する
汎用的な関数にはジェネリクスを使用する
外部データには型ガード関数を作成する
zodなどのバリデーションライブラリの活用を検討する

型アサーションのルール

DOM要素の取得など、コンパイラより開発者の方が型を知っている場合のみ使用する
エラーを「黙らせる」ための使用は避ける
as constとsatisfiesを積極的に活用する

命名規則の統一

型名はPascalCaseを使用する
Iプレフィックスは使用しない
意図を表す具体的な名前をつける
Props、Stateには適切なサフィックスをつける

シンプルな型設計

型推論を積極的に活用する
ユーティリティ型で重複を減らす
深すぎるネストを避ける
複雑な条件付き型は分割して名前をつける

パフォーマンスの最適化

インターセクション型よりinterfaceのextendsを優先する
複雑な型には名前をつけてキャッシュを活用する
大きなユニオン型は基底型で置き換える
関数の戻り値型を明示する

これらのプラクティスを日々の開発に取り入れることで、読みやすく保守しやすいTypeScriptコードを書けるようになります。チーム内でコーディング規約として共有し、コードレビューの基準として活用することをおすすめします。

参考リンク

TypeScript公式ドキュメント - Do’s and Don’ts - TypeScript公式の型定義ガイドライン
TypeScript Wiki - Performance - コンパイルパフォーマンスの最適化ガイド
TypeScript Handbook - TypeScript公式ハンドブック
zod公式ドキュメント - 型安全なスキーマバリデーションライブラリ
TypeScript Playground - ブラウザで動作するTypeScript実行環境

はじめに#

前提条件#

前提知識#

動作確認環境#

期待される結果#

TypeScriptでanyを避けるテクニック#

anyの問題点を理解する#

unknownを使う#

ジェネリクスで汎用性を確保する#

型ガードとアサーション関数を活用する#

zodなどのバリデーションライブラリを活用する#

型アサーションの適切な使用#

型アサーションが必要な場面#

型アサーションを避けるべき場面#

constアサーションを活用する#

satisfies演算子を活用する#

TypeScript型の命名規則#

型名はPascalCaseを使用する#

Iプレフィックスは避ける#

意図を表す名前をつける#

PropsとStateのサフィックス#

ジェネリクスの型パラメータ命名#

過度な型定義の回避#

型推論を活用する#

ユーティリティ型を活用する#

深すぎるネストを避ける#

条件付き型の複雑さを制限する#

型とロジックを分離する#

パフォーマンスを意識したTypeScript型設計#

インターセクション型よりinterfaceのextendsを優先する#

複雑な型に名前をつける#

大きなユニオン型を避ける#

関数の戻り値型を明示する#

プロジェクト参照を活用する#

skipLibCheckを有効にする#

TypeScriptベストプラクティスのまとめ#

anyを避けるためのチェックリスト#

型アサーションのルール#

命名規則の統一#

シンプルな型設計#

パフォーマンスの最適化#

参考リンク#