Mozilla DeveloperStyleGuideのC/C ++ Practicesで、次のことがわかります。
ポインターをテストするときは、(!myPtr)または(myPtr);を使用します。myPtr!=nsnullまたはmyPtr==nsnullは使用しないでください。
これには理由がありますか?それとも単なる慣習ですか?
Mozilla DeveloperStyleGuideのC/C ++ Practicesで、次のことがわかります。
ポインターをテストするときは、(!myPtr)または(myPtr);を使用します。myPtr!=nsnullまたはmyPtr==nsnullは使用しないでください。
これには理由がありますか?それとも単なる慣習ですか?
一般に、企業のコーディング ガイドラインは、まさにその企業内で施行されることが期待されるガイドラインです。
これは好みの問題です - どちらも同じことを達成します (myPtr
ポインター* であると仮定します) ので、純粋に主観的なものです。if (myPtr)
大規模なコードベースの場合、場所の半分と残りの半分を見るのは面倒if (myPtr != NULL)
です。
*IfmyPtr
がポインター以外のユーザー定義型の場合、演算子をオーバーロードできる!
ため、実際には異なる動作をする可能性があり!=
ます==
これを行った場合、見つけるのが非常に難しいタイプミスを犯す可能性があります
if (myPtr = nsnull) /* assignment operator */
あなたが本当にこれを意味している間
if (myPtr == nsnull) /* test equality */
これには理由がありますか?
企業のコーディング ガイドラインが存在するのは、大企業では通常、他のプログラミングの問題よりも美的一貫性を重視する人がいるからです。彼らは、無関係な詳細の一貫性がコードをより読みやすくするという偽りの正当化とともに、このような無意味なガイドラインを大量に生成します。企業環境が十分に機能していない場合、これらのガイドラインは公式のポリシー文書に明記され、すべての開発者に課せられます。
それとも単なるコンベンションですか?
この場合、null ポインター値に評価されるかどうかにかかわらず、型にはまらないシンボルを使用しない方がよいのは確かです。おそらくnsnull
、このスタイル ガイドでその使用のために定義され、義務付けられているため、その意味は内部関係者には明らかです。が従来の(または、または)if (ptr)
よりも優れているかどうかは好みの問題です。自分の選択をめぐって聖戦を繰り広げる人もいれば、気にしない人もいます。if (ptr != 0)
NULL
nullptr
スタイル ガイドで推奨されているスタイルの名前は boolean zen です。それがブール式の本質です。ブール禅を実践するということは、可能な限り単純な形式でブール式を書くことを意味します。たとえば、これはブール値の禅ではありません。
bool foo() {
if(myCondition()) {
return true;
} else {
return false;
}
}
ブール値の禅で書き直すと、次のようになります。
bool foo() {
return myCondition();
}
不要なコード構造を追加しないという理由だけで、2 番目の方法がより望ましいことは容易に理解できると思います。
現在、C 派生物では、ブール値のコンテキストで使用された場合、すべての整数/ポインターにも定義済みの動作があります。その変換を手作業で行うのは無意味です。私はe。C/C++/Objective-C の if ステートメント
bool foo = ...;
if(foo) printf("It's true");
if(foo != false) printf("It's really true");
行と同じくらい同等です
Bar* foo = ...;
if(foo) printf("It exists");
if(foo != 0) printf("It really exists");
したがって、ブール禅によれば、どちらの場合も単純なものに固執する必要があります。
このスライドデッキではブール禅の紹介を見つけることができます。