Cati programatori stiu sa programeze?
#55
Posted 04 July 2018 - 15:34
Asta m-a facut sa zambesc
Quote AppNameChangedForObviousReasons Cauta prin tot codul secvente identice dpv semantic cu: (key->key() == Qt::Key_Enter) || (key->key() == Qt::Key_Return) extrage-le intr-o singura metoda, si foloseste-o peste tot. Aveti un proces de code review? Daca nu, nici nu iti bate capul, pur si simplu schimba codul. Daca da, propune aceasta schimbare, marcand exact toate locurile din cod, si identifica alte secvente de cod similare care pot beneficia de aceeasi tehnica. alx42, on 04 iulie 2018 - 15:23, said:
si invoca ratiuni de lizibilitate sau consistenta. adica umfli codul cu 30% mai multe linii inutile ca sa menajezi niste orbeti. @Shinji si ai prea multe returns. E mai frumos asa: if(...) { return true; } return false; |
#56
Posted 04 July 2018 - 15:45
StefanSC, on 04 iulie 2018 - 15:29, said:
@winstonmontana: Care e diferenta intre o functie si o procedura? Quote
De asemenea, vezi ca pe tastatura ai tasta (Carriage) Return si tasta Enter . Doua gaste in doua traiste separate. OriginalCopy, on 04 iulie 2018 - 15:34, said:
@Shinji si ai prea multe returns. E mai frumos asa: if(...) { return true; } return false; bool chestie = false; if(...) { chestie = ......; } return chestie;deoarece o functie in C are N intrari si o singura iesire, drept urmare pentru a fii consecventi trebuie sa avem N intrari si o singura cale de iesire din functie. Daca nu se respecta acest criteriu si am o functie mare , nefactorizata, neoptimizata si complicata la care se mai adauga si M cai de iesire din aceasta face codul greoi, anevoios si se pierde timp mult. |
#57
Posted 04 July 2018 - 15:46
StefanSC, on 04 iulie 2018 - 15:29, said:
@Shinji Sper ca realizezi ca refactorizarea ta (a unui exemplu oferit de QTFoundation) schimba comportamentul codului si il face mai nesigur... As aprecia de asemenea daca ai mentiona in ce fel face codul mai nesigur. |
#58
Posted 04 July 2018 - 15:49
#59
Posted 04 July 2018 - 16:00
OriginalCopy, on 04 iulie 2018 - 15:49, said:
Are prea multe returns (mai mult de unul). |
#60
Posted 04 July 2018 - 16:08
Shinji, on 04 iulie 2018 - 16:00, said:
E discutabil daca o functie ar trebui sa aiba neaparat un singur return. Ca tot venise vorba de exemplele oferite de QT Foundation, acum ma uitam la unul tocmai pentru eventFilter, care are trei return-uri: http://doc.qt.io/qt-...tml#eventFilter Deseori se intampla sa scurtcircuitezi din executie eliberarea unei resurse cu un return prea devreme. Asa te alegi cu memory leaks si alte asemenea. Deasemenea, retine ca astfel de buguri nu sunt introduse in cod atunci cand codul e scris pentru prima oara, ci de obicei dupa 1 luna, 1 an, cand codul nu mai e proaspat in memoria recenta a programatorului, programatorul original nici nu mai e in echipa, etc, deci trebuie sa programezi defensiv pentru astfel de scenarii. Ce e in Qt e destul de irelevant, manualul qt nu e un manual de stil sau de practici bune, scopul celor de la qt e doar sa iti arate cum sa le folosesti produsul. Edited by OriginalCopy, 04 July 2018 - 16:35. |
#61
Posted 04 July 2018 - 16:12
Shinji, on 04 iulie 2018 - 16:00, said:
E discutabil daca o functie ar trebui sa aiba neaparat un singur return. Ca tot venise vorba de exemplele oferite de QT Foundation, acum ma uitam la unul tocmai pentru eventFilter, care are trei return-uri: http://doc.qt.io/qt-...tml#eventFilter Mai Shinji, tu sigur lucrezi la aceea corporatie de software ? Sigur ? Sigur ? Edited by WinstonMontana, 04 July 2018 - 16:13. |
#62
Posted 04 July 2018 - 16:17
@shinji:
E qt wiki, nu foundation... my bad: https://wiki.qt.io/H...catch_enter_key De asemenea, refactorizarea ta face return QObject::eventFilter(obj, event); daca nu ai un eveniment de tip key in timp ce solutia veche face return false; in aceeasi situatie. Ai vreo garantie ca pentru events de alt tip decat key QObject::eventFilter(obj, event) returneaza false mereu? @WinstonMontana: M-ai facut sa ma simt foarte batran. Pe unele tastaturi qwerty full size sau mai vechi, ai doua taste, una (carriage) Return sub Backspace si un Enter langa NumPad. Istoric, astea erau doua taste cu functii diferite. La ora actuala sunt tratate la fel in general dar poti avea surprize. Si ca idee, vezi ca incurci entry/exit points cu inputs/outputs. Iar motivatia din spatele regulii cu un singur exit point tine de: 1) Management al resurselor (memory leaks)... care nu se aplica la limbaje precum Java sau C#, ce nu existau pe vremea lui Djikstra. 2) Limitari ale IDE-urilor (cod nemarcat indentare aiurea, lipsa de colapsare samd) ... iarasi ceva ce a evoluat din vremea lui Djikstra. Edited by StefanSC, 04 July 2018 - 16:22. |
#63
Posted 04 July 2018 - 16:27
StefanSC, on 04 iulie 2018 - 16:17, said:
Si ca idee, vezi ca incurci entry/exit points cu inputs/outputs. https://www.tomdalli...gle-exit-point/ 1.Nu iti doresc sa faci debugging la un mamut de functie cu 10 exit-pointuri 2.ca vorbeai de java, nu iti doresc sa implementezi un mecanism de gestionare a exceptiilor avand in paralel si alte exit-pointuri. Pur si simplu iti plantezi singur bombe cu ceas. Edited by WinstonMontana, 04 July 2018 - 16:36. |
#64
Posted 04 July 2018 - 16:35
StefanSC, on 04 iulie 2018 - 16:17, said:
De asemenea, refactorizarea ta face return QObject::eventFilter(obj, event); daca nu ai un eveniment de tip key in timp ce solutia veche face return false; |
|
#65
Posted 04 July 2018 - 16:56
alx42, on 04 iulie 2018 - 15:23, said:
si invoca ratiuni de lizibilitate sau consistenta. adica umfli codul cu 30% mai multe linii inutile ca sa menajezi niste orbeti. Deci te enerveaza o chestie corecta care reduce din neplaceri ulterioare. Edited by UlrichVans, 04 July 2018 - 16:59. |
#66
Posted 04 July 2018 - 16:57
@shinji:
Eu vorbeam de refactorizarea pe care ai propus-o tu la exemplul pe care tot tu l-ai dat (si care pare copiat partial dupa wikia aia). Cata vreme codul ala, intr-un program mai mare, returna false pentru orice nu e key iar tu returnezi QObject::eventFilter(obj, event) fara sa fie clar ce comportament are, atunci refactorizarea ta e gresita. Posibil sa strici functionalitate in ambele directii. Naspa sa faci asa greseala cand tu esti cel ce se intreaba daca programatorii stiu sau nu sa programeze. @winstonmontana: Esti prea rigid si dogmatic in perceptia ta. Ca sa citez din link-ul pe care l-ai dat: "There is some controversy surrounding returning early versus having a single exit point, and both sides have decent arguments. However, it is my belief that[..]" respectiv: "Having said how great single exit points are, I will mention that there are certain situations where multiple exit points are safe and improve readability." . Edited by StefanSC, 04 July 2018 - 16:58. |
#67
Posted 04 July 2018 - 17:54
StefanSC, on 04 iulie 2018 - 16:57, said:
Cata vreme codul ala, intr-un program mai mare, returna false pentru orice nu e key iar tu returnezi QObject::eventFilter(obj, event) fara sa fie clar ce comportament are, atunci refactorizarea ta e gresita. |
#68
Posted 04 July 2018 - 17:55
StefanSC, on 04 iulie 2018 - 16:57, said:
@shinji: Eu vorbeam de refactorizarea pe care ai propus-o tu la exemplul pe care tot tu l-ai dat (si care pare copiat partial dupa wikia aia). Cata vreme codul ala, intr-un program mai mare, returna false pentru orice nu e key iar tu returnezi QObject::eventFilter(obj, event) fara sa fie clar ce comportament are, atunci refactorizarea ta e gresita. Posibil sa strici functionalitate in ambele directii. Naspa sa faci asa greseala cand tu esti cel ce se intreaba daca programatorii stiu sau nu sa programeze. @winstonmontana: Esti prea rigid si dogmatic in perceptia ta. Ca sa citez din link-ul pe care l-ai dat: "There is some controversy surrounding returning early versus having a single exit point, and both sides have decent arguments. However, it is my belief that[..]" respectiv: "Having said how great single exit points are, I will mention that there are certain situations where multiple exit points are safe and improve readability." . sa reduca timpul de gasire a unei solutii la o problema aparuta cu 90 %. De aceea noi avem metodologie si proceduri scrise cum sa elaborezi un cod, cum sa-l testezi. Iar cel care face cod review are la randul lor metodologie scrisa despre cum se elaboreaza un cod review, etc. Noi respectam metodologii si proceduri scrise, iar daca vrei sa schimbi ceva (chiar si estetic) trebuie sa specifici in scris motivul pentru care soliciti acest lucru, dupa care un alt senior evalueaza efectelor logicii si al lizibilitatii schimbarilor cerute. Management nemtesc, ata ete.Orice trebuie sa se desfasoara ca la carte dupa procedura si normativ. Probabil de aia majoritatea pleaca in concendiu fara laptopurile de sericiviu, ca n-au de ce , ca nu se intampla nimic, doarece totul merge conform procedurilor elaborate in scris. Edited by WinstonMontana, 04 July 2018 - 17:56. |
#69
Posted 04 July 2018 - 18:13
|
#70
Posted 04 July 2018 - 18:17
Shinji, on 04 iulie 2018 - 17:54, said:
Am mai zis-o o data, dar o repet daca e nevoie. Codul de pe wiki nu returneaza niciodata false. @winston: Yeap. E bine sa ai proceduri definite si sa te asiguri ca le urmezi. Dar cate bordeie atatea obiceie. De exemplu acum lucrez la un proiect in care metoda recomandata de a ajunge la exit point intr-o functie e goto . Si legat de nemti... acu niste ani lucram cu niste baieti din Bavaria care aveau proceduri din astea bine definite si urmate la litera. Si cand preluam modulele de la ei, gaseam dume prin ele. Ei se jurau ca merg corect, conform procedurilor elaborate in scris. Pana cand, exasperat, le-am propus un joc: pentru fiecare duma care ne intarzia mai mult de 1 zi, la urmatoarea intrevedere, vinovatul platea masa intregii echipe. Dupa a treia masa pe care au platit-o, au renunta sa mai se jure pe procedurile elaborate in scris ca totul merge perfect Edited by StefanSC, 04 July 2018 - 18:19. |
#71
Posted 04 July 2018 - 18:51
WinstonMontana, on 04 iulie 2018 - 12:11, said:
Atunci cand am mii de linii de cod , nu exista motiv sa impachetez a && b intr-o metoda privata, duce la boiler-plate cod, adauga linii inutile si face si risipa de timp. De multe ori, daca ai cod in productie , de care depind alte programe, si tu trebuie sa updatezi o sectiune de cod facuta fie acum cativa ani sau chiar de alt coleg, tu trebuie sa citesti sectiunea respectiva de cod repede si bine. De aceea codul trebuie scris ca efectiv "sa-ti sara in ochi ", doarece patchul trebuie elaborat si implementat in cateva ore maxim, pt a fi pus in productie ASAP. De aceea la o scriere de genul if(!(afirmatie)) {}acel (!) poate trece neobservat foarte usor. Nici implementarea cu metoda privata nu ma ajuta pentru ca trebuie sa fac salturi intr-un cod de mii de linii, apoi sa revin inapoi si tot asa. pe cand o sciere de genul : if (afirmatie) { /*JUMP*/ }else { ....... }intr-un cod de mii de linii pentru care trebuie sa faci patch , testare si deployment in cateva ore , sare imediat in ochi. Una este sa cauti albina in lanul de floarea soarelui si alta este cauti ditamai camionul. alx42, on 04 iulie 2018 - 15:23, said:
pe mine ma enerveaza disperatii aia care tin sa formateze codului dupa niste standarde imbecile. de exemplu acolada singura pe linie noua, sau acolade pentru o singura declaratie, si 4 spatii indentare: if(plm) { return QObject::eventFilter(obj, event); } in loc de if(plm) return QObject::eventFilter(obj, event); si invoca ratiuni de lizibilitate sau consistenta. adica umfli codul cu 30% mai multe linii inutile ca sa menajezi niste orbeti. Asa n-ar mai trebui sa stai cu teama ca ai lasat in codul sursa nu stiu cate spatii... OriginalCopy, on 04 iulie 2018 - 15:34, said:
Asta m-a facut sa zambesc Cauta prin tot codul secvente identice dpv semantic cu: (key->key() == Qt::Key_Enter) || (key->key() == Qt::Key_Return) extrage-le intr-o singura metoda, si foloseste-o peste tot. Aveti un proces de code review? Daca nu, nici nu iti bate capul, pur si simplu schimba codul. Daca da, propune aceasta schimbare, marcand exact toate locurile din cod, si identifica alte secvente de cod similare care pot beneficia de aceeasi tehnica. consistenta bate totul. @Shinji si ai prea multe returns. E mai frumos asa: if(...) { return true; } return false; use statement 1 * 20 + n diverse variable/per statement && use statement 2 * 20 + n diverse variabile/per statement? Ar fi codul absolut simplificat!!!! |
#72
Posted 04 July 2018 - 18:54
Un if amuzant nu face un programator prost. Poate era obosit, poate era nervos, stresat, presat de timp etc. Oricum compilatorul ia if-ul ala si-l face pe dos, deci e doar o chestie cosmetica. Solutia aici e simpla: cod review...
Nu exista programatori cu cod perfect, pentru ca codul perfect nu exista. Exista doar unii si altii care incearca sa-l defineasca. Problema este cind unii incearca sa faca o religie din niste OPINII care se refera la forma si nu la fond. Este rau sa ai mai multe return intr-o functie? Raspunsul este "depinde". Daca ai 17 returnuri intr-o ditamai functia oricum ai alte probleme decit numarul de return. Daca e un simpla verificare de 3 linii cu doua return, nici vorba. Ah, ca a zis cineva ca nu-i frumos sau mai rau, ca se intelege mai bine. Se intelege mai bine doar daca esti retardat si nu poti sa intelegi 3 linii cu 2 return Vreti exemplu de cod cu adevarat prost, real si folosit in mai multe locuri cu copy paste? System.gc(); System.gc(); System.gc(); System.gc(); System.gc(); System.gc(); System.gc(); System.gc(); System.gc(); System.gc(); System.gc(); System.gc(); System.gc(); System.gc(); System.gc(); System.gc(); Ya gotta be fucking sure Este mult mai grav cind codul functioneaza prost decit cind codul nu e frumos. Un clean code care implementeaza un kkt nu inseamna ca te ajuta mai mult, inseamna ca daca trebuie sa-l repari in loc sa schimbi 2 clase cu doua metode kilometrice trebuie sa schimbi 15 clase si 87 de metode de 3 linii. Sigur ca ideal ar fi ca sa fie un cod care merge bine si este si frumos aranjat, da sa fim seriosi, lumea reala dovedeste contrariul In concluzie, prefer oricind programatorul cu if-uri invirtite al carui cod functioneaza, decit programatorul care are un cod minunat da care pusca cind nu te-astepti, pentru ca si-a petrecut timpul mai mult bibilind aranjarea in pagina decit ceea ce face el de fapt... |
Anunturi
▶ 0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users