Cati programatori stiu sa programeze?

 StefanSC, on 03 iulie 2018 - 21:47, said:

Nu cumva la aia ne-autodidacti sunt carentele?

Edited by UlrichVans, 03 July 2018 - 22:09.

 WinstonMontana, on 03 iulie 2018 - 21:50, said:

Sa zicem ca undeva la 10% sunt buni si foarte buni. Dar per total suntem cam la nivelul Indienilor (tot aduc vorba de astia ca majoritatea softagiilor care au lucrat cu indieni ii cam injura pt codul ilizibil si alte metehne).
Asta se vede si in genul de produse software care se fac pe la noi...

 UlrichVans, on 03 iulie 2018 - 22:08, said:

Nu prea. Astia ne-autodidacti (daca prin asta  intelegem cu studii formale) au habar de un minim de coding standard.

 Shinji, on 03 iulie 2018 - 21:59, said:

De regula nu sunt nervii si stressul aluia care scrie codul. Piata foarte mobila, putini care stau mai mult de 2-3 ani intr-un singur loc .
Si pana acum nu am vazut proiect care sa nu fie understaffed sau overcommited in Romania . Poate or exista, dar inca nu mi-a iesit in cale acest unicorn.

P.S: ciudatenii in cod pot veni si de la coding standards impuse de client/echipa...

Edited by StefanSC, 03 July 2018 - 22:29.

Aceeasi intrebare o poti pune in orice domeniu de activitate ... doar pentru ca unii nu respecta niste reguli pe care le respecti tu (sau niste recomandari de bune practici din industrie) nu inseamna ca nu vor avea de lucru in industrie. Si la medici, profesori, vanzatori, muncitori, etc vor fi o gramada care nu respecta regulile de bune practici si vor lucra in continuare.

Quote

Mda, e trist cand se intampla asa. Dar nu e cazul aici. Ca tot veni vorba ca nu e bine sa incepi conditia cu o negatie, uite alt exemplu de cod din aplicatie:

if (!(n>0))
{
	*do stuff*
}

Deci nu vorbim de coding standards, pur si simplu de ce-i trece fiecaruia prin cap...

de pe OCCC (Obfuscated C Code Contest) îti dau acest exemplu de cod perfect funcțional:

// "Saw that code days ago in a question here  ,it prints the largest prime number"
int m=1711276033,N=1,t[1<<25]={2},a,*p,i,e=39717691,s,c,U=1;g(d,h)
{for(i=s;i<1<< 24;i*=2)d=d*1LL*d%m;for(p=t;p<t+N;p+=s)for(i=s,c=1;i;i--)a=p[s]*
(h?c:1LL)%m,p[s] =(m*1U+*p-a)*(h?1LL:c)%m,*p=
(a*1U+*p)%m,p++,c=c*1LL*d%m;}main(){while(e/=2){N*=2 ;U=U*1LL*(m+1)/2%m;
for(s=N;s/=2;)g(40,0);for(p=t;p<t+N;p++)*p=*p*1LL**p%m*U%m; for(s=1;
s<N;s*=2)g(983983719,1);for(a=0,p=t;p<t+N;)a+=*p<<(e&1),*p++=a%10,a/=10;
}while(!*--p);for(t[0]--;p>=t;)putchar(48+*p--);}


În mod evident tipul care l-a scris era un programator deștept.
Dar, cine și-ar dori așa ceva în codul care tb menținut și dezvoltat în viitor în cadrul unei companii ?

primul exemplu e la polul opus
prin compilare oricum sînt intrucțiuni de tip JNE, BNE, DJNZ (deci N=not) și analoagele lor cu Equal deci nu prea contează că compari cu 1 sau cu 0.

Pana la urma, din atatea moduri de a scrie if castiga ... pattern maching.

 dani.user, on 03 iulie 2018 - 22:47, said:

De obicei castiga cel care furnizeaza cel mai rapid un cod functional. Ca daca faci cod elegant la cost dublu si de 2 ori mai incet, s-ar putea clientul sa piarda multe oportunitati intre timp.

Cand esti meserias, scii cod suficient de de elegant mai repede decat scrie unul mai putin priceput cod de proasta calitate.

Eu am vazut prostii din astea in exceluri, niste formule parca facute de un incepator cu tutoriale de pe supportoffice ca sa faca ceva pentru care exista chiar functie simpla speciala in excel.
Si uite asa erau celule la care erau romane intregi de "formule" care se puteau rezolva din cateva randuri.

Edited by lexis1, 03 July 2018 - 23:20.

 dani.user, on 03 iulie 2018 - 23:18, said:

Cu conditia sa fii semnificativ mai meserias Eu sunt pus destul de des in situatia in care din dorinta de a face solutii "elegante"/"de ultima generatie"/"la moda" viteza proiectului e compromisa semnificativ, costurile cresc masiv, etc. Dar na, cum altii platesc factura, nu am nici o problema cu asta, doar ma mir de cat de ineficiente pot fi unele lucruri din dorinta de a face solutii aparent mai "elegante".

Edited by utopium, 03 July 2018 - 23:25.

Si sa lucrezi la proiecte adecvate, unde nu doar implementezi contra-cronometru ce zice clientul azi ca ar fi vrut de ieri.

Daca vrei e ca la masini, cea mai buna masina nu exista, e definita de nevoie/scop. Daca vrei o masina de familie, un Ferrari e bun de aruncat la gunoi.

In functie de ce vrei de la ea, oricare dintre un Ferrari 488 Spider, Dacia Duster 4x4, Skoda Octavia, Smart poate fi cea mai buna pentru tine, desi sunt masini foarte diferite.

 Shinji, on 03 iulie 2018 - 22:36, said:

if ( n <= 0 ) {

}

Pe ramura IF spui ce faci si nu ce nu faci
Cand dai indicatii cuiva spui pe unde sa mearga si nu pe unde sa  nu mearga
Cand mergi undeva doreste sa afli cum sa ajungi si nu cum sa nu ajungi

Din punct de vedere al design-ului intotdeauna ramura IF trebuie sa fie ramura lui " ce trebuie sa fac" si nu lui "ce nu trebuie sa fac"

La fel si  la scripturile SQL in join-uri pui ce trebuie sa lege si nu ce trebuie sa nu lege.

Quote

Nope, vorbim de arhitectural code design standards.

Edited by WinstonMontana, 03 July 2018 - 23:49.

Eu atat am inteles:
Cel mai greu e sa lucrezi simplu, sa dai solutii simple usor de inteles si verificat.

Edited by arg, 03 July 2018 - 23:47.

 WinstonMontana, on 03 iulie 2018 - 21:19, said:

Nu e absolut deloc OK.

!(a && ar trebui impachetat intr-o metoda privata, numita cum trebuie, si folosita in if(), iar codul mutat din else in if.

 Shinji, on 03 iulie 2018 - 22:36, said:

Parerea mea de ins care are putine tangente cu programarea: mai depinde si acel DO cum e pus , adica expresia ce continua dupa DO. Daca ceea ce vine dupa DO  este facut de asa natura sa fie evaluat mai usor prin negatie , in asa fel incat sa existe un numar mai mic de procesari la rularea codului, atunci codul este perfect corect chiar si fata de cazul normal.  Deci parerea mea este ca depinde de legatura dintre conditie si statement.

 utopium, on 03 iulie 2018 - 23:02, said:

Nu se precizeaza de la inceput cerinta , ce se vrea: mai repede sau mai calitativ?

 Shinji, on 03 iulie 2018 - 20:48, said:

Putini, iar numarul de ani nu e un bun indicator.

Am vazut ambele extreme care sustin teoria asta: arhitecti, CTOs, cum vrei tu sa ii numesti, care scriau destul de mult cod, si nu stiau lucruri importante dar elementare, si studenti care nici nu si-au terminat facultatea, si aveau o gramada de cunostinte.

Nu te mai uita la oameni in numar de ani, sunt chiar fix pix.

Acestea fiind spuse, nu am vazut programatori cu peste 5 ani experienta (care nu au schimbat cariera) care nu produceau plus-valoare. Chiar daca nu stiau acele lucruri elementare, stiau alte lucruri. Daca totusi vei intalni astfel de medii/companii care mentin pe pozitii astfel de oameni, atunci iti recomand sa pleci din acel mediu nociv cat mai rapid.

 WinstonMontana, on 03 iulie 2018 - 23:41, said:

Poate sunt  situatii de nested if statements in care prima conditie cu negatie ajunge sa fie folosita mai departe in alte statementuri de aia ar rula progamul mai eficient. Mai ales daca ai mai multe care se evalueaza mai usor prin   negatie fata de afirmatie.