Cati programatori stiu sa programeze?

Asta m-a facut sa zambesc

Quote

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:

consistenta bate totul.

@Shinji si ai prea multe returns. E mai frumos asa:

if(...) {
 return true;
}
return false;

StefanSC, on 04 iulie 2018 - 15:29, said:

Vezi mai sus ca am zis

Quote

Am doua taste enter

OriginalCopy, on 04 iulie 2018 - 15:34, said:

Mai frumos este asa:

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.

StefanSC, on 04 iulie 2018 - 15:29, said:

Poti te rog sa-mi dai un link la exemplul oferit de QTFoundation?

As aprecia de asemenea daca ai mentiona in ce fel face codul mai nesigur.

WinstonMontana, on 04 iulie 2018 - 15:45, said:

De acord.

Are prea multe returns (mai mult de unul).

OriginalCopy, on 04 iulie 2018 - 15:49, 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

Shinji, on 04 iulie 2018 - 16:00, said:

Nu neaparat, desigur, ci pentru consistenta.

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.

Shinji, on 04 iulie 2018 - 16:00, said:

O functie  poate sa aiba  N intrari si o singura iesire pentru a gestiona cat mai usor  fluxul de date  asa cum a fost propus de Djikstra (acel Djikstra)

Mai Shinji, tu sigur lucrezi la aceea corporatie de software ? Sigur ? Sigur ?

Edited by WinstonMontana, 04 July 2018 - 16:13.

@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.

StefanSC, on 04 iulie 2018 - 16:17, said:

Pai un output  poate fi distribuit pe N exit-point-uri si nu este corect. Un  singur ouput = un singur exit-point

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.

StefanSC, on 04 iulie 2018 - 16:17, said:

Codul de pe acel wiki (care nu e un exemplu oficial) nu returneaza niciodata false. Which is one of the reasons I hate it. Atat eu cat si acel cod returnam QObject::eventFilter(obj, event); daca nu avem un KeyPress

alx42, on 04 iulie 2018 - 15:23, said:

Si pentru a elimina erorile tembele in caz ca mai vine adaugat cod (intentionat sau nu)... alfel, shit happens: https://medium.com/@...ts-2565c62ff492

Deci te enerveaza o chestie corecta care reduce din neplaceri ulterioare.

Edited by UlrichVans, 04 July 2018 - 16:59.

@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.

StefanSC, on 04 iulie 2018 - 16:57, said:

Am mai zis-o o data, dar o repet daca e nevoie. Codul de pe wiki nu returneaza niciodata false.

StefanSC, on 04 iulie 2018 - 16:57, said:

acesata rigidate si dogmatica isi are rostul ei de a ma educa(sau pe cel care le foloseste, de a-l educa)  respectarea unor  proceduri si metode care sunt menite
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.

WinstonMontana, on 04 iulie 2018 - 17:55, said:

De aceea limba oficiala a IT-ului mondial e germana. A stai, ca nu este.

Shinji, on 04 iulie 2018 - 17:54, said:

Ai dreptate, m-am uitat eu in craci din cauza if-urilor. Solutia ta e corecta si imi cer scuze pentru afirmatii.

@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.

WinstonMontana, on 04 iulie 2018 - 12:11, said:

Pfff...si nu poti pune cateva commenturi pe care sa le cauti cu search si sa modifici dupa aia exact unde trebuie? Ce dracu asa ceva e elementar...

alx42, on 04 iulie 2018 - 15:23, said:

Nu se poate face un cod gen  skipOnRead(blank.space)  sau ceva si care sa fie citit la inceputul oricarui compile&build si sa transforme tot textul in forma curata?

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:

Nu am putea avea ceva mai bine de genul :
use statement 1 * 20 + n diverse variable/per statement && use statement 2 * 20 + n diverse variabile/per statement? Ar fi codul absolut simplificat!!!!

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...