コードは何行までが適正?「長すぎるコード」の境界線と分割のタイミング

  • URLをコピーしました!

非エンジニアの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行=限界のサイン」

これを超えたら「分割を検討する」だけでも、コードの読みやすさ・保守性・再利用性が格段に上がる。

コードの長さを減らすことは、読みやすさを取り戻すだけでなく、バグを防ぎ、保守コストを下げ、開発効率を上げる”最強の武器”でもあるんだ。

面倒くさがりの俺でもできるんだから、きっと誰でもできるはず。

よかったらシェアしてね!
  • URLをコピーしました!
目次