コードの「読みやすさ」をハックする：ESLintとPrettierでエンジニアの認知負荷を最小化する
こんにちは。開発環境の最適化に命を燃やすエンジニアです。
新しいプロジェクトを始めたとき、あるいはチーム開発でコードレビューをする際、もっとも精神をすり減らすのは「コードの書き方に関する些細な論争」ではありませんか？「インデントはスペース2つか4つか」「この行は改行すべきか」。そんな不毛な議論に使う時間は、プロダクトの価値を最大化するために使うべきです。
今回は、JavaScript/TypeScript開発において必須の二大巨頭、ESLintとPrettierを導入し、特に「Prettierの`printWidth`（行の長さ）」という、一見地味ながらエンジニアの生産性に直結する設定の真髄を紐解いていきます。
—
1. ESLintとPrettier：役割の境界を理解する
まず、この二つが「なぜ必要なのか」を正しく理解しましょう。ここを混同していると、開発環境はすぐにスパゲッティ状態になります。
- ESLint（コード品質の番人）:
コード内の論理的なミス（使われていない変数、定義前の関数呼び出し、非推奨な構文）を検知します。「コードの正しさ」を守るツールです。
- Prettier（見た目の調律師）:
改行、クォートの選択、セミコロンの有無など、「コードの見た目」を強制的に統一します。
結論： ESLintは「バグを減らすため」にあり、Prettierは「チームの心理的安全性を保つため」にあります。この二つを組み合わせることで、私たちは「ロジックに集中する」という究極の贅沢を手に入れるのです。
—
2. 最小構成で環境を構築する
まずは、モダンなNode.js環境で最もクリーンなセットアップを行いましょう。
必要なライブラリを開発依存としてインストール
npm install –save-dev eslint prettier eslint-config-prettier eslint-plugin-prettier
- `eslint-config-prettier`: ESLintとPrettierが競合するルールを無効化します。これがなければ、両者が「ここは改行しろ」「いや、するな」と喧嘩を始めます。
最重要：.prettierrc（設定ファイル）の作成
プロジェクトルートに `.prettierrc.json` を作成します。
{
“semi”: true, // セミコロンを強制（JSの自動セミコロン挿入による予期せぬ挙動を防ぐ）
“singleQuote”: true, // ダブルクォートより可読性が高いとされるシングルクォートを採用
“tabWidth”: 2, // インデントは標準的な2スペース
“trailingComma”: “all” // 変更差分を最小化するため、末尾のカンマは常に付ける
}
—
3. 「printWidth」の深淵：なぜ80〜100文字が最適なのか？
さて、今回の本題です。Prettierの `printWidth` 設定。これは「一行を何文字で折り返すか」という閾値です。
多くの初心者がデフォルトの「80文字」を見て、「今のモニターは広いのに、なぜこんなに短いの？」と疑問に思います。しかし、80〜100文字という制限には、人間の認知科学に基づいた理由があるのです。
なぜ短く設定すべきなのか？
1. 視線移動の最小化: 人間が文章を読む際、視線が左右に大きく動くと疲労が蓄積します。コードを一行で追い切れる範囲に収めることで、脳の認知負荷を劇的に下げることができます。
2. ネストの可視化: `printWidth`を短くすると、複雑なネスト（if文やコールバックの多重構造）がコードを右側に押し出し、視覚的に「この関数、深すぎないか？」というアラートを強制的に突きつけます。「長すぎる行＝リファクタリングのサイン」というシグナルになるのです。
3. 横並びの比較: コードレビュー時に、2つのファイルを左右に並べて表示することが多いですよね。`printWidth`が長すぎると、頻繁に水平スクロールが発生し、集中力が削がれます。
アーキテクト推奨の基準
- 80文字: ストイックなチーム向け。コードの「複雑さ」に敏感になれます。
- 100文字: 現代の標準。TypeScriptの型定義などが長くなりがちな環境では、100文字が最もバランスが良いです。
- 120文字以上: 推奨しません。モニターの広さに甘えると、コードの質（設計の凝集度）が確実に低下します。
`.prettierrc`に追記してください。
“printWidth”: 100 // チームで合意可能な「ギリギリの読みやすさ」
—
4. HelloWorld的な動作確認
正しく設定できているか、以下のファイルをわざと汚して保存してみてください。
// test.js
const hello = “world”;
function foo(){console.log(hello)}
保存した瞬間に、Prettierが以下のように修正してくれれば成功です。
const hello = ‘world’;
function foo() {
console.log(hello);
}
—
最後に：なぜこれをやるのか
ツールを導入する真の目的は、「設定の完璧さ」を追求することではありません。「コードの見た目に関する議論を、自動化という名のゴミ箱に捨てること」です。
チーム開発において、誰かの書いたコードのインデントを直す時間は、人生で最も生産性の低い時間の一つです。Prettierに任せきりにして、あなたは「どうすればもっと良いロジックが書けるか」「どうすればユーザーの課題を解決できるか」に脳のメモリを割いてください。
開発環境を整えることは、自分自身への最高のプレゼントです。ぜひ、今日からこの設定をプロジェクトに組み込み、ストレスフリーなコーディングライフを楽しんでください。応援しています。