ITパスポート 2010年 秋期 問43

変数の命名規則やコメントの書き方など、プログラムの標準的な記述方式を定める目的として、適切なものはどれか。【ITパスポート 解説】

正解の理由

• 命名規則やコメントが統一されていると、別の人や未来の自分がコードを読んで意味が分かりやすくなります（可読性＝readability が向上します）。
• 可読性が上がると、バグ修正や機能追加といった「保守作業」を速く・安全に行えます。つまり、目的は「保守性を上げること」です。

解法ステップ

1. 問題文のキーワードを拾う：「変数の命名規則」「コメントの書き方」「標準的な記述方式」 → これは「コードの書き方のルール（コーディング規約）」を指すと判断する。
2. コーディング規約の目的を思い出す：読みやすさ（可読性）と一貫性を保ち、保守を楽にする。
3. 選択肢を照らし合わせる：保守性に直接結びつくものを選ぶ。
4. 他の選択肢が目的に合うかを検証して除外する。

選択肢別の誤答解説

• ア: いつ、どのようなテストを行うかを明確にすること
  → テスト計画は「テストポリシー」や「テスト計画書」の仕事です。コーディング規約はテストの実施時期や方法を指定するものではありません。
• イ: ソフトウェアコード作成の前提となる仕様書の品質を向上させること
  → 仕様書（システムが何をすべきかを書く文書）の品質向上は要件定義やレビューの領域です。コーディング規約は「仕様をどう実装するか」ではなく、実装（コード）の書き方を定めます。
• ウ: ソフトウェアコードの保守性を向上させること
  → 正解。命名規則やコメント、インデントなどは可読性を高め、修正や拡張をしやすくします。
• エ: データベース設計の品質を向上させること
  → データベース設計（テーブル構造や正規化など）は別の設計規約や設計手法の領域です。コーディング規約は主にプログラムコード自体の書き方に関係します。

よくある誤解

1. 「コーディング規約はバグを直接減らす」
   → 規約自体がバグを自動で直すわけではありません。むしろ、可読性が上がりバグの発見・修正がしやすくなるという間接的な効果です。
2. 「仕様書が良ければコーディング規約は不要」
   → 仕様書は何を作るか（要件）を決めます。規約はどう書くか（実装方法）を統一します。両方必要で役割が違います。
3. 「コメントをたくさん書けば保守性が高まる」
   → コメントは有用ですが、意味のないコメントや古くなったコメントは逆に混乱を招きます。良い命名＋必要最小限のコメントが理想です。

補足コラム

• コーディング規約の具体例
  • 命名規則：変数はキャメルケース（例：userName）にする、定数は大文字＋アンダースコア（例：MAX_COUNT）にする。
  • コメント：関数の役割と引数・戻り値の説明を必ず書く。なぜその実装にしたか（理由）を書いておくと良い。
  • インデントや改行、ファイルの構成を統一する。
• ツールの利用例
  • リンター（linter：静的解析ツール）を使うと、規約違反やミスの兆候を自動検出できます。
• 初学者への実践アドバイス
  • チームの既存規約に従うことが最優先。個人の好みで変えない。
  • 意味のある名前を付ける（例：i より userCount の方が何を表すか一目瞭然）。簡単なルールを守るだけで読みやすさが劇的に変わります。

# 悪い例
a = 10
b = 20
c = a + b

# 良い例
item_price = 10    # 商品の単価
quantity = 20      # 個数
total_price = item_price * quantity

FAQ