コードを書く際の基本原則

① 一行ずつコメントを書くべきか？

結論：

❌ すべての行にコメントを書くのは推奨されない
⭕ 「意図が分かりにくい箇所」にコメントを書くのが正解

■ なぜ一行コメントは危険？

例：

i++;  // iを1増やす

これはコードを読めば分かります。

このようなコメントは

• メンテナンスで更新漏れ
• ノイズ増加
• 可読性低下

を招きます。

■ 正しいコメントの書き方

コメントは

「何をしているか」ではなく
「なぜそうしているか」を書く

例：

// 通信仕様上、ACKは3回まで再送する必要がある
retry_count++;

👉 仕様・背景・制約を書くのが重要

② 時間が経つと理解できなくなる理由

コードが理解できなくなる原因は：

• 命名が曖昧
• ロジックが複雑
• ネストが深い
• 設計意図が不明

つまり問題は「コメント不足」ではなく
設計の見通しの悪さです。

③ 入れ子を避ける設計

悪い例（ネスト地獄）

if (a) {
    if (b) {
        if (c) {
            process();
        }
    }
}

---

改善例（早期リターン）

if (!a) return;
if (!b) return;
if (!c) return;

process();

👉 ネストを浅くするのが基本

④ フローチャートを作る目的

フローチャートは

✔ 条件の整理
✔ 処理順序の明確化
✔ ネスト削減
✔ 例外処理の洗い出し

のために作る。

■ フローチャート作成のポイント

• 条件はYes/Noで分岐
• 処理は1ブロック1動作
• 例外は先に処理
• ループ条件を明確に

⑤ 実務で推奨される3原則

① ネストは3段まで
② 関数は1機能1責務
③ コメントは「意図」を書く