Voi ce ziceți? Ce este mai citibil?
foo = 'bar';
if( 'bar' == foo ) {}
// vs
if( foo == 'bar' ) {}
Nu am nici o problemă în a citi astfel de condiționale, dar la scris parcă îmi este puțin peste mână (și, implicit, evit).
dar cred ca tine de obisnuinta, se poate sa fie persoane care sa fie obisnuite invers.
Am folosit o perioadă bună această abordare, exact datorită unor avantaje prezentate în articol, precum și datorită unor constrângeri de proiect, iar cu toate că avantejele s-au dovedit a fi utile/valide, am renunțat.
Am ajuns să abandonăm abordarea, în principal pentru că foarte mulți aveau persistenta impresie subiectivă că este contraintuitiv/confuz, mai ales cei noi-intrați pe proiect. Nu neapărat că era o problemă de înțeles, de obișnuit cu, sau overhead cognitiv suplimentar 
ci doar o imperfecțiune deranjantă… urâtă 
Având în vedere că anii (mișto) haiducești ai programării au cam trecut - în favoarea erei industriale -, cred că orice limbaj/IDE ar cam trebui să aibe ceva analizor static (vezi mai jos exemplu), care să prevină typos de genu și să reducă necesitatea aceastei abordări… mai bine să fie mai lizibil/intuitiv codul sursă.
Până la urmă cred că abordarea inversă este într-adevăr mai naturală, poate datorită faptului că în centrul atenție stă - în general - variabila, căreia i-ar reveni primul loc (și nu vreunei constante)… poate alte motive.
1 Like
Mie mi se pare aia cu un singur = a fi o problemă imaginară. Niciodată nu mi s-a întâmplat să pun din greșeală unul singur și să nu văd imediat că ceva nu-i bine, pentru că am obiceiul de a testa manual codul imediat ce l-am scris atât cu valori care îndeplinesc condiția, cât și cu valori care știu că ar trebui să dea eroare.
În altă ordine de idei, mi se pare foarte aiurea să citesc codul pe dos.
dacă $amurgul este 'violet' // mi se pare natural
versus
dacă 'violet' este $amurgul // mi se pare prea poetic
…mă simt mai ceva ca Bacovia! 
Pe de altă parte, pentru vorbitorii nativi de limbă engleză s-ar putea să nu fie la fel de aiurea, având în vedere că în engleză adjectivul vine în fața substantivului:
$amurg 'violet'
versus
'purple' $twilight
1 Like
Mie nu mi se pare ok sa renuntam la ceva bun pt ca e incomod si programatorii nu vor sa se acomodeze. Daca era indiferent, mai ziceam. Dar asa, e ca si programarea non oop doar pt ca nu vrem sa o intelegem.
Da, stiu ca in it e criza mare de specialisti si acum numai cine nu vrea nu e "it"st, dar o sa coboram la nesfarsit nivelul doar ca sa se simta bine toata lumea, si vom ignora tot mai tare calitatea?
2 Likes
Eu îl văd mai degrabă ca un hack, din aceiași familie ca “hungarian notation” sau să pui T înainte de numele unui tip, sau E înainte de numele unei excepții. Avem unelte care ne permit să depășim problema.
Pe de altă parte e intradevar o problema tendința asta de limitare intrun optim local, din care e greu să scoți oamenii. Unele chestii chiar tre sa vina prin dictat de la leadershipul tehnic - folosirea TDD, review-uri de cod etc, oop vs procedural etc.
1 Like
Eu stiu ca in versiunile mai vechi de PHP, de cand folosesc eu Yoda conditions, chiar conta ordinea. E posibil sa se fi optimizat intre timp incat sa nu mai conteze, dar haideti totusi sa dam exemplul care lipseste din articol. Creem mai intai un pic de context:
// am vazut de multe ori cod din acesta,
// in care se returneaza tot ce cade la mana, dpdv al tipului de date
function somethingReallyImportant() {
if ($conditie) {
return true;
} else if ($altaConditie) {
return -1;
}
return null;
}
$variabila = somethingReallyImportant(); // aici pot avea cam orice tip de date
// My Yoda style, a se observa type checkul adaugat
if (false !== $variabila) { /* sky is the limit */ }
// deci nu asa, sa fiu la mana cast-ului din PHP engine
if (false != $variabila) { /* implementare */ }
Acuma, eu stiu ca daca pun prima data o constanta / valoare fixa / variabila deja evaluata, al carei tip de data este cunoscuta de catre evaluatorul codului, tot ce urmeaza dupa conditie nu se mai castuieste, ci se face direct verificare daca e de acelasi tip. Daca pica verificarea de tip, conditia se evalueaza negativ si se iese din evaluarea termenilor conditiei f rapid.
In cazul in care eu as face if ($post == "test") {} mi s-ar castui $post acela in mai multe tipuri, pana ar da de valoarea care matchuie partea dreapta a evaluarii.
Da, poate fi vazuta ca o micro-optimizare la nivel de 2016, dar nah. Eu am invatat-o acum vreo 10 ani, cred ca imi va fi groaznic sa ma dezobisnuiesc. Oricum in PHP7 avem strict return types (exemplele 4 si 5 de acia) si deja sunt in extaz mistic, pot sa tolerez si non-Yoda code daca vad asta in actiune.
1 Like
Spre rușinea mea și a unei părți din echipe, trebuie să-ți dau dreptate. 
Deși exemplul acesta poate nu este unul critic și a fost ușor de ocolit prin tooling, este într-adevăr reprezentativ pentru trend-ul general în direcția permisivității.
Ceea ce cred că e și mai îngrijorător este că văd chiar firme (tot mai mult) cultivând acest trend…
…posibil să fie din cauza migrației forței de muncă tot mai accentuate și a brain-drain-ului asociat… sau poate în direcția reducerilor de costuri nu mai vor unele firme să formeze experți care ar trebui renumerați
corespunzător mai mult… nu știu…
1 Like
Cred ca am gasit si ceva explicatii in codul sursa php. Eu una n-as vrea sa se execute asa ceva daca as putea.
Daca gasesc si unde se apeleaza toate cast-urile pt conditii, revin cu link.
Acest while(1) e ceva ce am retinut se pare, peste ani. Practic eu imi doresc sa nimeresc din prima pe acel switch si sa ies cu bine din prima, pt ca ramura default e mai scary putin 