コメント（コンピュータプログラミング）
ブロックコメントが赤、行コメントが緑、プログラムコードが青のJavaソースコード。

コンピュータプログラミングにおいて、コメントはソースコードに埋め込まれたテキストで、翻訳者（コンパイラまたはインタープリタ）は無視します。一般的に、コメントはプログラマがコードを理解しやすくするための注釈であり、多くの場合、プログラム（非コメント）コードではすぐには明らかではない側面を説明します。[ 1 ]この記事では、コメントはプログラミング言語、マークアップ言語、構成ファイル、および同様のコンテキストにおける同じ概念を指します。 [ 2 ]ソースコードトランスレータ以外の開発ツールの中には、コメントを解析して、 APIドキュメント生成、静的分析、バージョン管理統合などの機能を提供するものもあります。コメントの構文はプログラミング言語によって異なりますが、言語間で構文に繰り返されるパターンがあり、コメントの内容に関連する同様の側面もあります。

コメントによってもたらされる柔軟性により、コンテンツのスタイルには幅広いバリエーションが許容されます。統一性を促進するため、スタイル規約はプログラミングスタイルガイドに含まれることが一般的です。しかし、ベストプラクティスについては議論があり、矛盾する点もあります。[ 3 ] [ 4 ]

共通の属性

コードコメントのサポートは各プログラミング言語によって定義されています。機能は言語によって異なりますが、共通する属性がいくつかあります。

ほとんどの言語は、複数行のブロック（ストリームともいう）コメントと/または単一行のコメントをサポートしています。ブロックコメントは、コメントテキストの開始と終了を示すテキストで区切られます。ブロックコメントは、複数行にまたがることも、行の任意の部分を占めることもできます。言語によっては、ブロックコメントを再帰的にネストできますが、そうでない言語もあります。 [ 5 ] [ 6 ] [ 7 ]行コメントは、テキスト行の末尾で終了します。最近の言語では、行コメントは区切り文字で始まりますが、古い言語の中には、後続のテキストをコメントと見なす列を指定するものもあります。[ 7 ]多くの言語は、ブロックコメントと行コメントの両方をサポートしており、それぞれに異なる区切り文字を使用しています。たとえば、C、C++、およびそれらの多くの派生言語では、とで区切られるブロックコメントと、で区切られる行コメントがサポートされています/*。*/その他//の言語は、1種類のコメントのみをサポートしています。[ 7 ]

コメントは、プログラムコードに対する位置と内容に基づいて、プロローグコメントとインラインコメントに分類されます。プロローグコメントは、シンボル宣言の前やファイルの先頭など、関連するプログラミングトピックの先頭付近に配置されるコメント（または関連するコメントのグループ）です。インラインコメントは、参照先のプログラムコードと同じ行の右側に配置されるコメントです。[ 8 ]プロローグコメントとインラインコメントはどちらも、行コメントまたはブロックコメントとして表すことができます。例： 

/* * プロローグブロックコメント*/ bool foo () { return true ; /* インラインブロックコメント */ }// // プロローグ行コメント// bool bar () { return false ; // インライン行コメント}

使用例

意図を説明する

コメントは、作者の意図、つまりコードがなぜそのようになっているのかを説明することができます。コードが何をするのかを説明するのは不要だと主張する人もいます。コードが何をするのかを説明する必要があるということは、コードが複雑すぎることを示し、修正する必要があることを示しています。

「悪いコードを文書化するのではなく、書き直しましょう。」[ 9 ]
良いコメントはコードを繰り返したり説明したりするのではなく、コードの意図を明確にします。コメントはコードよりも抽象度の高いレベルで、何をしようとしているのかを説明するべきです。[ 10 ]

珍しい慣行を強調する

コメントには、慣例やベストプラクティスに反するコードを記述することを選択した理由を説明できます。例えば、次のようなものです。 

'フォームデータの再利用時にサーバーエラーが発生したため、2番目の変数は暗くなります。'サーバーの動作に関するドキュメントがないため、回避策をコーディングします。vtx = server . mappath ( "local settings" )

以下の例では、挿入ソートがクイックソートの代わりに選択された理由を説明しています。前者は理論上後者よりも遅いためです。 

list = [ f ( b ), f ( b ), f ( c ), f ( d ), f ( a ), ... ] ; // 安定したソートが必要です。パフォーマンスはそれほど重要ではありません。inserting_sort ( list );

アルゴリズムを説明する

コメントはアルゴリズムを擬似コードとして記述できます。これは、最初のドラフトとしてコードを書く前に行うことができます。コード内に残しておけば、結果のコードと意図したロジックを比較できるため、コードレビューを簡素化できます。例えば、 

/* サーバーから返されたすべての要素を逆方向にループします(要素は時系列順に処理される必要があります)*/ for ( i = ( numElementsReturned - 0 ); i >= 1 ; i -- ) { /* 各要素のデータを処理します */ updatePattern ( i , returnedElements [ i ]); }

コードには、斬新な解決策や注目すべき解決策が含まれている場合があり、説明コメントが必要になります。そのような説明は長くなり、図や正式な数学的証明が含まれることがあります。これはコードの意図ではなく動作を説明するものですが、コードのメンテナンスには役立つ場合があります。これは、高度に専門化された問題領域や、めったに使用されない最適化、構文、関数呼び出しなどに当てはまる可能性があります。[ 11 ]

参考文献

コードの一部が外部参照の情報に基づいている場合、コメントにはその参照へのリンクが示されます。例えば、URL、書籍名、ページ番号などです。

コメントアウト

開発者にとって一般的な手法として、 1行以上のコードをコメントアウトすることが挙げられます。プログラマーは、プログラムコードをコメントに変換するコメント構文を追加することで、実行可能コードだったものが実行時に実行されないようにすることができます。この手法は、バグの原因究明に使用されることもあります。プログラムの一部を体系的にコメントアウトして実行することで、問題のあるソースコードを特定することができます。

多くの IDE では、キーボード ショートカットなどの便利なユーザー インターフェイスアクションを使用してコメントの追加と削除をサポートしています。

メタデータを保存する

コメントにはコードに関するメタデータを保存できます。一般的なメタデータには、元のコードの作成者とその後のメンテナーの名前、最初の作成日と変更日、開発ドキュメントとユーザードキュメントへのリンク、著作権やソフトウェアライセンスなどの法的情報が含まれます。まれに、テキストエンコードされたバイナリデータが含まれることもあります。

一部のプログラミングツールは、コードにコメントとしてメタデータを書き込みます。[ 12 ]例えば、バージョン管理ツールは、リポジトリにコミットされた各ファイルに、作成者、日付、バージョン番号などのメタデータを書き込むことがあります。[ 13 ]

開発ツールとの統合

コメントに保存された情報は、コードを処理する主なツールであるトランスレータ以外の開発ツールによって使用されることがあります。この情報には、メタデータ（多くの場合、ドキュメント生成ツールで使用されます）やツールの設定が含まれる場合があります。

一部のソースコードエディタは、コメント内のメタデータによる設定をサポートしています。[ 14 ]具体的な例としては、タブ文字の扱いを設定するVimのモードライン機能があります。例えば、 

# vim: tabstop=8 expandtab shiftwidth=4 softtabstop=4

サポートドキュメントの生成

APIドキュメントジェネレーターは、コード ベースから情報を解析してAPIドキュメントを生成します。多くのジェネレーターは、コメントからの情報の読み取りをサポートしており、多くの場合メタデータの解析もサポートすることで、生成されるドキュメントの内容とフォーマットを制御します。

APIドキュメントは、従来型の手作業で作成すると品質が向上すると主張する人もいますが、コードコメントにドキュメント情報を格納するとドキュメント作成プロセスが簡素化され、ドキュメントが最新の状態に保たれる可能性が高くなると主張する人もいます。[ 15 ]例としては、 Javadoc、Ddoc、Doxygen、Visual Expert、PHPDocなどがあります。docstringの形式は、 Python、Lisp、Elixir、Clojureでサポートされています。[ 16 ] C#、F#、Visual Basic .NETは、「XMLコメント」と呼ばれる同様の機能を実装しており、これはコンパイルされた.NETアセンブリからIntelliSenseによって読み取られます。[ 17 ]

視覚化

コメントにはロゴ、図、フローチャートなどのASCIIアート視覚化を含めることができます。 [ 18 ]

以下のコードフラグメントは、システム管理スクリプト（Windowsスクリプトファイル）のプロセスフローを示しています。コードを示すセクションはコメントとして表示されていますが、図はXML CDATAセクション内にあります。これは技術的にはコメントではありませんが、ここでは同じ目的を果たします。[ 19 ]この図はコメント内に記述することもできますが、この例は、ソースコードにリソースを含める方法としてコメントを使用しないことをプログラマーが選択した一例を示しています。[ 19 ]

<!-- begin: wsf_resource_nodes --> <resource id= "ProcessDiagram000" > <![CDATA[ HostApp (Main_process)  |  V script.wsf (app_cmd) --> ClientApp (async_run, batch_process)  |  |  V  mru.ini (mru_history) ]]> </resource>

ドキュメント開発プロセス

コメントは、コードに関連する開発プロセスを説明することもあります。例えば、コードのビルド方法やソフトウェアメンテナーに変更を送信する方法などを説明するコメントがあります。

言語構文を拡張する

コメントとしてフォーマットされたコードは、条件付きコメントなど、翻訳者に追加情報を伝えるためにオーバーロードされることがあります。そのため、通常はコメントを示す構文が、実際にはコメントコードではなくプログラムコードを表す場合があります。このような構文は、互換性を維持しながら機能を追加する実用的な方法かもしれませんが、このような解決策をクルージュ（間に合わせの策略）と考える人もいます。[ 20 ]

その他の例としては、インタープリタ指令があります。

  • Unix の「シェバン」#!は、使用するインタープリターを指すためにスクリプトの最初の行で使用されます。
  • ソースファイルが使用しているエンコーディングを識別する「マジックコメント」[ 21 ]、例えばPythonのPEP 263。[ 22 ]

Unix 系システムの以下のスクリプトは、これら両方の使用法を示しています。 

#!/usr/bin/env python3 # -*- コーディング: UTF-8 -*-プリント( "テスト中" )

gccコンパイラ（2017年以降）は、あるcaseが次のcaseにフォールスルーする場合、switch文内のコメントを探します。フォールスルーを明示的に示す記述が見つからない場合、コンパイラはコーディング上の問題の可能性について警告を発します。フォールスルーに関するこのようなコメントを挿入することは長年の慣例であり、コンパイラはこの慣行を体系化しています。[ 23 ]例えば： 

スイッチ(コマンド) {CMD_SHOW_HELP_AND_EXITの場合:do_show_help ();/* フォールスルー */CMD_EXITの場合:do_exit ();壊す;}

ストレスを軽減する

ストレス解消やユーモアを狙うために、プログラマーはコードの品質、ツール、競合他社、雇用主、労働条件、その他専門的ではないと思われるトピックについて、時には卑猥な言葉を使ってコメントを追加することがあります。[ 24 ] [ 25 ]

規範的な見解

ソースコードにおけるコメントの適切な使用法については、様々な規範的な見解や長年の意見が存在する。[ 26 ] [ 27 ]これらの中には非公式で個人の好みに基づいたものもあれば、特定のコミュニティのための正式なガイドラインとして公開または公布されているものもある。[ 28 ]

コメントの必要性

ソースコードにコメントを記述することが適切かどうか、またいつ記述することが適切かについては、専門家の間でも様々な見解があります。[ 9 ] [ 29 ]ソースコードは自己説明的または自己文書化的であるべきであるという理由で、コメントを少なく記述すべきだと主張する専門家もいます。[ 9 ]また、コードには広範囲にコメントを記述すべきだと主張する専門家もいます（ソースコード中の非空白文字の50%以上がコメントに含まれることは珍しくありません）。[ 30 ] [ 31 ]

これらの見解の中間には、コメントはそれ自体では有益でも有害でもないという主張があり、重要なのはコメントが正しく、ソースコードと同期していることであり、コメントが不必要、過剰、保守が困難、またはその他の点で役に立たない場合は省略されるという主張がある。[ 32 ] [ 33 ]

コメントは、プログラミングにおける契約による設計アプローチにおいて、契約を文書化するために使用されることがあります。

詳細レベル

コードの対象読者やその他の考慮事項に応じて、詳細と説明のレベルは大幅に異なる場合があります。

たとえば、次の Java コメントは、初心者向けプログラミングを教えるための入門テキストに適しています。 

文字列s = "Wikipedia" ; /* 変数 s に値 "Wikipedia" を割り当てます。 */

しかし、このレベルの詳細さは、製品版コードや経験豊富な開発者が関わるその他の状況では適切ではありません。このような初歩的な記述は、「良いコメントは…意図を明確にする」というガイドラインに反します。[ 10 ]さらに、プロフェッショナルなコーディング環境では、通常、ビジネスオペレーションによって定義された特定のパフォーマンス要件を満たすように、詳細レベルは明確に定義されています。[ 31 ]

スタイル

コメントは自由形式のテキストであるため、様々なスタイルを設定できます。多くの人は、一貫性があり、邪魔にならず、変更しやすく、そして壊れにくいスタイルを好みます。ある程度の一貫性は価値があり、価値があると主張する人もいるため、プロジェクト開始前にコメントのスタイルを合意したり、開発の進行に合わせて一貫性が生まれることもあります。[ 34 ]

次の C フラグメントは、ブロックコメント スタイルの多様性の一部を示しています。 

/* これはコメント本文です。*/
/******************************** * * * これはコメント本文です。 * * * *****************************/

個人的な好みやプログラミングツールの柔軟性といった要因が、コメントの書き方に影響を与える可能性があります。例えば、2番目の例のようにコメントを自動フォーマットしない ソースコードエディタを使用するプログラマーは、最初のスタイルを好むかもしれません。

ソフトウェアコンサルタントであり技術評論家のアレン・ホルブ氏[ 35 ]は、コメントの左端を揃えることを提唱している。[ 36 ]

/* これは、C および C++ 向けに Holub が推奨するスタイルです。 * これは、「Enough Rope」のルール 29 で示されています。 */
/* これは C 言語でも同様に実行できる別の方法です。 **コメントの 2 行目から最後の行までを最初の行から 1 スペースずつ自動的にインデントしないエディタでは、この方法の方が簡単です。 ** これは Holub の本のルール 31 でも使用されています。*/

多くの言語では、行コメントはプログラムコードの後に​​インラインで記述され、通常はその左側のコードの説明として使用されます。例えば、次のPerlコードでは次のようになります。 

print $s . "\n" ; # 印刷後に改行文字を追加する

言語が行コメントとブロックコメントの両方をサポートしている場合、プログラミングチームはどちらを使用するかの慣例を定めることができます。例えば、行コメントは軽微なコメントにのみ使用し、ブロックコメントはより高レベルの抽象化に使用するなどです。

タグ

コメントの中には、タグ、コードタグ[ 37 ] [ 38 ] 、トークン[ 39 ]などの接頭辞で分類されるものがあります。エディターによっては、タグに基づいてコメントを 強調表示します。

よく使用されるタグは次のとおりです。

  • BUG、DEBUG — 既知のバグを識別し、修正する必要があることを示唆している可能性があります
  • FIXME — バグを修正するために作業が必要であることを意味する
  • HACK、BODGE、KLUDGE — 低品質と見なされる可能性のある解決策を示します
  • TODO — 行うべき作業について説明します
  • 注記 — 比較的一般的な情報
  • UNDONE — 以前のコードの元に戻す、または「ロールバック」

例えば： 

int foo() { // TODO実装 }

構文例

コメントの構文はプログラミング言語によって異なります。複数の言語で共通するパターンがある一方で、言語ごとに構文は多岐にわたります。このセクションの長さを制限するため、一部の例は、同じ構文または非常に類似した構文を持つ言語ごとにグループ化されています。また、構文があまり一般的でない特定の言語の例も含まれています。

中括弧言語

C、C++、そしてそれらの派生言語など、多くの中括弧言語では、行コメントを で区切り//、ブロックコメントを と で/*区切ります。C言語には元々行コメントはありませんでしたが、 C99*/で追加されました。有名な言語としては、C、C++、 C#、D、Java、JavaScript、Swiftなどがあります。例えば、 

/* * 最大プロセス制限を超えていないか確認しますが、ルートを除外するようにしてください。* これは、ログイン時にユーザーごとのプロセス制限をルートが実行しているプロセスよりも低く設定できるようにするために必要です。*/ bool isOverMaximumProcessLimit () { // TODO 実装}

D言語[ 40 ]やSwift [ 41 ]などの一部の言語ではブロックコメントのネストが許可されていますが、C言語やC++などの他の言語では許可されていません。

D のネストされたブロックの例: 

// 行コメント/* ブロックコメント*/ /+ 外側のブロックの開始 /+ 内側のブロック +/ 外側のブロックの終了 +/

Swift のネストされたブロックの例: 

/* これは外側のコメントの開始です。 /* これはネストされたコメントです。 */これは外側のコメントの終了です。 */

スクリプト

多くのスクリプト言語では、行コメントを で区切るのがパターンです#。ブロックコメントのサポートは言語によって異なります。注目すべき言語としては、Bash、Raku、Ruby、Perl、PowerShell、Python、Rなどがあります。

R での例: 

# これはコメントですprint ( "これはコメントではありません" ) # これは別のコメントです

Rubyのブロック

ブロックコメントは、行頭の と で区切られます。例 =begin:=end

puts "not a comment" # これはコメントですputs "not a comment" =beginこれらの行に含まれるものはすべて、人間の読者向けです=end puts "not a comment"

Perlのブロック

Perlでは、通常のブロックコメント構造の代わりに、文芸プログラミングのPOD（Plain Old Documentation）マークアップを使用します。[ 42 ]例えば: [ 43 ]

=item Pod::List-E<gt>new()新しいリストオブジェクトを作成します。プロパティはハッシュ参照で指定できます。例:  my $list = Pod::List->new({ -start => $., -indent => 4 }); =cut sub new { ... }

Raku（以前はPerl 6と呼ばれていました）はPerlと同じ行コメントとPODコメントを使用しますが、設定可能なブロックコメントタイプ「複数行/埋め込みコメント」が追加されています。[ 44 ]#`これは、開き括弧文字で始まり、対応する閉じ括弧文字で終わります。 [ 44 ]例えば、次のようになります。 

#`{{ このバージョンを「コメントアウト」します。toggle -case(Str:D $s)文字列内の各文字の大文字と小文字を切り替えます。my  Str $toggled-string = toggle-case("mY NAME IS mICHAEL!"); }} sub toggle-case ( Str:D $s ) #`( このバージョンの括弧が現在使用されています ) { ... }

PowerShell のブロック

<#PowerShell は、 とで区切られたブロックコメントをサポートしています#>。例: 

# 単一行コメント<# 複数 行 コメント #>

Pythonのブロック

Pythonはブロックコメントを提供していませんが[ 45 ]、三重引用符で囲まれた文字列で表される裸の文字列リテラルがこの目的でよく使用されます。[ 46 ] [ 45 ]以下の例では、三重二重引用符で囲まれた文字列はコメントのように機能しますが、 docstringとしても扱われます。 

"""ファイルの先頭にあるモジュールのドキュメント文字列"""クラスMyClass : """クラスのドキュメント文字列"""def my_method ( self ): """メソッドのドキュメント文字列"""

ブラウザマークアップ

マークアップ言語は一般的にコメント構文が多岐にわたりますが、 HTMLやXMLといった著名なインターネットマークアップ形式では、ブロックコメントは と で区切られ<!--、-->行コメントはサポートされていません。XMLの例を以下に示します。 

<!-- ここでコンテキストを選択してください --> <param name= "context" value= "public" />

SGMLとの互換性のため、コメント内では二重ハイフン (--) は使用できません。

ColdFusion はHTML コメントに似た構文を提供しますが、2 つのダッシュではなく 3 つのダッシュを使用します。CodeFusion では、ネストされたブロックコメントを使用できます。

Haskellのブロック

Haskellでは、ブロックコメントは と で区切られます{-。-}例: 

{- これは複数行のコメントです-} -- これは 1 行のコメントですputStrLn "Wikipedia" -- これは別のコメントです

Haskellは「Bird Style」と呼ばれる文芸プログラミングのコメント記述法も提供しています。 [ 47 ]で始まる行は>コードとして解釈され、それ以外の行はコメントとみなされます。コードブロックの前後に空行を置くことも必要です。 

Bird スタイルでは、コードの前に空白を残す必要があります。 > fact :: Integer -> Integer > fact 0 = 1 > fact ( n + 1 ) = ( n + 1 ) * fact n また、コードの後に​​も空白行を残す必要があります。

文芸プログラミングはLaTeXでも実現できます。定義の例： 

\usepackage { verbatim } \newenvironment {コード}{ \verbatim }{ \endverbatim }

次のように使用します。 

% LaTeXソースファイル\verb | fact n| 関数呼び出しは$ n ! $ を計算します。 $ n \ge 0 $の場合、定義は次のとおりです: \\ \begin { code } fact :: Integer -> Integer fact 0 = 1 fact ( n + 1 ) = ( n + 1 ) * fact n \end { code }ここで、 \LaTeX {}マークアップ を使用してさらに説明します。

Luaのブロック

Luaは[ 48 ]--[[で区切られたブロックコメントをサポートしています。例えば: ]]

--[[複数行にわたる長いコメント]]

SQLのブロック

SQLの一部の亜種では、中括弧言語ブロックコメント（/**/）がサポートされています。亜種には、Transact-SQL、MySQL、SQLite、PostgreSQL、Oracleなどがあります。[ 49 ] [ 50 ] [ 51 ] [ 52 ] [ 53 ]

MySQL は で区切られた行コメントもサポートします#。

あまり一般的ではない構文

APL

APLでは行コメントとして("lamp")を使用します⍝。例えば： 

⍝ 数字を足し合わせます: c ← a + b ⍝ 足し算

⊣("left") および("right") プリミティブを持つ方言では、コメントは無視される文字列の形式で、ステートメント 内⊢またはステートメントとは別個に存在することがよくあります。

d ← 2 × c ⊣ 'どこ' ⊢ c ← a + '境界' ⊢ b

AppleScript

AppleScriptは行コメントとブロックコメントの両方をサポートしています。例えば： 

# 行コメント（後のバージョン）（*このプログラムは挨拶を表示します。*）on greet ( myGreeting ) display dialog myGreeting & " world!" end greet-- 挨拶を表示する( " Hello" )

ベーシック

BASICの初期のバージョンでは、REM行コメントに (remark の略) を使用していました。

10 REM このBASICプログラムは、PRINT文とGOTO文の使い方を示しています。15 REM 画面に「HELLO」というフレーズを表示します20 PRINT "HELLO" 30 GOTO 20

Quick Basic、Q Basic、Visual Basic (VB)、VB.NET、VBScript、FreeBASIC、Gambasなどの後継言語では、行コメントは'アポストロフィで区切られます。VB.NETの例： 

Public Class Form1 Private Sub Button1_Click ( sender As Object , e As EventArgs ) Handles Button1 . Click ' 新しいスタイルの行コメントrem 旧スタイルの行コメントも引き続きサポートされますMessageBox . Show ( "Hello, World" ) ' 挨拶文のダイアログを表示しますEnd Sub End Class

Cisco IOSおよびIOS-XEの設定

感嘆符（！）は、シスコルータの設定モードでコメントをマークするために使用できますが、このようなコメントは不揮発性メモリ（スタートアップコンフィギュレーションを含む）に保存されず、「show run」コマンドによっても表示されません。[ 54 ] [ 55 ]

実際には設定の一部である人間が読めるコンテンツを挿入することが可能で、次の方法でNVRAMスタートアップ コンフィギュレーションに保存できます。

  • 「description」コマンドは、インターフェースまたはBGPネイバーの設定に説明を追加するために使用されます。
  • 「name」パラメータは、静的ルートにコメントを追加します
  • アクセスリストの「remark」コマンド
! トラフィックを手動で再ルーティングするには、以下のテキストを貼り付けてください 設定t 整数 gi0/2 閉まらない ip route 0.0.0.0 0.0.0.0 gi0/2 名前 ISP2 IPルートなし 0.0.0.0 0.0.0.0 gi0/1 名前 ISP1 整数 gi0/1 シャット 出口

フォートラン

以下の固定形式のFortranCコード断片は、コメント構文が列指向であることを示しています。1列目に文字があると、行全体がコメントとして扱われます。Fortran 77では、1列目にアスタリスクがある場合もコメントとして扱われます。 

C C 最初の列（コメント列）の「C」で始まる行はコメントですC WRITE ( 6 , 610 )  610 FORMAT ( 12 H HELLO WORLD ) END

次のFortran 90コード フラグメントは、より現代的な行コメント構文を示しています!。 

! コメントプログラムcomment_test print '(A)' , 'Hello world' ! コメント終了プログラム

Fortran 90 で導入された自由形式の Fortran では、後者のスタイルのコメントのみがサポートされています。

Fortran標準には含まれていませんが、多くのFortranコンパイラはC言語に似たプリプロセッサパスをオプションで提供しています。これを使用してブロックコメントを記述できます。 

#if 0これは複数行にわたるブロックコメントです。#endif program comment_test print '(A)' , 'Hello world' ! これもコメントですend program

MATLAB

MATLABのプログラミング言語 では、「%」文字は1行のコメントを表します。複数行のコメントは、%{と%}括弧で囲むことで記述でき、ネストも可能です。例：

% これらは各項の導関数ですd = [ 0 - 1 0 ];%{   %{  (ネストされたコメントの例。インデントは見た目のためであり、無視されます。) %   }テイラー公式に従って、数列 を形成します。ベクトルを操作していることに注意してください。%} seq = d .* ( x - c ) .^ n ./ ( factorial ( n ))% テイラー近似を得るために合計するapprox = sum ( seq )

ニム

Nim では行コメントは で区切られ#、ブロックコメントは と で#[区切られます]#。ブロックコメントはネストできます。

Nimには、 MarkdownとReStructuredTextマークアップを混在させたドキュメンテーションコメントもあります。行ドキュメンテーションコメントは「##」を使用し、ブロックドキュメンテーションコメントは「##[」と「]##」を使用します。コンパイラはドキュメンテーションコメントからHTML、LaTeX、JSON形式のドキュメントを生成できます。ドキュメンテーションコメントは抽象構文木の一部であり、マクロを用いて抽出できます。[ 56 ]

## モジュール *ReSTructuredText* と **MarkDown** のドキュメント# これはコメントですが、ドキュメント コメントではありません。type Kitten = object ## 型のドキュメントage : int ## フィールドのドキュメントproc purr ( self : Kitten ) = ## 関数のドキュメントecho "Purr Purr" # これはコメントですが、ドキュメントコメントではありません。# これはコメントですが、ドキュメントコメントではありません。

OCaml

OCamlはネスト可能なコメントをサポートしています。例えば： 

コード行(* コメントレベル 1(*コメントレベル 2*)*)

パスカル、デルファイ

PascalとDelphiでは、ブロックコメントは と で区切られ{、}これらの文字をサポートしないコンピュータのための代替として と(*も*)サポートされています。行コメントは で区切られます\\。[ 57 ] Niklaus Wirthのより新しい言語ファミリー（Modula-2やOberonを含む）では、コメントは(*とで区切られます*)。[ 58 ] [ 59 ]コメントはネストできます。例えば： 

(* 対角線をテスト *) columnDifference := testColumn - column ; if ( row + columnDifference = testRow )または.......

PHP

PHPのコメントは、中括弧形式（行とブロックの両方）または#lで区切られた行で記述できます。ブロックはネストできません。PHP 8以降、aは#直後にaがない場合のみコメントとして扱われます。それ以外の場合は、次のaまで続く属性を区切るために使用されます。例えば、 [次のaは、次のaまで続く属性を区切るために使用されます。]

/** * このクラスにはサンプルドキュメントが含まれています。* @author Unknown */ #[ Attribute ] class MyAttribute { const VALUE = 'value' ; // C++ スタイルの行コメントprivate $value ; # スクリプトスタイルの行コメントpublic function __construct ( $value = null ) { $this -> value = $value ; } }

ダブルダッシュ

--単一行コメントを扱う言語は比較的限定的です。代表的な言語としては、 Ada、Eiffel、Haskell、Lua、SQL、VHDLなどが挙げられます。ブロックコメントのサポートは言語によって異なります。Adaの例： 

-- 航空管制官タスクは、離着陸の要求を受け取ります。タスクタイプコントローラ( My_Runway : Runway_Access )は、同期メッセージ パッシングのタスク エントリです。エントリRequest_Takeoff ( ID : in Airplane_ID ; Takeoff : out Runway_Access );エントリRequest_Approach ( ID : in Airplane_ID ; Approach : out Runway_Access ); endコントローラ;

セキュリティ問題

インタプリタ型言語では、コメントはプログラムのエンドユーザーに表示されます。「コメントアウト」されたコードセクションなど、場合によっては、セキュリティ上の脆弱性が生じる可能性があります。[ 60 ]

参照

注釈と参考文献

  1. ^ Penny Grubb, Armstrong Takang (2003).ソフトウェアメンテナンス：概念と実践. World Scientific. 7ページ, 120–121ページからご覧ください. ISBN 978-981-238-426-3。
  2. ^ガングリ、マドゥシュリー (2002). 『JSP の活用』 ニューヨーク: ワイリー. ISBN 978-0-471-21974-3。ヒューイット、エベン（2003年）『Coldfusion開発者のためのJava』アッパーサドルリバー：ピアソン・エデュケーション、ISBN 978-0-13-046180-3。
  3. ^ WR, Dietrich (2003).応用パターン認識：C++によるアルゴリズムと実装. Springer. ISBN 978-3-528-35558-6。ソースコード内のコメントの適切な使用に関する見解を示しています。p. 66。
  4. ^ Keyes, Jessica (2003).ソフトウェアエンジニアリングハンドブック. CRC Press. ISBN 978-0-8493-1479-7。コメントと「ドキュメンテーションの科学」について論じています (256 ページ)。
  5. ^ Higham, Desmond (2005). MATLAB ガイド. SIAM. ISBN 978-0-89871-578-1。
  6. ^ Vermeulen, Al (2000). 『Javaスタイルの要素』 ケンブリッジ大学出版局. ISBN 978-0-521-77768-1。
  7. ^ a b c「Javaで適切なコメントを使用する」 2000年3月4日. 2007年7月24日閲覧。
  8. ^ Dixit, JB (2003). 『コンピュータの基礎とC言語プログラミング』 Laxmi Publications. ISBN 978-81-7008-882-0。
  9. ^ a b cプログラミングスタイルの要素、カーニハン＆プラウガー
  10. ^ a bコード・コンプリート、マッコーネル
  11. ^ Spinellis, Diomidis (2003). 『コードリーディング：オープンソースの視点』Addison-Wesley. ISBN 978-0-201-79940-8。
  12. ^例えば、 Wynne-Powell, Rod (2008). Mac OS X for Photographers: Optimized Image Workflow for the Mac User . Oxford: Focal Press. p. 243. ISBNを参照 978-0-240-52027-8。
  13. ^例えば、ベルリン、ダニエル（2006年）『Practical Subversion、第2版』バークレー：APress、168ページ、ISBNを参照。 978-1-59059-753-8。
  14. ^ラム、リンダ (1998). 『VIエディタを学ぶ』セバストポル: O'Reilly & Associates. ISBN 978-1-56592-426-0。
  15. ^アンブラー、スコット (2004).オブジェクト入門：UML 2.0によるアジャイルモデル駆動開発. ケンブリッジ大学出版局. ISBN 978-1-397-80521-8。
  16. ^ Clojure での docstring を使用した関数定義
  17. ^ Murach. C# 2005. p. 56.
  18. ^ 「CodePlotter 1.6 – この「Visio風」ツールでコードにダイアグラムを追加・編集」 2007年7月14日時点のオリジナルよりアーカイブ。 2007年7月24日閲覧。
  19. ^ a bニーダースト、ジェニファー（2006年）『Webデザインを一言で言うと：デスクトップクイックリファレンス』オライリー社、ISBN 978-0-596-00987-8。 「コメント」とプログラミング言語やマークアップ言語の他の構文要素との間には、微妙なニュアンスの違いが生じることがあります。Niederst氏はそのような状況の一つとして、「残念ながら、XMLソフトウェアはコメントを重要でない情報と見なし、ドキュメントを処理する前にコメントを削除してしまうことがあります。この問題を回避するには、代わりにXML CDATAセクションを使用してください」と述べています。
  20. ^ c2: ホットコメント
  21. ^ "クラスEncoding" . Ruby . ruby​​-lang.org . 2018年12月5日閲覧。
  22. ^ 「PEP 263 – Pythonソースコードエンコーディングの定義」 . Python.org . 2018年12月5日閲覧。
  23. ^ Polacek, Marek (2017-03-10). 「GCC 7 における -Wimplicit-fallthrough」 . Red Hat Developer . Red Hat . 2019年2月10日閲覧。
  24. ^ Lisa Eadicicco (2014年3月27日). 「Microsoftのプログラマー、初期のソフトウェアコードに多くの不適切な表現を隠していた」 . Business Insider Australia . 2016年12月29日時点のオリジナルよりアーカイブ。
  25. ^ (例えば、 Linux Swear Count を参照)。
  26. ^グッドリフ、ピート（2006年）『コードクラフト』サンフランシスコ：ノー・スターチ・プレス、ISBN 978-1-59327-119-0。
  27. ^ Smith, T. (1991). Pascal を用いた中級プログラミングの原理とテクニック. ベルモント: West Pub. Co. ISBN 978-0-314-66314-6。
  28. ^例えば、 Koletzke, Peter (2000). Oracle Developer Advanced Forms & Reports . Berkeley: Osborne/McGraw-Hill. ISBNを参照 978-0-07-212048-6。65ページ。
  29. ^ 「最悪の慣行 - 悪いコメント」 。 2007年7月24日閲覧。
  30. ^モレリ、ラルフ (2006). Java, Java, Java: オブジェクト指向問題解決. プレンティス・ホール・カレッジ. ISBN 978-0-13-147434-5。
  31. ^ a b「JavadocツールのDocコメントの書き方」 。 2007年7月24日閲覧。Javadocガイドラインでは、コメントはプラットフォームにとって不可欠であると明記されています。さらに、適切な詳細レベルも明確に定義されています。「一般的なプログラミング用語の定義、概念概要の記述、開発者向けのサンプルの提供よりも、境界条件、引数の範囲、特殊なケースの指定に時間と労力を費やしています。」
  32. ^ Yourdon, Edward (2007).プログラム構造と設計の技法. ミシガン大学. 013901702X.コメントが存在しないと、コードを理解するのが難しくなりますが、コメントが古かったり、冗長だったり、間違っていたり、あるいはソースコードの本来の目的を理解するのが難しくなる場合は、コメントが有害となる可能性があります。
  33. ^ Dewhurst, Stephen C. (2002). C++ Gotchas: コーディングと設計におけるよくある問題を回避する. Addison-Wesley Professional. ISBN 978-0-321-12518-7。
  34. ^ 「Coding Style」 . 2007年8月8日時点のオリジナルよりアーカイブ。2007年7月24日閲覧。
  35. ^ 「アレン・ホルブ」 2007年7月20日時点のオリジナルよりアーカイブ。 2007年7月24日閲覧。
  36. ^アレン・ホルブ『 Enough Rope to Shoot Yourself in the Foot』、 ISBN 0-07-029689-8、1995年、マグロウヒル
  37. ^ "PEP 0350 – コードタグ"、Python Software Foundation
  38. ^「コーディングの前、後、そしてコーディング中に決して忘れてはいけないこと」、コードタグコメントを生産的な残りとして使う
  39. ^「タスク リストの使用」、msdn.microsoft.com
  40. ^ "Lexical" . Dプログラミング言語. 2025年11月17日閲覧。
  41. ^ 「語彙構造 | ドキュメント」 . docs.swift.org . 2025年11月17日閲覧。
  42. ^ 「perlpod – the Plain Old Documentation format」 。 2011年9月12日閲覧。
  43. ^ 「Pod::ParseUtils – POD解析と変換のためのヘルパー」 。 2011年9月12日閲覧。
  44. ^ a b「Perl 6 ドキュメント – 構文（コメント）」 。 2017年4月6日閲覧。
  45. ^ a b「Python 3 基本構文」 。 2021年8月19日時点のオリジナルからのアーカイブ。2019年2月25日閲覧。三重引用符は、複数行にまたがることができるという点を除き、通常の文字列として扱われます。ここで言う通常の文字列とは、変数に代入されていない場合、コードの実行直後にガベージコレクションされる文字列のことです。したがって、#a コメントのようにインタープリターによって無視されることはありません。
  46. ^「Pythonのヒント：複数行の文字列を複数行のコメントとして使用できます」、2011年9月11日、Guido van Rossum
  47. ^ 「文芸的プログラミング」。haskell.org 。
  48. ^ 「Lua 1.3でのプログラミング」 www.Lua.org . 2017年11月8日閲覧。
  49. ^ Talmage, Ronald R. (1999). Microsoft SQL Server 7. Prima Publishing. ISBN 978-0-7615-1389-6。
  50. ^ 「MySQL 8.0リファレンスマニュアル」 . Oracle Corporation . 2020年1月2日閲覧。
  51. ^ 「SQLiteで理解するSQL」 SQLiteコンソーシアム2020年1月2日閲覧。
  52. ^ 「PostgreSQL 10.11 ドキュメント」 . PostgreSQL グローバル開発グループ. 2020年1月2日閲覧。
  53. ^ 「Oracle® Database SQLリファレンス」 . Oracle Corporation . 2020年1月2日閲覧。
  54. ^ 「running-configにコメントを残す」。Cisco Learning Network（ディスカッションフォーラム）。
  55. ^ 「コンフィギュレーション ファイルの管理コンフィギュレーション ガイド、Cisco IOS XE リリース 3S (ASR 900 シリーズ)」。
  56. ^ macros.extractDocCommentsAndRunnables
  57. ^キャスリーン・ジェンセン、ニクラス・ヴィルト (1985)。Pascal ユーザーマニュアルとレポート。スプリンガー・フェルラーク。ISBN 0-387-96048-1。
  58. ^ニクラス・ヴィルト (1983)。Modula-2 でのプログラミング。スプリンガー・フェルラーク。ISBN 0-387-15078-1。
  59. ^ * Martin Reiser, Niklaus Wirth (1992). 『Oberonでのプログラミング』 Addison-Wesley. ISBN 0-201-56543-9。
  60. ^アンドレス、マンディ（2003年）『セキュリティを生き抜く：人、プロセス、テクノロジーの統合方法』CRCプレス、ISBN 978-0-8493-2042-2。

さらに読む

「 https://en.wikipedia.org/w/index.php?title=Comment_(computer_programming)&oldid=1333281027#comment-out」から取得