非エンジニアのRyoです。
また新しいことを学んだんだけど、最初はマジで意味わからんかった。「このファイル、そろそろ長すぎるかな？」って思うこと、プログラミングしてる人なら誰でもあるよね。でも、何行以上が”長い”のか、明確な基準ってあるの？今回学んだことを、同じように悩む非エンジニアの人にシェアしてみる。
コードの長さ、行数の目安は？
ReactやTypeScriptでUIがある場合の目安をまとめてみた。
行数別の認識
・〜100行：OK（読みやすい・小規模）
・100〜200行：注意（状態管理が増えてくる）
・200〜300行：長め（関数のネストやUIの複雑さが気になる）
・300行以上：長すぎ（早急に分割すべき）
マジで300行が境界線になってる。これ超えたら要注意ってことだ。
分けるべき判断基準
以下のサインが出てきたら分割を検討すべき。
・同じような処理が繰り返されている
・useStateやuseEffectが多すぎて、頭が混乱する
・スクロールしても今どこを見てるか分からない
・UIとロジックが混在して、見通しが悪い
・コードジャンプしても目的の箇所が見つからない
・1つの関数に10行以上のif分やネストがある
他の言語ではどう？
言語によって認識が違うけど、基本的に300行は長いって認識。
・JavaScript/TypeScript：長い（特にUIと状態が混ざるReactでは顕著）
・Python：長い（関数型・スクリプト文化があるので、短く保つのが吉）
・Java/C#：やや長い（クラス単位で見るが、可読性は意識される）
・C/C++：長い（ネスト・ポインタ・メモリ操作が絡むと危険度大）
・Ruby/PHP：長い（フレームワークでのMVC分離が前提）
なぜ”300行”が限界なのか？（脳科学の話）
人間の短期記憶には限界があって、一度に保持できる情報は「7±2チャンク」（ミラーの法則）って言われてる。
コードが300行を超えると、以下の問題が起こりやすくなる。
・今見ている関数の上が思い出せない
・複数の状態の流れを同時に追えない
・「1ファイル＝1責任」の原則から逸脱する
つまり、構造を把握できる脳の処理能力を超えてしまうんだ。
長すぎるコードのリスク
長すぎるコードには以下のリスクがある。
・バグが増える（状態の影響範囲がわかりづらく、修正時に別の場所を壊しやすい）
・保守性が下がる（他の人が読んで理解するのに時間がかかる）
・再利用できない（似た処理が別ファイルに必要でもコピペしかできない）
・テストしにくい（1つのコンポーネントに機能が詰まりすぎて単体テストできない）
コードを短く保つためのテクニック
Reactの場合
・UIごとに小さなコンポーネントに分割
・ロジックはカスタムフックで切り出し
・アニメーションは専用ファイルに分ける
・イベントハンドラを1行で書かずに関数化
汎用言語共通
・関数の長さは20行以内を意識
・重複処理はすぐ関数化
・責任ごとにファイル分け（単一責任原則）
実務感覚：こんな行数だったらこうする
・150行前後：メインはそのまま。ロジックやUIを少し切り出す
・250行超え：主要UI・ロジックを分割し始めるべき
・400行超え：本格的に設計を見直すべき。見通しが悪すぎる
・600行〜：リーダブルコードとしては崩壊。保守不可レベル
まとめ
「300行＝限界のサイン」
これを超えたら「分割を検討する」だけでも、コードの読みやすさ・保守性・再利用性が格段に上がる。
コードの長さを減らすことは、読みやすさを取り戻すだけでなく、バグを防ぎ、保守コストを下げ、開発効率を上げる”最強の武器”でもあるんだ。
面倒くさがりの俺でもできるんだから、きっと誰でもできるはず。
