コードを無効にするための構文は、通常のコメントの構文と異なる必要がありますか？

開発中のいくつかの理由で、コードをコメントアウトすることがあります。私は無秩序で時々急いでいるので、これらのいくつかはそれをソース管理にします。

また、コメントを使用してコードのブロックを明確にします。

例えば：

MyClass MyFunction()
{
    (...)
    // return null; // TODO: dummy for now
    return obj;
}

これは「機能」し、多くの人がこのように実行しますが、コメント化されたコードとコードを明確にする「実際の」コメントを自動的に区別できないのは不愉快です。

• コードを読み取ろうとするとノイズが発生します
• たとえば、ソース管理のon-commitフックのコメントアウトされたコードを検索することはできません。

一部の言語は、複数の単一行コメントスタイルをサポートする-例えばPHPにすることができますいずれかを使用//または#単一行コメントのために-と開発者がコメントアウトコードのためにこれらのいずれかを使用に同意することができます：

# return null; // TODO: dummy for now
return obj;

他の言語-私が今日使用しているC＃など-は、単一行のコメントに対して1つのスタイルを持っています（そうですか？コンパイラディレクティブを使用した「コメントアウト」コードの例も見ました。これはコードの大きなブロックに最適ですが、ディレクティブには2つの新しい行が必要であるため、1行では少しやりすぎです。

#if compile_commented_out
    return null; // TODO: dummy for now
#endif
return obj;

したがって、コメントアウトコードはすべての（？）言語で発生するので、「無効化されたコード」は言語仕様で独自の構文を取得すべきではありませんか？プロの（コメントの分離/無効化されたコード、エディター/ソースコントロールがそれらに作用する）は十分であり、短所（「コメントアウトはすべきではない」）であり、言語の機能的な部分ではなく、潜在的なIDEラグ（Thomasに感謝） ））犠牲に値する？

編集する

私が使用した例はばかげています。ダミーコードは実際のコードに置き換えられるため、簡単に削除できます。

まず、あなたの例では「TODO」コメントがあります。これらのタイプのコメントは、IDE（少なくともEclipseおよびVisual Studio）によって「タスク」のマーカーとして検出されるため、ある意味で特別です。しかし、私はあなたがthmeを使用しているので、「無効化されたコード」という用語を使用するときには、それらを参照していないと思います。

無効化されたコード自体については、コードを汚染するというのが私の意見です。私は以前にあったものを追跡するために別のメカニズムを使用します：ソースリポジトリです。code / test / code / test ...モードのときを除いて、未使用のコードにはコメントせず、削除します。その場合、X行にコメントを付けることは、1つのキーボードショートカットの問題です。

編集：そうそう、私はあなたの明確な質問に答えるのを忘れていました、無効化されたコードに対して特別なコメントをすることは役に立たないと思います。本当にコードを保持したいが、「使用しない」と言う場合は、いつでも@deprecatedとしてマークできますが、それはあなたの質問のポイントではありませんでした。

開発中のいくつかの理由で、コードをコメントアウトすることがあります。私は無秩序で時々急いでいるので、これらのいくつかはそれをソース管理にします。

これが問題の根源だと思います。無秩序で急いでいると、問題が生じるだけです。開発が急いでいてうまく制御されていない理由を理解することが、コメントアウトされたコードを見つけようとせずに、最初のステップであるべきです。

したがって、コメントアウトコードはすべての（？）言語で発生するので、「無効化されたコード」は言語仕様で独自の構文を取得すべきではありませんか？プロの（コメントの分離/無効化されたコード、エディター/ソースコントロールがそれらに作用する）は十分であり、短所（言語の機能的な部分ではなく、「とにかくコメントアウトしないでください」）は犠牲に値しますか？

私はそうは思いません。コメントアウトされたコードは悪い習慣であり、言語が誰かにそれを使用することを奨励すべきではないと私は思います。はい、人々はそれを行い、私はそれを見ましたが、コメントアウトされている私のコードをチェックインすることを拒否します。未使用の古いコードを簡単に管理できるようにすることは、言語の範囲を超えており、バージョン管理の領域に属するものです。

技術的な制限も気になります。これが機能するためには、コメントを解析して、コメントアウトされたソースまたはテキストであるかどうかを判別するか、新しいトークンを言語に追加する必要があります。言語の現在の複雑さに応じて、これがコンパイルにどのような影響を与えるかは完全にはわかりません（行がコンパイルされる有効なコードであるかどうかを識別します）。また、人々はIDEがこれをリアルタイムで管理することを期待します（言語の構文の複雑さと、さまざまな構造やエラーを見つけて強調表示するIDEの応答性の間に関係があります）。

使用している言語にコメント構文が1つしかない場合でも、独自のフレーバーを追加できますが、//が無効な行を示し、//-がコメントを示すプロジェクトで作業しました。組み込みの場合ほどは良くありませんが、ほとんどのIDEは、異なる目的で異なる構文を使用したことを認識していないため、違いを確認するための古い方法が最も効果的である場合があります。

答えに反対して、私は「はい、異なる構文があるはずです！」と答えます。

どんな開発者にも、コードをコメント化せずに1日でもコーディングを行うと言ってみてください。そうすることは、ソース管理を知らない、または怠惰であることを意味しません。Thomas Owensが彼の反対の答えで言ったように、「私がコード/テスト/コード/テスト...モードにいるときを除いて、未使用のコードにはコメントしません。」

コード/テスト/コード/テストモードで費やされた時間はどれくらいですか？私にとっては、それは少なくとも90％の作業です。現時点では、大規模なOSXプロジェクトをiOSに変換しています。最初のステップは、機能するスタブができるまで、壊れていたすべてのコードを無効にすることでした。次の数週間は、コードが機能するようになったら、コメントを外してコードを修正します。

他にも多くのケースがあります。「Windowsの場合は次のコメントを外す」や「iPhone専用アプリの場合はこの行のコメントを外す」などの指示がよく見られるサンプルコードを使用している場合はどうでしょうか。

はい、ずっとソース管理を使用します。しかし、はい、無効なコードと実際のコメントを区別する方法が欲しいです。

要約すると、コードを無効にするためにコメントを使用しないと言うプログラマーはうそをついています。HEADにコミットする洗練されたファイル以外にも、コーディングには多くのものがあります。コードが無効になるのには多くの正当な理由があります。

はい、実際のコメントと無効化されたコードを区別する構文（または少なくとも規則）があればよいでしょう。