Yoda conditions

A héten felmerült egy kérdés egyik kollégánktól, hogy mi értelme van annak, ha egy if utasítás feltételében megfordítjuk az operandusok sorrendjét? Nézzük meg!

ElÅ‘ször is tisztázzuk, hogy mit is jelent, ha megfordítjuk az if utasítás feltételében az operandusok sorrendjét. Ez azt jelenti, hogy a megszokott:

if (változó == valami) {
    //kód
} 

helyett

if (valami == változó) {
    //kód
} 

módon írjuk meg a feltételeket, ahol a valami egy konstans, amihez hasonlítunk.

Ezt a programozói szaknyelv Yoda condition néven ismeri. A Yoda condition a nevét nem meglepő módon Yoda-ról kapta, pontosabban a beszédstílusáról.

Eredeti nyelven Yoda beszéde a hagyományos angoltól eltérően nem az alany-ige-tárgy sorrendet követi, hanem általában az alany-tárgy-ige sorrendet. Ezt a szósorrendet tipikusan egyébként akkor szokás használni, ha valamit hangsúlyozni szeretnénk.

Pl: „She wants to fight, and fight she will”.

Ennyi angol és nyelvtani felvezető után visszatérve a programozásra felmerülhet a kérdés, hogy mi értelme van ennek a szintaxisnak?

A rövid válasz az, hogy C# esetén semmi, csak annyi, hogy a kódunkat nehezebb lesz olvasni. Persze akkor felmerül a másik kérdés, hogy mégis milyen nyelvek esetén van értelme?

Például C/C++ esetén van haszna, mivel itt az if utasításban nem csak összehasonlítani tudunk, hanem értéket is tudunk adni a változóknak:

if (valtozo = 42) {
    /*kód*/
}

A fenti C/C++ kódrészlet simán lefordul, de nem sok értelme van így a feltételnek. Viszont ha ezt a kifejezést Yoda condition-re alakítjuk, akkor a kód nem fog fordulni, mivel az = operátor bal oldalán kell állnia annak, aminek értéket adunk.

/*fordítási hiba*/
if (42 = valtozo) {
    /*kód*/
}

Ezen felül Java és olyan nyelvek esetén is lehet értelme, ahol a == jel nem felüldefiniálható és mindig referenciát hasonlít össze. Nézzünk egy példát!

String x = null;
if (x.equals("foo")) {
    //kivétel fog keletkezni.
}

A fenti kódrészletetbÅ‘l belátható, hogy egy kivétel fog keletkezni, mivel null objektumon nem hívható metódus és x változó értékét nem ellenÅ‘riztük le null-ra. Viszont ha megfordítjuk a sorrendet, akkor nem fog kivétel keletkezni:

String x = null;
if ("foo".equals(x)) {
    //Nem keletkezik kivétel
}

Ebben az esetben a konstans, létezÅ‘ objektumon lesz meghívva a metódus, ami nem dob kivételt, mert lekezeli, hogy x lehet null értékű.

A fenti példákból látható, hogy C# esetén nem sok értelme van a Yoda condition használatának, mivel az if utasítás feltételeinek bool típusra kiértékelhetÅ‘nek kell lenniük, valamint a == felülírható (kifejezetten ajánlott egyébként, ha a típus implementálja az IEquatable<T> interfészt) és a ?. operátorral null ellenÅ‘rizve tudunk egy objektum tulajdonságához hozzáférni.

Egyetlen „elÅ‘nye”, hogy növeli a kód kognitív komplexitását, vagyis több idÅ‘ kell a megértéséhez és módosításához. Éppen ezért a fejlett refactor eszközök, mint a Roslinator, felismerik ezt a mintát és automatikusan át tudják írni a feltételt a megszokott formára.

Összegezve tehát a Yoda condition valamikor hasznos volt, de manapság egyre kevesebb értelme van. C/C++ esetén a feltételen belüli értékadásból adódó hibákat szinte bármelyik statikus kód analizátor meg tudja fogni. Statikus kód analizátort pedig projekt mérettől függetlenül érdemes használni.