コーディング標準シートで次のルールを見つけました。
条件で bool への暗黙的な変換に依存しないでください。
if (ptr) // 間違っている
if (ptr != NULL) // わかりました
この規則はどの程度合理的/有用ですか?
コンパイルされたコードのオーバーロードはどれくらいですか?
コーディング標準シートで次のルールを見つけました。
条件で bool への暗黙的な変換に依存しないでください。
if (ptr) // 間違っている
if (ptr != NULL) // わかりました
この規則はどの程度合理的/有用ですか?
コンパイルされたコードのオーバーロードはどれくらいですか?
厳密には、bool への暗黙的な変換に依存できます。C との下位互換性が必要です。
したがって、コードの可読性の問題になります。多くの場合、コード標準の目的は、スタイルに同意するかどうかに関係なく、コード スタイルを同一にすることです。他人の標準を見て、それを自分の標準に組み込むべきかどうか迷っている場合は、先に進んで議論してください。しかし、それがあなたの会社の長年のルールである場合は、それを受け入れることを学びましょう.
PS 私はちょうど同じルールを持つ組織に参加しました。明示的は暗黙的よりも優れていると常に信じていたので、実際には問題ありません。私が我慢できないことの1つはbool condition; ... if (condition == true)
、それがあまりにも冗長で、私の目にすりおろすことです.
まともなコンパイラは、チェックが暗黙的であろうと明示的であろうと同じコードを生成するはずなので、それは考慮すべきではありません。
bool
などの への暗黙的な変換を持つクラスを使用したい場合、この規則により拘束されstd::istream
ます。このコードは、EOF に達するまで、ファイルから一度に 1 語ずつ読み取ります。
std::ifstream file("foo.txt");
std::string word;
while (file >> word)
{
// do stuff
}
ストリーム抽出演算子はファイル ストリームへの参照を返します。これはbool
、ストリームがまだ良好な状態にあるかどうかを示すために暗黙的に変換されます。ファイルの最後に到達すると、テストは失敗します。コーディング標準では、この共通構造を使用できません。
ポインター型の場合、大したことではありません。bool
コンパイラは、 への暗黙的な変換と に対する明示的なテストについて、おそらくほぼ同じコードを生成しNULL
ます。その時点での好みの問題です。どちらも絶対的な意味で「優れている」わけではありません。コーディング標準は、一貫したスタイルを強制しようとしているだけです。
そのことを念頭に置いて、組み込み型 (ポインター、int など) を扱うときは、コーディング標準に絶対に従う必要があります。への正当な変換を持つクラスで上記と同様の状況に遭遇した場合bool
、私はあなたのチームメイトに問題を提起します.
ほとんどの場合、それはひどいものではありませんが、意味を正確に入力すると、より読みやすくなります。
(C89 との互換性のために)int
の代わりに返される標準ライブラリを扱う場合など、このルールが破られる可能性があると思うことがあります。bool
ただし、この規則により、一般的にコードが理解しやすくなります。これは C# などの言語でも強制されており、そこではあまり不満はありません。したがって、慣れる必要があることを除けば、このルールに従うことに大きな欠点はありません。
これは、コンパイルされたコードにはまったく影響しません。
その有用性については、Java/C# などの言語から来た人々の理解に役立つことは間違いありません。何をチェックしているのかがより明確になります。int と NULL の比較を開始すると、警告がスローされます (したがって、問題の変数の型について曖昧であることを示します)。私は個人的には最初の形式を好みますが、それは完全に不合理な要件ではありません。
私はこのルールがとても嫌いです。C++ では、ポインター型 (およびもちろんブール型) に対して bool への暗黙的な変換を使用するのが慣用的です。IMO、読みやすい
bool conditionMet = false;
while (!conditionMet) // read as "while condition is not met"
{
/* do something */
}
これを読むよりも:
bool conditionMet = false;
while (conditionMet == false) // read as "while conditionMet is false"
{
/* do something */
}
ポインターも同様です。また、不必要な比較を導入することで、タイプミスが発生し、比較の代わりに代入が行われる可能性がさらに増えます。もちろん、望ましくない結果が生じることになります。古い C コードのように int を bool として使用している場合は、bool への暗黙的な変換も使用する必要があると思います。
ゼロの利益を追加するルールは、有利に削除できるルールです。
それは印象的な愚かなルールです。
if (ptr != NULL) // ok
それならなぜですか
if ((ptr != NULL)==true)