はじめてのC言語：コメントの書き方の基本と注意点を解説

2025年8月19日2025年9月11日

C言語

C言語のコメントは、プログラムの動作には影響を与えずに、意図や注意点、メモをソースコード内に残すための仕組みです。

初心者のうちは書き方のルールや注意点を誤解しやすいので、基本から実用テクニック、避けるべき落とし穴まで段階的に解説します。

読みやすく安全なコメントは、将来の自分と仲間への最高の贈り物です。

目次 [ close ]

C言語のコメントの基本

コメントとは何か

コメントはソースコード中に書く注釈のことで、コンパイラによって無視されます。

つまり、コメントの有無でプログラムの実行結果は変わりません。

意図を説明したり、設計上の理由や注意事項を記録するために使います。

「なぜそう書いたのか」を残すことが特に重要です。

コメントの種類(//, /* */)

C言語では主に2種類のコメントがあります。

行コメント: // 以降、その行の終わりまで。C99以降で導入されました。
ブロックコメント: /* から */ まで。複数行にまたがれます。

古いC89コンパイラでは//が使えない場合がありますが、現在よく使われるコンパイラ(Clang、GCC、MSVC)では通常有効です。

コメントを書く目的と効果

コメントには次のような効果があります。

第一に、後から読んだときに判断を再現できるようにします。

第二に、注意点(境界条件、パフォーマンス、依存関係)を明示します。

第三に、外部仕様やAPIの使い方をコードの近くに一元化します。

コードから読み取れる「何をするか」ではなく、「なぜそうするか」を書くのが良い習慣です。

コメントの書き方(基本文法)

行コメント(//)の書き方

行コメントは、その行の//以降がすべてコメントになります。

短い補足や末尾注記に向いています。

C言語

#include <stdio.h>

int main(void) {
    printf("Hello, World!\n"); // 画面に挨拶を表示します
    return 0; // 正常終了
}

実行結果

Hello, World!

ブロックコメント(/* … */)の書き方

ブロックコメントは/から/までがコメントです。

複数行にわたって説明したいときに使います。

C言語

#include <stdio.h>

/*
  ここはブロックコメントです。
  複数行にわたる詳しい説明や
  手順、参考URLなどを書けます。
*/
int main(void) {
    printf("multi-line comment demo\n");
    return 0;
}

実行結果

multi-line comment demo

複数行コメントの作り方

複数行の説明を行コメントで書く場合は、各行の先頭に//を付けます。

履歴やメモを一時的に残す場合に読みやすくなります。

C言語

// 仕様メモ:
// - 入力は整数のみを受け付ける
// - 範囲は1〜100
// - 範囲外はエラー表示

ブロックコメントを使う場合は通常通りです。

C言語

/*
  仕様メモ:
  - 入力は整数のみ
  - 範囲は1〜100
  - 範囲外はエラー
*/

コメント内の記号の扱い(*/ に注意)

ブロックコメントの中に*/という並びを含めると、意図せずコメントが終了します。

回避例を示します。

C言語

/*
  終了トークン(*/ )をそのまま書くとコメントが終わるので注意。
  安全な書き方の例: * / と分割する、または "*/" のように文字列として書く。
  例: 終了トークンは * / です。
*/

使い分けと実用テクニック

行コメントとブロックコメントの使い分け

行コメント: 短い補足、行末メモ、変数や式の意味の簡潔な説明に向いています。近年は主流です。
ブロックコメント: 関数やモジュールの長めの説明、ライセンス表記、非アクティブ化したい大きな説明ブロックに向いています。

次の表は特徴の比較です。

種類	主な用途	長所	注意点
// 行コメント	短い注記	タイピングが軽い、差分が見やすい	C89では不可の場合あり
/* … */	詳細説明、ヘッダ、Doxygen	複数行OK、整形しやすい	*ネスト不可、/ に注意**

コードの一時無効化(コメントアウト)

小さな範囲を無効化するならブロックコメントで十分です。

しかし、大きな範囲を無効化する場合は#if 0 ... #endifを使うと安全です。

ブロックコメントはネストできず、内部に*/があると壊れるからです。

C言語

#include <stdio.h>

int main(void) {
    printf("A\n");

#if 0
    // ここは一時的に無効化
    printf("B\n");
    /*
      ここにブロックコメントがあってもOK
      #if 0 はネストに強い
    */
#endif

    printf("C\n");
    return 0;
}

実行結果

A
C

関数/変数への説明コメントの付け方

関数の目的、前提条件、戻り値、例外的な挙動を簡潔に書きます。

「何を」「なぜ」「いつ」を意識します。

C言語

#include <stddef.h>

/* 配列の平均値を計算します。
   前提: arr != NULL, n > 0
   注意: オーバーフロー対策のため一時的にdoubleで加算します。 */
double mean_int(const int *arr, size_t n) {
    double sum = 0.0; // 合計(精度確保のためdouble)
    for (size_t i = 0; i < n; ++i) {
        sum += arr[i];
    }
    return sum / (double)n;
}

変数にも短い説明を添えると読みやすくなります。

C言語

int retry_count = 3; // 最大リトライ回数

Doxygenスタイル(/** */)の基本

ドキュメント生成ツールDoxygenは/** ... */形式のコメントを特別扱いします。

コンパイラからは通常のブロックコメントとして無視されるので安心です。

C言語

/**
 * @brief 2つの整数を加算します。
 * @param a 1つ目の加数
 * @param b 2つ目の加数
 * @return a + b の結果
 * @note オーバーフローは未定義です。必要ならlong long等を検討してください。
 */
int add(int a, int b) {
    return a + b;
}

よく使うタグは@brief、@param、@return、@noteです。

TODO/FIXMEコメントの使い方

未対応項目はTODO、既知の不具合はFIXMEとして明確に残します。

検索しやすい接頭辞と担当や期日をセットで書くと管理が楽になります。

C言語

// TODO(you, 2025-09-30): 範囲チェックを厳密化する
// FIXME: 符号付き/無しの比較で警告が出るケースを解消する

注意点とベストプラクティス

ブロックコメントはネスト不可

/* … */ は入れ子にできません。

次のような入れ子は途中で終了してしまい、以降のコードが壊れます。

安全に無効化したいときは#if 0 ... #endifを使いましょう。

C言語

/* 外側
    /* 内側 ← ここで外側が終わってしまう */
    以降はコードとして解釈されてしまう
*/

文字列内の // や /* はコメントではない

文字列や文字リテラルの中にある//や/*はコメントではありません。

次の例は正しく動作します。

C言語

#include <stdio.h>

int main(void) {
    // URLに // が含まれてもOK (これはコメント)
    printf("Visit: http://example.com/\n"); // 行末コメント
    printf("C-style token: /* not a comment inside string */\n");
    return 0;
}

実行結果

Visit: http://example.com/
C-style token: /* not a comment inside string */

マクロ/プリプロセッサとコメントの落とし穴

プリプロセッサでは、\による行継続やマクロのトークン連結とコメントが絡むと崩れることがあります。

マクロの中で改行をコメントで消すような書き方は避けるのが無難です。

C言語

// 悪い例: バックスラッシュ直後のコメントは可読性を損ねやすい
#define SUM(a, b) \
    ((a) + (b)) /* 行継続の直前や直後にコメントを置くと見落としの元 */

// 良い例: 行の区切りを明確にし、コメントは行末や前行に置く
#define SUM_OK(a, b) \
    ((a) + (b)) // aとbの和

また、マクロでコード塊を一時無効化したい場合、#if 0の方が安全です。

入れ子のコメントアウトを避ける

コード内に既にブロックコメントがある状態で、さらに外側をブロックコメントで囲むとネスト不可により破綻します。

大きなスコープの一時停止は#if 0 ... #endifを使うのが確実です。

冗長なコメントを避ける

コードから自明なことは書かないのが原則です。

例えばi = i + 1; // iに1を足すのようなコメントは不要です。

代わりに、意図や理由、境界条件、性能上の配慮など、コードだけでは伝わりにくい情報を記述しましょう。

日本語コメントと文字コードの注意点

日本語コメントは可読性に寄与しますが、文字コードの取り扱いに注意します。

プロジェクト全体でUTF-8(できればBOMなし)に統一するとトラブルが減ります。

MSVCの場合: /utf-8オプションでソースの文字コードをUTF-8として扱えます。
GCCの場合: -finput-charset=UTF-8、実行文字セットに関わる場合は-fexec-charset=UTF-8も検討します。
Clangの場合: 一般にUTF-8前提ですが、エディタ側でUTF-8保存を徹底します。

コメントは実行時には消えますが、ソース管理や差分表示で文字化けするとレビューが困難になります。

エディタとリポジトリの設定を合わせましょう。

ファイル先頭のライセンスコメントの扱い

ソースの先頭にライセンス文をブロックコメントで記載する慣習があります。

最近はSPDX識別子で簡潔にする方法も広まっています。

C言語

/*
 * SPDX-License-Identifier: MIT
 * Copyright (c) 2025 Aetheria
 */
#include <stdio.h>

int main(void) {
    printf("licensed\n");
    return 0;
}

実行結果

licensed

ライセンス表記は自動ツールが検出しやすい書式に統一し、毎ファイル同じ形式で維持します。

まとめ

コメントはコードの意味を補う説明書きであり、「なぜそうするか」を伝える最重要のドキュメントです。

行コメント//とブロックコメント/* ... /を用途で使い分け、ブロックコメントのネスト不可や/の扱いなどの落とし穴を避けましょう。

大きな無効化には#if 0 ... #endifが安全で、APIにはDoxygenスタイルが有効です。

日本語コメントはUTF-8で統一し、ライセンス表記はSPDXで簡潔に保つと管理が容易になります。

今日から、過不足のない、将来の読者に優しいコメントを書く習慣を身につけていきましょう。