if (kutya) then {macska }else {macska};

Nem mondok olyant, hogy "az indiai programozók rosszul dolgoznak", mert minden általánosítás hibás :)
De egy biztos, simán megállapítható, hogy melyik három pattern-t alkalmazzák előszeretettel:

SIDE EFFECT PATTERN
Az alkalmazás titokban, egy eldugott helyen, ahová a leggonoszabb teszter sem jár beállít egy változót, amit máshol is lendületesen használnak. Jobb esetben módosítja csak, így aztán szerencse nélkül nehéz rájönni, hogy miért működik úgy-ahogy (máshogy) az alkalmazás. A legügyesebbek külön thread-et indítanak, és onnan, nem thread safe módon piszkálnak változókat.

EXCEPTION BASED WORKFLOW PATTERN
A dev dob egy exception-t amit többször átcsomagolnak, majd valaki elkap, megnézi, hogy az okok között az exception message részében szerepel-e a "sör" szó, ha igen, akkor csinál valamit, ha nem, akkor mást csinál. A profik az if és a while kiváltására is képesek. A kezdők képesek az exception-t akár GoToException-nak is elnevezni (lehetőleg RuntimeException formájában, hogy más gyanútlan developerek észre se vegyék, hogy átjutottak a védelmükön.

UNIFIED NAMING PATTERN
Mivel a hosszú változóneveket különösen fárasztó begépelni, ezért mindenki copy-paste-el. Erre épül a pattern, de továbbfejlesztve az alapötletet. A unified naming alapváltozatában a változókat azonos, vagy hasonló névvel látjuk el, függetlenül attól, hogy milyen értéket esetleg milyen objektum milyen propertyjét rakjuk bele. A fejlett (és nem mellékesen sokkal viccesebb) változatban ragaszkodjunk már létező nevekhez. Egy példa amely felételezi, hogy két viewhelperünk is van: MacskaViewHelper és MacskaBajuszViewHelper:
<%
set macskaViewHelper = lookup("macskaBajuszViewHelper");
// innentől jöhet bármi, a többi developer úgyse jön rá, hogy nem macska, hanem macskabajusz.
%>

Ezt természetesen oda vissza lehet játszani, és a legszebb, hogyha a két viewhelpernak hasonló metódusai vannak, hogy ne bukjunk le egyből.

Na jó, most megyek, és pofán baszom Mauglit.