デッドコードを書くことは有用ですか？

デッドコードを書くのは便利だと思いますか？

「何らかの操作を行う2つのロジックがある場合、他のロジックコードをコメント化したり、コードを削除したりする代わりに、操作に影響しないためデッドコードにする」と言う人もいます。

例：-

if(true){
    // logic - 1
} else {
    // logic - 2  // dead code
}

本当ですか？

私は通常、デッドコードを書くのではなく、2番目のロジックを削除するだけです。

IMO、それは無意味よりも悪い。

時間の無駄であることに加えて、（または次の人）に変更trueした場合に機能するコードを持っているという錯覚を与えますfalse。それは錯覚に過ぎません...テストしない限り。

そしてもちろん、コードが読みにくくなるのは混乱です。

何らかのSCMを使用する場合、デッドコードはほとんど役に立ちません。代わりに削除する必要があり、ロジック2のコードを表示する必要がある場合は、SCMリポジトリから取得する必要があります。

編集：

デッドコードがあり、コードの他の部分をメンテナンスしている場合、デッドコードを改善する可能性のあるコードの使用を試みることがあります。他の誰かがメンテナンスを行っている場合、実際にデッドコードを知っていない可能性があり、たとえ知っていても、なぜそれがまだ存在するのかはほとんどわかりません。

次に、「ライブ」コードではなくデッドコードでのみ使用されるため、メソッドを削除できると考えた場合、デッドコードを変更する（およびおそらく破壊する）か、他のメソッドをデッドコードにする必要があります。

最終的には、何らかの形で保守地獄に陥ることになります。

したがって、誤った結果を生成したりメンテナーの注意をそらすことができないため、最良のコードは削除されたコードです。:)

いいえ、それは悪いことです。コードが乱雑になり、保守性が低下するからです。

通常、代替の「ロジック」のいずれかを選択する明確な理由があります。この理由（および却下された代替案の存在）は、コードコメントで文書化する必要があります。理由が無効になるという比較的まれなイベントでは、代替コードをリポジトリ履歴から取得するか（以前に推奨された実装ソリューションだった場合）、または現在の完全な知識と要件を使用して肉付けして実装できます（曖昧な場合のみ）考え）。

動作には影響しませんが、メンテナンスには影響します。メンテナンスを容易にするために、コードを可能な限り整理しておく必要があります。

私はあなたがしていることに正直に混乱しています。

優先度の降順：

1. 新しいコードが機能しない場合は、それらを比較できるように、コードの変更の記録をどこかに保管する必要があります。これは常にソース管理内にある必要があります。すでにこれを行っていると思います。そうでない場合は、ソース管理のいくつかの形式を取得するためにできる限りのことを行います。もしあなたが絶対にそれなしでやらなければならないなら（そして、これが良いアイデアである機会を聞いたことがない）、少なくともソースの状態の定期的なバックアップをすぐに利用できるようにしてください。

2. あなたが＃1をしていると仮定して、必要であればデッドコードを回復することができますが、それを長期のライブコードに保持しないでください。紛らわしいだけで、価値を持たないために複雑さが増し、メンテナンスが必要になり、ライブコードとの同期がとれなくなり、将来的に人々を誤解させるなどになります。

3. ただし、2つのコードパス間のコンパイル時の切り替えが合理的である特定の状況があります。新しいコードを開発している間、およびその直後に、両方を使用するのが便利な場合があるため、簡単に切り替えることができます。スイッチバックする必要がある場合、または外部構成オプションを追加する必要がある場合、定数に基づいたifを使用すると、適切なアップグレードパスが得られます。したがって、多くのことと同様に、特定の問題を解決している場合は、それを実行してください。そうでない場合は、避けてください。

人々がやり過ぎだと思う理由は、問題がある場合に人々がソース管理履歴を実際に読んでしまうという疑問（しばしば正しく）からです。新しいコードが怖くて動作しないので、簡単な復帰オプションが必要です。両方を満たそうとするための妥協案は、「計算に変更...（日付）。問題がある場合は、ソース管理の古いバージョンを参照してください」などのコメントを入れることです。

いいえ、役に立ちません。そのelseブロックは何の目的も果たしません。使用する実装が不明な場合は、コメントアウトするか、別のクラスを作成するか、別の場所に保存してください。また、ほとんどの場合、ソースファイルのローカルまたはリモートの履歴があります。

条件がコンパイル時定数に依存している場合、デッドコードはコンパイラーによって削除されるはずです。したがって、技術的にそれを維持しても害はありません。

2つの代替コードをすばやく切り替えたい場合は、次の便利なコメント構成を使用できます。

//*
alternative 1 is active
/*/
alternative 2 is commented out
//*/

/最初のコメント行の最初の行のみを削除すると、次のようになります。

/*
alternative 1 is commented out
/*/
alternative 2 is active
//*/

これにより/、コード内の1つを追加または削除するだけで、選択肢を切り替えることができます。

これは最初は少し奇妙に見えるかもしれませんが、慣れると、ある種のパターンとして簡単に認識することができます。

これを連鎖させて、単一の文字で複数のブロックを一度に切り替えることもできます。

//*
first block of code for alternative 1
/*/
first block of code for alternative 2
/*/
second block of code for alternative 1
/*/
second block of code for alternative 2
//*/

私はこの方法で使用しませんが、機能します。

古いコード、およびそれが置き換えられたという事実が、将来のプログラマーが直感に反する何かについて警告されるように、ソースコードに本当に残るべきであるいくつかの非常にまれな機会があります。その場合、なぜそれがまだあるのか、何が起こったのかを説明する何らかの種類の解説も必要です。

いつものように、保守が容易なプログラムを作成することは、難しい規則や速い規則に従うだけでなく、物事を明確にすることです。デッドコードを残しておくと、何が起こっているかを理解しやすくなります。そのままにしておきます。そうでない場合は、取り出します。

コンパイラーによって無視されます。しかし、私はあなたに同意し、elseステートメントを削除します。バージョン管理を使用していると仮定すると、ファイルの履歴を表示することで古いコードを表示できます。

これはおそらく個人的な意見ですが、コードの一部を維持するとき、デッドコードは邪魔になると思います。どのタスクでも、常に複数の方法で達成できるため、いずれかを選択する必要があります。調査を行い、アルゴリズムを評価して、いずれかを選択してください。この後、コードはその中に代替メソッドを含める必要はありません。

非常に強力な候補者が2人いる場合は、代替案について小さなメモを書き、プロジェクトwiki、またはプロジェクトのドキュメントを含む他の場所に貼り付けます。必要に応じて、このドキュメントを参照し、読みたい理由の概要を説明する1行のコメントを入力できます。

デッドコードを書くのが便利だと思う状況をすぐに考えることはできません。代替アルゴリズムがある場合：

• 最も有用なものを保持し、他を排除するか、
• または、アルゴリズムはさまざまな状況に適用できます。その後、両方を保持し、最初のアルゴリズムを使用するときに条件が状況を識別します。

いずれの場合も、デッドコードはありません。

デッドコードを削除したりコメントしたりしない場合は、コンパイラエラーを回避するためにそれを維持する必要があります。時間の無駄です。SCMがある場合は削除してください。

番号

一部のプログラマーは、このスタイルをコメントの代替として使用し、エレガントだと感じています。

if (1 == 0) 
{
    std::cout <<"I am a dead code capable of resurrection, once a programmer changes the condition!";
}

簡単な答えは簡単です。デッドコードは混乱を招き、バグが発生する可能性があります。コードに文字を入力するとすぐにリスクがあります。したがって、必要以上に追加しないでください。

私が似たようなことを書かなければならなかったのは、コンパイラのバグの回避策としてでしたが、この回避策を使用するようにコンパイラベンダーから推奨されました。

書いたデッドコードをテストしますか？おそらく良いことを確認するために何かしますか？そうでない場合は、取り除いてください。

将来のコード変更のために、デッドコードがまだ機能することを確認しますか？そうでない場合は、取り除いてください。

たとえ使用されていなくても、プログラムに不正なコードは必要ありません。そこにあることは、それが使用できることを示唆しています。両方を使用しない場合、通常は2つのバージョンのコードを維持する必要はありません。これは余分な作業であり、無意味だと感じているため、ほとんどの人がデッドコードに対して良い仕事をしないからです。

コメントアウトされたコード（または、CまたはC ++で#ifdef編集されたコード）を保持する理由があるかもしれませんが、これには、なぜそれがまだ存在するのか、そしてどのような目的に役立つのかについてのコメントを添付する必要があります。

Javaでは、到達不能なコードのため、以下はコンパイルされないことに注意してください。

int someFunc() {
    return 10;
    int x = 12;
    return x;
}

理想的には、コードに何か問題がある場合は、本番環境に移動してユーザーに見つけさせるのではなく、できるだけ早く見つけたいと考えています。

コンパイラがエラーのクラスを見つけることができる場合、コンパイラにそれを見つけさせます。私見は、誰かがあなたが説明する方法でデッドコードを書くことで何をしているのか、そのコンパイラエラーを回避しようとしています。

デッドコードには到達できないため、問題を引き起こすことはできないと主張するかもしれませんが、コメント、ブレース、インデントで問題が発生する可能性があります。

古いロジックをコメントアウトする理由は、コードに大きな変更を加えることを恐れているためです。実際、1週間後、古いコードが実際に正しいことを認識し、今では最初からコードを記述する必要があります。しかし、それがソース管理の目的です。何らかのロジックを変更することに決めた場合、多少機能する現在のコードを失うことを恐れないでください。それを削除して、SVN / Git / TFSにバージョン管理を任せてください。

そうではなく、YAGNIやDRYを気にしないために、何かを行うために2つの異なるロジックを作成した場合は、ユーザーが使用できる場所に配置するようにしてください。もしそうなら、戦略パターンをそこに投げるでしょう。これらの「if .. else」をしないでください。デザインが悪く、維持するのが面倒です。何らかのコードが存在する権利があると本当に考えている場合は、それを使用できるようにしてください。

別の見方をすれば、基本的にほとんどのプロのプログラマーはコードのサイズが敵であることに同意しているということです。これらのブログ投稿を見てください：最高のコードは、コードの最悪の敵であるジェフ・アトウッドによるコードではありませんご覧ください。、Steve Yeggeによる。もっと多くのを見つけることができます。

多くの場合、コードを簡潔に保ち、コードベースが大きくなりすぎるのを防ぐために、多くの場合、パフォーマンスを犠牲にします（それほど重要ではありません）。だから、あなたは本当に100行のデッドコードが良いことだと思いますか？

私がこれが便利だと思ったのは、何かをすばやく無効にしてテスト/バックフィルをしたい場合だけです（プログラムがステップA、B、Cを実行する-すべて時間がかかる。バックフィル中にBとCを無効にすることを選択するかもしれません必要ないことがわかっている場合は、時間を短縮してください）。
しかし、真実はすべての場合でこれは非常にハッキーです。バックフィルコードの長期的な使用が確認された場合は、このようなハックを使用する代わりにconfigを使用して選択を選択するようにコードを記述する必要があります。
私の簡単な経験則は、この種のコードをチェックインしないことです。チェックイン/バージョン管理が必要な場合は、すぐにこれに戻ることができることを意味し、要件の変更を考えると、それは常に悪いことです。

実際には、「デッド」コードを作成するのに役立つ方法が1つあります。それは、プログラムが決して起こらないはずの何かに到達したためにプログラムに大きな例外をスローさせたい場合です。これは、コンパイラエラーか、行の誰かが使用しているテストのロジックを変更し、それを台無しにした場合です。いずれにせよ、あなたの「他」は花火を打ち上げます。この場合、リリースのためにifdefを使いたいでしょう。

エラーメッセージが「パニック：ファイル％sの行％dにいることは想定されていません」などのような状態を示すことが非常に重要です...