ヨーダ記法
PowerShellでは、代入演算子に=を使い、比較演算子には別のトークンを使う仕様となっているが、-eq演算子(または-ne演算子)の左オペランドに、配列のようなコレクションを指定すると、右オペランドと一致する要素を含むサブ配列(または一致する要素を含まないサブ配列)が返却される。
そのため、コレクション変数自体を$nullと比較する場合、必ず演算子の左オペランドに$nullを指定するヨーダ記法を使わなければならない。
PowerShellは動的型付け言語であるため、変数は特定の型に束縛されず、プログラムの実行途中で(再代入によって)型が変化する可能性がある。変数にコレクション型の値が格納されているか否かを問わず、nullチェックの際は常に$nullを比較演算子の左側に置くことがベストプラクティスとされている。
なお、JPCERT/CCによる日本語版は更新されておらず、項目の削除が反映されていない。
nullの振る舞いを回避できる利点についても、ヌルポインタエラーを隠蔽し発覚が遅れるという意味では欠点と考えることができる。入力としてnullを許可しないコードであった場合、本来は事前のnullチェック処理を明示的に記述し、実際に入力を使用する箇所ではnon-nullになることを保証すべきだが、ヨーダ記法で書くと事前のnullチェックを省略できてしまい、意図せずnullを許可するコードになってしまう。
そのほか、C++において非基本型を == 演算子で比較する際、適切な演算子オーバーロードが存在しない場合があることも欠点に挙げられる。例えば、ATLのCComBSTRを文字列リテラルと比較するとき、if (L"Hello" == cbstrMessage)と記述すると、CComBSTRによるメンバー演算子オーバーロードCComBSTR::operator ==は使用されない。代わりに暗黙の型変換演算子オーバーロードCComBSTR::operator BSTRが使用され、結果として文字列ではなくポインタ同士の比較が実行されてしまう。_bstr_tにも同様の問題がある。もっとも、この点に関してはヨーダ記法の問題というより、演算子オーバーロードの定義の仕方に問題がある。等値比較演算子==は本来オペランドの交換法則を満たすべきであり、このような組み込み型に対する通常の演算子の意味から逸脱するような振る舞いをする演算子オーバーロードは、便利というより混乱を招くだけである。