すべての間接参照されたポインタをヌルガードするのは合理的ですか？

新しい仕事で、次のようなコードのコードレビューでフラグを立てられました。

PowerManager::PowerManager(IMsgSender* msgSender)
  : msgSender_(msgSender) { }

void PowerManager::SignalShutdown()
{
    msgSender_->sendMsg("shutdown()");
}

最後のメソッドは次のように読むべきだと言われています：

void PowerManager::SignalShutdown()
{
    if (msgSender_) {
        msgSender_->sendMsg("shutdown()");
    }
}

つまり、変数がプライベートデータメンバーであっても、変数をガードする必要があります。この「知恵」についてどのように感じているかを説明するためにexp辞を使うのを抑えるのは難しいです。説明を求めると、ある年のジュニアプログラマーがクラスがどのように機能するかについて混乱し、必要のないメンバーを誤って削除した（そしてその後に設定する）ことについてのホラーストーリーを大量に受け取ります、どうやら）、そして製品リリース直後に現場で物事が爆発しました。すべてをチェックする方が良いという「難しい方法を学び、信頼してください」。NULLmsgSender_NULLNULL

私にとって、これは貨物カルトのプログラミングのように感じます。いくつかの善意の同僚は、私が「それを得る」のを助け、これが私がより堅牢なコードを書くのにどのように役立つかを真剣に助けようとしていますが、...私は彼らがそれを手に入れていないように感じるのを助けることができません。

コーディング標準では、関数内で間接参照されているすべてのポインターをNULL最初にチェックすることを要求するのは妥当ですか？プライベートデータメンバーであっても？（注：コンテキストを提供するために、航空交通管制システムやその他の「障害と同等の人々が死ぬ」製品ではなく、家電製品を製造しています。）

編集：上記の例では、msgSender_共同編集者はオプションではありません。これまでNULLに発生した場合は、バグを示しています。コンストラクターに渡される唯一の理由はPowerManager、モックIMsgSenderサブクラスでテストできることです。

要約：この質問には本当に素晴らしい回答がいくつかありました。みなさんありがとう。私は主にその簡潔さのために@aaronpsからのものを受け入れました。以下のかなり一般的な合意があるようです。

1. すべての間接参照されたポインタにNULLガードを強制するのはやり過ぎですが、
2. 代わりに参照（可能な場合）またはconstポインターを使用して、議論全体を回避できます。
3. assertステートメントは、NULL関数の前提条件が満たされていることを検証するための、ガードに対するより賢明な代替手段です。

それは「契約」に依存します：

有効ながPowerManager なければならない場合はIMsgSender、nullをチェックせず、すぐに消滅させます。

一方で、それは場合かもしれない持っているIMsgSender、あなたはそのような単純なように、使用するたびにチェックする必要があります。

ジュニアプログラマーの話についての最後のコメント、問題は実際にはテスト手順の欠如です。

私はコードを読むべきだと感じています：

PowerManager::PowerManager(IMsgSender* msgSender)
  : msgSender_(msgSender)
{
    assert(msgSender);
}

void PowerManager::SignalShutdown()
{
    assert(msgSender_);
    msgSender_->sendMsg("shutdown()");
}

これは実際には、NULLをガードするよりも優れています。NULLの場合、関数が呼び出されるべきではないことが非常に明確になるためmsgSender_です。また、これが発生した場合に気付くようになります。

同僚が共有する「知恵」は、このエラーを静かに無視し、予測できない結果をもたらします。

一般的に、バグは原因に近いと検出された場合、修正が簡単です。この例では、提案されているNULLガードによりシャットダウンメッセージが設定されず、顕著なバグが発生する場合と発生しない場合があります。SignalShutdownアプリケーション全体が停止した場合に比べて、関数を逆方向に操作するのに苦労し、便利なバックトレースまたはを直接指すコアダンプを生成しSignalShutdown()ます。

少し直感に反しますが、何か問題があるとすぐにクラッシュすると、コードがより堅牢になります。それはあなたが実際に問題を見つけ、そして同様に非常に明白な原因を持つ傾向があるからです。

msgSender が決してであってnullはならない場合null、コンストラクターのみにチェックを入れる必要があります。これは、クラスへの他の入力にも当てはまります-クラス、関数など、「モジュール」へのエントリポイントに整合性チェックを配置します。

私の経験則では、モジュール境界（この場合はクラス）間で整合性チェックを実行します。さらに、クラスは、クラスメンバーのライフタイムの整合性をすばやく精神的に検証できるように、十分に小さくする必要があります。不適切な削除やnullの割り当てなどの間違いを防ぐことができます。投稿のコードで実行されるnullチェックは、無効な使用が実際にポインターにnullを割り当てることを前提としています-常にそうであるとは限りません。「無効な使用法」は本質的に通常のコードに関する仮定が適用されないことを意味するため、すべてのタイプのポインターエラー（無効な削除、増分など）を確実にキャッチすることはできません。

また、引数がnullにならないことが確実な場合は、クラスの使用法に応じて参照の使用を検討してください。それ以外の場合は、生のポインタを使用するstd::unique_ptrかstd::shared_ptr、代わりに使用することを検討してください。

いいえ、ポインターであるすべてのポインター逆参照をチェックすることは合理的ではありませんNULL。

NULLポインターチェックは、前提条件が満たされていることを確認するため、またはオプションのパラメーターが提供されていない場合に適切なアクションを実行するために、関数の引数（コンストラクターの引数を含む）で役立ちます。また、クラスの内部を公開した後、クラスの不変式をチェックするのに役立ちます。しかし、ポインターがNULLになった唯一の理由がバグの存在である場合、チェックする意味はありません。そのバグは、ポインターを別の無効な値に簡単に設定できた可能性があります。

あなたのような状況に直面した場合、2つの質問をします。

• なぜそのジュニアプログラマーの間違いがリリース前にキャッチされなかったのですか？たとえば、コードレビューやテスト段階ですか？障害のある家電製品を市場に持ち込むことは、安全性が重要なアプリケーションで使用されている障害のあるデバイスをリリースするのと同じくらい費用がかかります（市場シェアとのれんを考慮すると）。その他のQAアクティビティ。
• nullチェックが失敗した場合、どのようなエラー処理を行うことを期待しますか、またはassert(msgSender_)nullチェックの代わりに単に書くことができますか？nullチェックを入れるだけでクラッシュを防ぐことができたかもしれませんが、実際には操作がスキップされている間に操作が行われたという前提でソフトウェアが続行するため、状況が悪化する可能性があります。これにより、ソフトウェアの他の部分が不安定になる可能性があります。

この例は、入力パラメーターがnull†であるかどうかよりも、オブジェクトの有効期間に関するもののようです。あなたPowerManagerは常に有効IMsgSenderでなければならないことに言及しているので、引数をポインタで渡すことにより（それによってnullポインタの可能性を可能にします）、設計上の欠陥として私を襲います††。

このような状況では、インターフェイスを変更して、呼び出し元の要件が言語によって強制されるようにすることをお勧めします。

PowerManager::PowerManager(const IMsgSender& msgSender)
  : msgSender_(msgSender) {}

void PowerManager::SignalShutdown() {
    msgSender_->sendMsg("shutdown()");
}

このように書き直すことは、そのライフタイム全体にわたってPowerManager参照を保持する必要があると言いますIMsgSender。また、これは、にIMsgSender比べてより長くPowerManager存続しなければならない暗黙の要件を確立し、内部のNULLポインターチェックまたはアサーションの必要性を否定しますPowerManager。

また、スマートポインターを使用して（boostまたはc ++ 11を介して）同じことを記述し、明示的に次のIMsgSender期間よりも長く生きることができPowerManagerます。

PowerManager::PowerManager(std::shared_ptr<IMsgSender> msgSender) 
  : msgSender_(msgSender) {}

void PowerManager::SignalShutdown() {
    // Here, we own a smart pointer to IMsgSender, so even if the caller
    // destroys the original pointer, we still have a valid copy
    msgSender_->sendMsg("shutdown()");
}

このメソッドは、IMsgSenderのライフタイムがのライフタイムより長いことが保証できない場合PowerManager（つまりx = new IMsgSender(); p = new PowerManager(*x);）に推奨されます。

†ポインターに関して：横行するnullチェックはコードを読みにくくし、安定性を向上させません（安定性の外観を改善しますが、これははるかに悪いです）。

どこかに、誰かがメモリを保持するためのアドレスを取得しましたIMsgSender。std::bad_alloc無効なポインタを渡さないように、割り当てが成功したことを確認する（ライブラリの戻り値をチェックするか、例外を適切に処理する）のは、関数の責任です。

PowerManagerはを所有していないためIMsgSender（しばらく借用しているだけです）、そのメモリの割り当てまたは破壊については責任を負いません。これが私がリファレンスを好むもう一つの理由です。

††この仕事は初めてなので、既存のコードをハッキングしていると思います。したがって、設計上の欠陥とは、使用しているコードに欠陥があることを意味します。したがって、nullポインターをチェックしていないためにコードにフラグを立てている人は、ポインターを必要とするコードを書くために実際にフラグを立てています:)

例外と同様に、ガード条件は、エラーから回復するための対処方法がわかっている場合、またはより意味のある例外メッセージを表示する場合にのみ役立ちます。

エラーを飲み込むこと（例外またはガードチェックとしてキャッチされるかどうか）は、エラーが重要でない場合にのみ行うべき正しいことです。飲み込まれているエラーを確認する最も一般的な場所は、エラーログコードです。ステータスメッセージをログに記録できなかったため、アプリをクラッシュさせたくありません。

関数が呼び出され、オプションの動作ではないときはいつでも、静かにではなく大声で失敗するはずです。

編集：ジュニアプログラマーの話を考えてみると、プライベートメンバーがnullに設定されていたのに、それが許可されていないことが起こったようです。彼らは不適切な文章に問題があり、読んで検証することでそれを修正しようとしています。これは逆向きです。特定するまでに、エラーはすでに発生しています。そのためのコードレビュー/コンパイラの強制可能なソリューションは、ガード条件ではなく、ゲッターとセッターまたはconstメンバーです。

他の人が指摘したように、これは合法的にmsgSenderできるかどうかに依存します。以下は、決して NULL であってはならないと想定しています。 NULL

void PowerManager::SignalShutdown()
{
    if (!msgSender_)
    {
       throw SignalException("Shut down failed because message sender is not set.");
    }

    msgSender_->sendMsg("shutdown()");
}

チームの他の人が提案した「修正」は、デッドプログラムの嘘をつかないという原則に違反しています。バグを見つけるのは本当に難しいです。以前の問題に基づいて動作をサイレントに変更するメソッドは、最初のバグを見つけるのを難しくするだけでなく、独自の2番目のバグも追加します。

ジュニアはヌルをチェックしないことで大混乱を引き起こしました。このコードが未定義の状態で実行を継続することで大混乱を招くとしたらどうでしょう（デバイスはオンですが、プログラムはオフだと「考えている」）。おそらく、プログラムの別の部分は、デバイスがオフの場合にのみ安全なことを行います。

これらのアプローチのいずれかは、サイレント障害を回避します。

1. この回答で提案されているようにアサートを使用しますが、実稼働コードでアサートされていることを確認してください。もちろん、他のアサーションが本番環境ではオフになるという前提で記述されている場合、これは問題を引き起こす可能性があります。

2. nullの場合、例外をスローします。

コンストラクターでnullをトラップすることに同意します。さらに、メンバーがヘッダーで次のように宣言されている場合：

IMsgSender* const msgSender_;

その場合、初期化後にポインタを変更することはできません。そのため、構築に問題がなければ、それを含むオブジェクトの存続期間は問題ありません。（オブジェクトが指摘するだろうない CONSTです。）

これはまったく危険です！

私は、Cコードベースの上級開発者の下で、同じことを求めて、すべてのポインターのNULLを盲目的にチェックする、最も粗末な「標準」を使用して作業しました。開発者は次のようなことをすることになります。

// Pre: vertex should never be null.
void transform_vertex(Vertex* vertex, ...)
{
    // Inserted by my "wise" co-worker.
    if (!vertex)
        return;
    ...
}

私はかつて、そのような関数で前提条件のそのようなチェックを一度削除して、assert何が起こるかを見るためにそれを置き換えることを試みました。

恐ろしいことに、この関数にnullを渡すコードベースで数千行のコードを見つけましたが、開発者は混乱している可能性があり、問題が解決するまでコードを追加しました。

さらに恐ろしいことに、この問題はコードベースのあらゆる場所でヌルをチェックしていることがわかりました。コードベースは数十年にわたって成長し、最も明確に文書化された前提条件でさえ静かに違反できるように、これらのチェックに依存するようになりました。これらの致命的なチェックを削除することによりasserts、コードベースでの数十年にわたるすべての論理的な人為的エラーが明らかになり、それらにinれ込んでしまいます。

このように一見無害なコードの2行+時間と1つのチームで、蓄積された1000個のバグをマスクできました。

これらは、ソフトウェアが機能するために存在する他のバグに依存するバグを作成する種類のプラクティスです。これは悪夢のシナリオです。また、こうした前提条件の違反に関連するすべての論理エラーにより、ミスが発生した実際のサイトから100万行のコードが神秘的に表示されます。これらのnullチェックはすべて、バグを非表示にし、バグを隠します。

ヌルポインターが前提条件に違反するすべての場所で盲目的にヌルを単純にチェックすることは、私にとっては完全に狂気です。

コーディング標準では、関数で間接参照されているすべてのポインターを最初にNULLでチェックすることを要求することは合理的ですか？プライベートデータメンバーであっても？

ですから、絶対にそうではないと言います。「安全」でもありません。それは非常によく反対であり、コードベース全体のあらゆる種類のバグを隠します。これは、長年にわたって最も恐ろしいシナリオにつながる可能性があります。

assertここに行く方法です。前提条件の違反は、気付かれることなく許可されるべきではありません。さもないと、マーフィーの法則が簡単に発動します。

たとえば、Objective-Cは、nilオブジェクトに対するすべてのメソッド呼び出しを、ゼロに近い値に評価されるノーオペレーションとして扱います。質問で提案された理由により、Objective-Cの設計決定にはいくつかの利点があります。すべてのメソッド呼び出しをヌルガードするという理論的な概念は、それが十分に公表され、一貫して適用されている場合、ある程度のメリットがあります。

とはいえ、コードは真空ではなくエコシステム内に存在します。ヌルガードの動作は、C ++では非慣用的で驚くべきものであるため、有害であると見なされる必要があります。要約すると、C ++コードをそのように書く人はいないので、やらないでください！ただし、反例として、CおよびC ++での呼び出しfree()またはdeleteonはNULL、no-opであることが保証されていることに注意してください。

あなたの例では、コンストラクターにmsgSenderヌルでないアサーションを配置する価値があるでしょう。コンストラクターがすぐにメソッドを呼び出した場合、msgSenderとにかくそこでクラッシュするため、そのようなアサーションは必要ありません。ただし、将来の使用のために保存する だけmsgSenderなのでSignalShutdown()、値がどのようになったかのスタックトレースを見ても明らかではないNULLため、コンストラクターでのアサーションはデバッグを大幅に容易にします。

さらに良いことに、コンストラクタはconst IMsgSender&参照を受け入れる必要がありますNULL。

null参照を避けるように求められる理由は、コードが堅牢であることを保証するためです。ずっと前のジュニアプログラマーの例は単なる例です。誰でもコードを誤って壊して、特にグローバルおよびクラスグローバルの場合、null参照解除を引き起こす可能性があります。CおよびC ++では、直接メモリ管理機能により、偶発的にさらに可能性が高くなります。驚くかもしれませんが、この種のことは非常に頻繁に起こります。非常に知識があり、経験豊富で、非常に上級の開発者でも。

すべてをnullチェックする必要はありませんが、nullになる可能性が十分にある逆参照から保護する必要があります。これは通常、それらが異なる関数で割り当てられ、使用され、逆参照される場合です。他の関数の1つが変更され、関数が破損する可能性があります。また、他の関数の1つが順不同で呼び出される可能性があります（デストラクタとは別に呼び出すことができるデアロケータがある場合など）。

私は、同僚がassertの使用と組み合わせてあなたに言っているアプローチが好きです。テスト環境でクラッシュするため、本番環境で問題を修正して正常に失敗することは明らかです。

また、coverityやfortifyなどの堅牢なコード正当性ツールを使用する必要があります。そして、すべてのコンパイラの警告に対処する必要があります。

編集：他の人が述べたように、いくつかのコード例のように、静かに失敗することも一般的に間違っています。関数がnull値から回復できない場合、呼び出し元にエラーを返す（または例外をスローする）必要があります。呼び出し元は、呼び出し順序を修正するか、回復するか、呼び出し元にエラーを返す（または例外をスローする）などの責任を負います。最終的に、関数は正常に回復して続行するか、正常に回復して失敗するか（1人のユーザーの内部エラーのためにデータベースがトランザクションに失敗するが、実際には終了しない）、または関数がアプリケーションの状態が破損していると判断する回復不能で、アプリケーションが終了します。

参照の代わりにポインターを使用すると、それは単なるオプションであり、nullチェックが正しいことがわかります。コードスニペットは、それを決定するには遅すぎます。たぶん、価値のある（またはテスト可能な）他の要素があります...msgSenderPowerManager

ポインターと参照を選択するときは、両方のオプションを徹底的に検討します。メンバー（プライベートメンバーであっても）にポインターを使用する必要がある場合は、if (x)参照を解除するたびに手順を受け入れる必要があります。

それはあなたが何をしたいかによって異なります。

あなたは「家電製品」に取り組んでいると書きました。、どういうわけか、バグが設定することにより、導入された場合msgSender_にNULL、あなたがしたいですか

• SignalShutdown続行するデバイスで、スキップして残りの操作を継続する、または
• デバイスをクラッシュさせ、ユーザーに強制的に再起動させますか？

シャットダウン信号が送信されない場合の影響によっては、オプション1 が実行可能な選択肢になる場合があります。ユーザーが彼の音楽に耳を傾け続けることができますが、表示はまだ前のトラックのタイトルが表示されている場合、それは可能性があるデバイスの完全なクラッシュに好ましいこと。

もちろん、オプション1を選択した場合、assert（他の人が推奨するように）開発中に気付かれずにこのようなバグが忍び寄る可能性を減らすために不可欠です。ifヌルガードは、生産、使用中の障害の緩和のためだけに存在しています。

個人的には、プロダクションビルドには「早期クラッシュ」アプローチも好みますが、バグが発生した場合に簡単に修正および更新できるビジネスソフトウェアを開発しています。家電機器の場合、これはそれほど簡単ではないかもしれません。