ネストされたコメントの問題を解決する方法

1つの言語だけでなく、コメントをネストできないように見えます。この問題の良い解決策はありますか？C / C ++およびJavaでの1つの回避策は、単一行コメントのみを使用することですが、より大きなブロックをコメントアウトすることは不可能になります。私はこのようなものに直面しています：

</li><!--
                <li><!-- Save -->

そのため、コメントを手動で確認して編集する必要があります。多くの言語でこれをどのように扱うべきかアドバイスをいただけますか？私にはわからないが、多分、Pythonにコメント'''を含めることができるかもしれない方法でこれを解決できるの#でしょうか？`

最良の解決策は、明らかに、コメントを入れ子にしないことです。ネストされたコメントは通常、間違ったコメントを使用していることを示しています。最も一般的な例は、コメント自体を含むコメントアウトされたコードです。修正するには、コメントアウトする代わりにコードを削除します。

ただし、多くのプログラミング言語には複数のタイプのコメント構文があり、この事実を使用して少なくとも1レベルの深さまでネストできます。たとえば、Javaの場合：

/* This is commented out!
Foo.bar.baz();
// And now for something completely different...
Quux.runWith(theMoney);
*/

また、多くの言語では、少なくとも1種類のコメントが一種のネスト可能です。Cライクな言語では、行コメント内の行コメントは無視されます。

// some_commented_out(code);
// // This is a comment inside the comment!
// // Still inside the nested comment.
// some_more_code_in(outer_comment);

ほとんどのIDEは、1つのアクションで行コメントを使用してコードブロック全体のコメントをサポートし、この種のコメントスタイルを正しく処理します。Pythonの同じ例：

# some_commented_out(code)
# # This is a comment inside the comment!
# # Still inside the nested comment.
# some_more_code_in(outer_comment)

多くの場合、特定のプロジェクトのコーディング標準には、どのコメントスタイルをいつ使用するかに関するルールがあります。一般的な慣習は/* */、メソッドとクラスのドキュメントにブロックコメント（）を使用し、//メソッド本体などのコメントにインラインコメント（）を使用することです。

/**
 * Helper class to store Foo objects inside a bar.
 */
public class Foobar {
    /**
     * Stores a Foo in this Foobar's bar, unless the bar already contains
     * an equivalent Foo.
     * Returns the number of Foos added (always 0 or 1).
     */
    public int storeFoo(Foo foo) {
        // Don't add a foo we already have!
        if (this.bar.contains(foo)) {
            return 0;
        }
        // OK, we don't have this foo yet, so we'll add it.
        this.bar.append(foo);
        return 1;
    }
}

このようなスタイルでは、/* */コメントをネストする必要はほとんどありません（メソッドまたはクラス全体を一時的に無効にする必要がある場合、それらの名前を変更しても同じようにうまく機能します）。少なくともIDEの助けが//あれば、コメントが入れ子になります。

最後に、コードを無効にするには、多くのプログラミング言語で他のオプションがあります。たとえば、Cでは、プリプロセッサを活用できます。

this_is(activated);
#if 0
this_is(!activated);
/* Comments inside this block don't really nest, they are simply removed
   along with the rest of the block! */
#endif

動的言語では、多くの場合、if代わりに通常のステートメントを使用できます。

<?php

if (0) {
   // This should never run... 
   some_stuff_that_should_never_run();
}

ただし、CPPの例とは異なり、この戦略ではソースファイル全体が構文的に有効である必要があるため、柔軟性がはるかに低くなります。

最後に、ネストされたコメントを許可する言語が少なくともいくつかあります。興味のある方のために、ウィキペディアにはすばらしい比較表があります。

CおよびC ++には、ネストされたブロックコメントがあります。

#if 0
#endif

多くのハイライトエディターはこれをコメントとして理解し、他の多くのエディターは少なくとも他の条件付き無効コードとしてハイライトします。

他の多くの言語では、エディターのサポートに依存する必要があります。行ベースのコメントしか持たない言語（perl、python、ruby、shell ...）では、範囲内のすべての行にコメント文字を追加するのはかなり簡単なので、ほとんどのエディターがこれを行うことができます。コメント文字が2倍になっているため、ブロック全体をコメントアウトする前に、コメントが何であったかを引き続き確認できます。これを行うことは、ここでの利点です。

XMLとSGMLはおそらく最大の苦痛であり、コメントの定義はばかげています。コメントはネストするのは簡単でしたが、そうではないだけでなく、--内部コメントを持つことは完全に禁止されています。残念ながら、どのエディターがSGML / XMLでコメントアウトをサポートしているかわかりません。

一般的な解決策ではなく、確かに理想的でもありませんが、この特定の問題に取り組む1つの方法は、サーバー側のテンプレート処理言語を使用して、ネストされたコードコメント要素のコメントをブロックすることです。これにより、コンテンツは本質的にそのまま残りますが、クライアントブラウザーに送信できなくなります。

ファイルが他のサーバー側の処理を必要としないストレートで純粋なコンテンツである場合、それはあまり役に立ちません。その場合、およびネストされたコメントのより一般的なケースでは、なぜそうするのか尋ねてください。それらのほとんどの場合、それを処理する最良の方法は、すべてを処理しないことであることがわかります。つまり、セクションを削除する場合は、そのセクションを削除し、そのセクションをアーティファクトとして復活させる必要がある場合にバージョン管理に違いを記憶させます。

HTML / XMLの場合、存在しない処理命令を使用できます。SOに関する私の回答を参照してください。

<?ignore
  <band height="20">
    <staticText>
      <reportElement x="180" y="0" width="200" height="20"/>
      <text><![CDATA[Hello World!]]></text>
    </staticText>
  </band>
?>
</detail>

Swiftはネストされたコメントをサポートしているため、「コメントをネストできないのは1つの言語だけではない」ということは、もはや真実ではありません。プログラミング言語でネストされたコメントがサポートされていないことに不満がある場合は、Swiftを試してみることをお勧めします。

/* This is the start of the first multiline comment.
 /* This is the second, nested multiline comment. */
 This is the end of the first multiline comment. */

Swiftプログラミング言語：基本

Dプログラミング言語には、ネストされたコメントが組み込まれています。

/+ This is a nested comment 
  /+ This is part of that a comment +/
  /* So is this */
+/
/+ /* This is another nested comment */ +/
/* /* This is not a nested comment */

言い換えれば、/+と+/コメントの巣。