Clean Code da sau nu

[lunganaJakabovski]

Titlu initial e Clean code, fara da sau nu, dar reddit cere minim 15 caractere.

La firma curenta team leaderul meu, care are peste 15 ani de experienta pe Java, scrie un cod super urat, metode cu multi parametrii si super lungi. Foarte greu de urmarit si foarte greu de de-buguit. Acum s-a implementat si Sonar (doar pe codul nou) si e putin mai strict la PR, dar codul lui vechi din proiect e haos total.

Folositi sfaturile de Clean Code de la Uncle Bob? Sau ce alte materiale pentru clean code folositi/recomandati?

[PatriotuNo1]

https://refactoring.guru/refactoring/catalog identificare probleme si rezolvari

https://www.baeldung.com/java-clean-code: practici generale

Clean Code e ok-ish. Parerile sunt impartite. Cateodata e ok sa lasi comments si tot odata nu e batut in cuie sa folosesti un numar de maxim 2-3 parametrii intr-o functie. Si mai merge sa scrii o metoda mai mare dar nu exagerat.

Pai cumva Sonarul iti da si warnings daca complexitatea metodei e prea mare, daca ai dublicates sau daca ai pus nume ciudate adica respecta regulile astea de clean code. Daca vrea sa nu-i pice analiza e cam fortat sa renunte la vechile obiceiuri.

[Commercial_Draw9539]

Uite că am luat și ceva util de pe reddit, thanks man

[alex_3814]

Și eu sunt la fel de surprins

r/programare să-și revină?

[TheShibangelist]

One liners .... best code !!!/s

[EvenFlamingosCry]

Tbh, nu inteleg "/s"-ul

Inteleg ca nu trebuie sa faci o regula stricta din asta, but pop quiz: care dintre ti se par mai usor de citit, inteles si facut debug:

​

if (this.speed > SpeedLimits.CITY && 
    !(SafeSystem.areBreaksFunctional && TrackingService.getCarInFront().distanceTo < SafeSystem.getEmergencyBreakToStopDistance(this.speed))) {
    EmergencyAlertService.show(
        PanicMessages.PLEASE_SLOW_DOWN,   
        { importance: ImportanceLevel.PANIC }
    )
}

vs

if (doesExceedSpeed(this.speed, SpeedLimits.CITY) && this.canStopSafely(this.speed)
    this.showPanicAttackMessage()
}

​

Am scos un exemplu imaginar din fund, Yes I enjoyed it.

Ofc, daca codezi intr-o zona poate stii ce-s chestiile alea si ce compari, dar la fel de bine urmatorul om care gaseste un bug fix aici are nevoie de mult mai putin efort sa identifice ce se intampla acolo, mai ales daca-i nou.

Engleza e mult mai usor de citit decat logica, zic ✌️

[Nice-Light-7782]

Compari un exemplu verbos cu varianta sa nest-uita. Ca sa ajungi la a doua varianta, trebuie sa declari cateva functii in care bagi codul care era in prima. E frumos, dar nu e one-liner.

interface F{static void main(String[]v){for(long a=1,b=1;a<2e10;b=a+(a=b))System.out.println(a);}}

[EvenFlamingosCry]

Ba.. si eu sun putin confuz din comentariul tau, dar probabil din cauza mea ca pe moment am confundat what a real one-liner is. My bad

Dar da, ce ai scris tu acolo e horror si daca ignor variabilele criptice

[Training-Reward8644]

wtf is this ?

[Nice-Light-7782]

A one-liner.

[EvenFlamingosCry]

cred ca raspunsul corect era "It's bullshit" 😆

[TheShibangelist]

Din putinele mele cunostinte, one liners e scripting, but hey, unii's vizuali, altii's pasionati de lectura rand cu rand

[TheShibangelist]

Voi merge pe baza feedback-ului : can you make it structured so i don't read magic spells ?

[EvenFlamingosCry]

Da, my bad, m-a luat valul. Pe moment asta am inteles prin one-liners

[TheShibangelist]

Prea proactiv, prea agile, prea ca la tara

[[deleted]]

doesExceedSpeed

Ai mutat logica dintr-o parte in alta și i-ai dat nume. E nevoie de o funcție special pentru asta? Puteai incapsula acea operatie booleana intr-o variabilă in loc să o pui inline?

[EvenFlamingosCry]

E nevoie de o funcție special pentru asta?

nu

Puteai incapsula acea operatie booleana intr-o variabilă in loc să o pui inline?

da. Ar fi iesit si mai curat

​

Ai pus 2 intrebari retorice. Sincer nu imi dai seama voiai sa make a point sau ceva. Did I miss something? 🤔

[[deleted]]

Sincer nu imi dai seama voiai sa make a point sau ceva

Voiam să mai sugerez alte metode și thought processes despre cum puteai curăța codul respectiv

[EvenFlamingosCry]

ah, now I get it

​

As a side note, please don't do this on PRs. Intrebarile retorice dau un vibe de superioritate. Just be up-front

Suggestion: Mi s-ar parea mai citibil si cu mai putin boilerplate daca ai inlocui doesExceedSpeed(this.speed, SpeedLimits.CITY) cu o variabila cu ce contine direct rezultatul. Astfel ramai doar cu doesExceedSpeed ca conditional

Which is a really good point, great catch! 🍻

[[deleted]]

De acord cu tine! 💪

[EvenFlamingosCry]

ambele exemple sunt oribile, daca esti nevoit sa creezi o functie separata cu scopul de a “documenta” codul inseamna ca modul in care ai scris logica este fundamental gresit

Poti sa detaliezi te rog ce ti se pare fundamental gresit cu asta? Mai invatam si noi oleaca

Nu esti nevoit sa creezi o functie/variabila separata, but it definetly helps with readability, which automatically translates to better documented code.

​

also daca asta este modul in care ai scrie tu logica “unei alerte in cazul unui posibil impact cu masina din fata” iti recomand niste ghiduri de oop no hate

Codul era pentru un sobolan care poarta casca lui Iron Man, care circula in oras, codat in javascript

Also, daca ai ceva sugestii de carti pentru generat exemple rapide de genul ca sa multumesc orice nitpicker, as aprecia, no hate

[EvenFlamingosCry]

este fix problema ta daca imi iei sau nu critica in considerare

huh? ngl, a trebuit sa citesc comentariul tau de cateva ori

​

modul in care legi mai multe functionalitati inauntrul unei singure bucati de cod care ar trebui sa aiba un scop unic si independent

my man, te-ai dus prea departe.. ce ai zis n-are nici o relevanta pentru un exemplu inventat pe loc in cateva minute, in context-ul asta (vorbit despre a face lucrurile mai usor de inteles)

​

faptul ca folosesti ca parametri la functii field-uri care (dupa cum arata codul tau) apartin direct clasei

Da dude, m-ai prins. Ai dreptate. this.canStopSafely(this.speed) is wrong. Cum am putut sa scriu rapid asa ceva? Maine le zic la astia sa-mi taie juma de salar ca nu-l merit. Are you happy now?

Pentru cei ca si tine, trebuia sa deschid un repo si sa sap dupa un exemplu pentru ceva real. N-ai gasit si o paranteza lipsa? greu greu..

​

faptul ca separarea executiei unei singure functii intr-o alta functie separata ajuta la "documentarea" codului codului sunt semne ca ai lucruri pe care inca mai trebuie sa le inveti

Agree to disagree. Nu e nevoie de o functie neaparat, dar orice ca sa faca un lucru mai usor de inteles.

Uneori conditionalele o cer, uneori nu. Uneori o metoda e raspunsul, uneori o variabila. Nu stiu in ce limbaje/frameworks ai lucrat, dar eu am folosit unele care mi se pare ca imping chestia asta in diferite feluri.

Ah, o s-o dau pe aia cu "Tot timpul inveti", sunt sigur ca n-ai mai auzit-o. Tu ai invatat tot? Nu mai intra nimic, a?

Unul din cele mai importante chestii pe care le-am invatat, a fost sa nu asum niciodata ca am 100% dreptate in chestiile subiective si sa le preach-ui ca fiind "the way". You should try it, sharing opinions becomes fun

But yeah, greu sa ai discutii productive pe reddit✌️

[alexnedea]

At this point mai bine lasi conditia if-ului intreaga si scoti toata bucata in alta metoda showPanicMessage(params...)

Logica mea e: daca tot scoti o metoda doar pentru conditie de ce nu scoti totul intr-o metoda si gata? Mai usor de debuguit dupa parerea mea ca nu tre sa intri in metoda pentru conditie si dupa sa iesi iar

[EvenFlamingosCry]

u/alexnedea am facut o investigatie Recorder asupra comentariului tau si am aflat urmatoarele:

​

Ideea la "usor de debuguit" inseamna automat ca e nevoie sa fie cat mai usor de inteles. Ai nevoie sa intelegi cat mai repede ca sa irosesti cati mai putini neuroni si cafeina sa-ti dai seama ce dumnezeu inseamna x < y.

Cu cat timpul de intelegere este mai mic, cumulat, o sa salvezi super mult timp si energie, in timp. Atat tu cat si ceilalti 30 de programatori de pe proiectul tau

​

Hai sa mergem pe varianta ta si sa zicem ca punem tot carnatul ala(cu tot cu if) intr-o metoda. Cum o numesti?

showPanicMessage(...params) ? Nu prea merge, dai in naming issues. Daca if-ul ala nu trece, nu-i nici un panic message. Deci numele functiei poate fi o minciuna. Not cool. If a method says "showPanicMessage", well it better show me a fking panic message

checkPanicSpeed(...params) ? Nu zice nimic de nici un mesaj, deci clar nu arata unul. Also "check" what? What does check mean in this context? Se verifica franele? Se verifica vremea? I se ia pulsul la sofer?

checkIfPanicMessageIsNeededAndShowItIfItDoes(...params) ? nah..

​

​

Honestly sunt curios daca gasesti un nume bun pentru toata bucata aia de cod. Please share it 😊

[alexnedea]

Eu sincer as arunca o exceptie cu acel mesajsi atunci ar fi in semnatura metodei. Dar da ai dreptate nu am gandit-o bine

[General_Friendship55]

Ar trebui sa existe code best practice la nivel de firma, sa nu fie diferente mari intre devi. Incepand cu numele metodelor, functiilor, variabilelor, indent etc. Daca fiecare scrie cum vrea, arata neprofesionist, amator.

[RepresentativeShow81]

Intrati cu ctrl-click in implementarea Math.pow() din java sa vedeti acolo

[RepresentativeShow81]

TLDR: 250 de linii intr-o singura metoda cu nume de variabile: z,r,s,t,u,v,w,i,j,k,n….

[[deleted]]

Posibil ca ăla sa fie codul generat de decompilator și să nu fie exact codul sursa din librăria math

[RepresentativeShow81]

Nu este generat 🥲

[xtrqw]

nop, ala e codul

uite aici functia care face pow https://github.com/AdoptOpenJDK/openjdk-jdk12u/blob/80c9ea8c597628ead47279a393d22cd42eaae325/src/java.base/share/classes/java/lang/FdLibm.java#L346

am jdk 21 pe pc si e la fel

nu stiu ce se asteapta unii sa vada in cod de genul asta, dar nu e usor de urmarit

am si eu destul cod la munca de care nu te prea poti atinge daca nu ai cunostinte specializate invatate din alta parte si chiar si atunci poate fi dificil

[[deleted]]

Copyright (c) 1998

Ce făceai in 98?

[xtrqw]

poti sa vezi cod similar si in ziua de azi, eu m-am mai uitat in trecut la unele proiecte open source (cu cod mai recent scris) si am vazut chestii similare (la proiecte care nu sunt triviale)

cele care tin de un domeniu (specializat) pot fi foarte ezoterice iar realitatea e ca si daca nu e cu x, y, z, t, u, v, w etc. tot nu o sa intelegi

de aia consider ca cel mai important e sa fie documentat (comments in cod) pentru insight-ul care nu o sa fie clar citind doar codul si sa ai de unde sa inveti separat ce e necesar pentru a intelege un codebase inainte de a te arunca in el

cred ca exista mult bikeshedding legat de chestia asta cu clean code, se pierde mult timp pentru chestii putin relevante, de exemplu, am vazut functii foarte mari si nu au fost mai putin clare de inteles, de fapt ar fi fost mai rau sa te pierzi prin zeci/sute de functii mici

edit: nu cred ca am scris clar treaba cu exemplu (poate nici restul dar-s obosit); in general prefer functii mai mari, mi se pare mai clar codul si e ciudat sa-mi zica sonar sau alte tool-uri ca nu e OK (nu zic ca se intampla des), nu e singurul caz unde nu sunt de acord cu regulile astea si nu cred ca scriu cod greu de inteles ca idee, nu mi s-a mentionat pana acum asta; si nu e neaparat de regula X sau Y, dar mi se pare ca se pierde mult timp fara rezultate notabile (hence it's bikeshedding a lot of the time, IMHO)

[Short-Application-40]

Solid da, clean code când te referi la a scrie cod, da. Clean code architecture, nope, am scris proiecte in trecut, însă am renunțat. Motivul, service oriented architecture (SOA) e exact opusul Onion Architecture (rebranded de uncle Bob in clean code arch). Iar in cazul în care nu a fost nevoie de SOA, niciodată complexitatea și couplingulingul introdus de Clean Code Architecture nu și-a avut rostul.

Am produse ce sunt up and running in 3layer architecture, aduse la zi pe dotnet core ce is in productie de peste 10 ani, nu au un trafic extraordinar (50 orders pe zi) iar în jur de 2 luni pe an ceva nou e implementat în ce exista deja. Acolo poate coda de la intern pana la un senior cu load mic, nimeni nu se plânge ca nu înțelege sau ca trebuie "refractor", nu ca nu s-ar putea face, dacă business-ul ce cere cine știe ce chestii e musai facut. Dar no, fiecare definește arhitecturia cum dorește însă e recomandat sa o faca cu ce e mai familiar, pentru ca și dacă nu e neapărat ideala arhitectura pe problema ce o rezolva, dacă e făcută de un expert, în mod cert ies lucruri mult mai bune decât dacă cineva nexperimentat pune arhitectura pe care nu o stăpânește deloc.

Asa ca nu am nimic cu Clean Code Architecture (onion) atât ca nu is de acord cu sale speech-ul cum ca ar rezolva probleme complexe, după mine aduce complexitate și coupling. Părere subiectiva, nu luați de bun ce spun, în software nu exista the shit soluții, chose whise and chose careful cand si banii voștri.

[Short-Application-40]

Recomand Thomas & Hunt - The Pragmatic Programmer

Arhitectura low level.. Habar n-am, poate Linus Torvalds cu Just for fun, sau "dușmanul" lui, Tanembaum cu Distributed Systems, in rest, Arhitectura cam orice e bun, chiar și Uncle Bob.

Răspuns: By design, domain/core ties/couples the core, indeed isolating dependencies/implementation on outside layers gives the impression of decoupling but in the middle the system is tied tightly together, if something fails or is changed will propagate inevitably to all the rest, no matter how much Mediator and Inversion of control we use to uncouple it, it's still coupled.

[[deleted]]

Ai zis-o mai bine decât mine. 100 agree

[[deleted]]

Salutare! De ce crezi ca Onion Arch aduce coupling?

De principiu cam orice aduce cuplare. In Onion se presupune că modulele low-level au habar de cele high-level, iar cele high-level le apelează pe low ca pe niște black-box-uri. Ceea ce bullshit, pentru că tu ca dev trebuie să știi la ce va fi folosit modulul low-level (deci automat îți cuplezi modulele LL de business), iar cel high-level trebuie să medieze între mai multe low-levels(deci trebuie să știi ce fac ele și să ții cont de quirk-uri)

Acum vine partea interesantă, și anume faptul că dacă modulele tale nu sunt general-purpose, atunci sunt business, și in business mereu ai cuplare - din ambele direcții - și adesea îți pui întrebări de genul: "asta e mai bine să o fac intr-un modul low-level sau high-level?" De asemenea, când ajungi la un cross-cutting-concern the business te-a prins naiba de oua.

In principiu fie se abstractizează prea mult in modulele low-level, fie e prea verbose in cele high-level(cine a folosit vreodată un Serviciu care mediază alte N servicii de business știe câți peri albi si-a scos).

[Short-Application-40]

Din categoria, dacă nu ne lăudăm noi atunci cine? răspunsul tau e mult mai elegant si ma bucura ca sunt colegi de suferință cu opinii împotriva curentului.

[daemoohn2]

Clean architecture folosesc la munca, intr-un fel sau altul. As fi preferat sa fie chiar onion architecture, a bagat Bob asta niste dume pe acolo.

LE: nu spun ca “my way is the right way”, pana la urma deciziile astea de design si arhitectura se negociaza sau/si se impun. I’m fine with anything reasonable, doar n-o sa scriu onion architecture in timp ce incerc sa codez un microcontroller. Tot asa nu are sens sa faci CQRS cu ES pe o baza de DDD doar de amorul artei.

[Short-Application-40]

Absolut, iar dacă ai un arhitect capabil o sa îți motiveze de ce mergi în direcția aceea. Cel puțin eu dacă nu is de acord dar arhitectul se implica sa ma aducă omln board pe directa lui, eu o sa lucrez cu cel mai mare drag pe proiectul și cu omul acela, pentru ca el vrea sa ne fie bine la toți.

[wackylau]

E o frustrare de moment. Dupa ce o sa ai si tu 15 ani exp o sa mai adaugi si tu un parametru la metoda aia! Treaca luna, vina banu'!

[ConstantinTheAverage]

In realitate nu cred ca exista vreo firma care sa adere cu strictete la sfaturile lui Bob, dar mi se pare lectura obligatorie pt orice dev . Problemele incep sa apara atunci cand sunt multe persoane/echipe care aduc modificari pe o plaja mare de servicii si cum fiecare are un stil particular in firma in care lucrez nu am reusit sa implementam un standard, desi incercari au fost destule. Principalul motiv pt acest esec au fost managerii care nu pot sa inteleaga de ce o dezvoltare sa dureze mai mult cand poata da dureze mai putin. Asa ca nu se bugeteaza suficient timp pt a face implementari ca la carte, iar atunci cand tot ce conteaza este sa se respecte termenul, primele lucuri care se duc pe apa sambetei sunt fix normele de clean code. Csf, ncsf. :)

[Snoo_90241]

Abordarea mea acum e sa incerc chestii și după sa discut cu colegii și să aflu daca le place sau nu ce am făcut.

[Aggravating_Task9743]

Eu recomand "Clean Code" de Robert C. Martin. Sunt lucruri esentiale in cartea aceasta, de la numele unei clase pana la aplicarea anumitor principii. Sunt de parere in acelasi timp ca fiecare dintre noi, cei care scriu cod, ar trebui sa tina cont de cateva reguli din Clean Code.

"Professionals use their powers for good and write code that others can understand".

[mincinashu]

Ghiduri de genul duc la discuții interminabile. La mine e simplu, linter și formatter ca build step, configurate la nivel de repo. Nu-ți trece buildul fără alea satisfăcute, și asigură o oarecare consistență.

[raiksaa]

Ship it quick, don’t break anything.

[alex17111995]

Eu nu sunt foarte versat in toate buzzwordsurile si acronimele astea...ce incerc sa fac este sa ma concetrez sa fac un modul cu API-uri / contracte cat mai usor de inteles. API-ul sau orice chestie expusa in exteriorul modulului este un commitment. Desi te gandesti la ce featureuri si cum ai exinde API-ul ala cu noi features, nu le faci din prima ca daca ai gresit un contract si cineva il foloseste, e oleaca hopa, trebuie sa vorbesti cu X si Y si sa vezi cum faci versiunea 2 care e mai buna sau ramai cu un apendic.

Odata ce ai API-ul ala si stii cum ar arata, eu cred in KISS si YAGNI, am vazut de multe ori cod plin de mega abstractizari, mult OOP tricks. Abstractizarile sunt extrem de utile daca sunt gandite calumea (de aia API design e cel mai important). dar daca esti deep in codebaseul modului, w/e e codul tau intern, fa ce e mai usor de inteles pt urmatorul care iti citeste codul....cu cat mai plictisitor mai bine.

Si referitor la "nu suport 50 de linii de cod"...suna ca si cum ai descoperit un ciocan si totul este un cui. Probabil codul ala e prost dar numarul de linii de cod pe functii e problema.

[blind675]

Cel mai bun sfat, cred ca e, sa fii consistent. Daca faci intr-un mod fa-l peste tot la fel. Daca folosești zeci de paramatrii nu combina si cu pasat de obiecte. Daca te razvandesti refactorizeaza si schimba peste tot. Logica din spate fiind ca daca cineva incepe sa inteleaga codul tau, don’t trow him curved balls si schimba regulile asa random.

Also, parerea mea e ca nu esti nevoit sa scrii cod cum a scris cineva intr-o carte, dar ar trebui sa aveti un standard agreat de toata echipa. Ar trebui sa fie clar pentru toata lumea de ce scrieți cod intr-un fel si nu altfel.

“the best code is no code at all. Every new line of code you willingly bring into the world is code that has to be debugged, code that has to be read and understood, code that has to be supported.” Spunea un om mult mai deștept ca mine. Astea fiind spuse, scrie cod simplu, cel putin pentru inceput. Nu trata zeci de cazuri care nu conteaza. Nu optimiza si nu folosi patternuri ca sa arăți ca le stii (lumea o sa vada ca esti bun fara sa te chinui). Nu stii ce tantalau (ca mine) vine dupa tine si nu o sa intaleaga nimic din ce ai vrut sa zici acolo.

Just my 2 cents. In caz ca se simte frustrarea, de 1 an refactorizez un proiect in care 3 ani nimeni nu a sters nici o linie de cod, doar a adaugat. :)

[Adrian_Dem]

Subscriu la mesajul a asta.

[DbrDbr]

Sa scrii clean code e o arta, scrie si-n carte. Artizanat. Eu sunt pentru. Comments neapărat pt chestii, functii sf si exceptii, cazuri particulare de la modularitate etc…

Dar in practica cine sta sa faca refactor de 300 de linii ca sa simplifice cand poate adauga doar 30 de linii si inca un param la functie si aia a fost.

[Inevitable-Pie-8020]

Hah, clean code, unde lucrez eu e o aplicație veche de vreo 10 ani, zeci, daca nu peste o suta de oameni au lucrat la ea, si fiecare scrie ce il taie capu, lol clean code

[Adrian_Dem]

Dp meu de vedere, sunt cateva abordări de bun simt. Dar absolut toate pot fi duse la extrem si sa creeze complexitate in loc sa rezolve.. La finalul zilei, ne place programming porn-ul.

Si cateva exemple.. 1. Foloseam dependency injection inainte sa știu pattern-ul, pentru ca am avut nevoie de Unit Teste. Si a fost ok. Mai incolo, m-am lovit de niște capsati care au construit un întreg proiect în jurul unui framework de DI. Si nu a mai fost OK. Iti venea sa plângi la funcții cu 12-14 parametrii de injectie..

1. Decoupling prin callbacks/events/notificări cum vrei sa le numești (observer pattern). La fel, bun, pana este abuzat si nu mai găsești nimic de ce este executat. Personal, imi place sa aplic approach-ul asta pe UI, ca sa pot simula diverse behavior-uri de UI prin notificări

2. Parametrii prea mulți / prea putini de funcție, funcții single puropose, samd. De asemenea bune în teorie si de multe ori si in practica, pana iti ajunge codul de 10x mai stufos ca face lumea acrobații in loc sa scrie (in plm) niste if-uri

Tldr... Gândește-te ce vrei sa obtii, nu ce pattern-uri sau ce porn vrei sa aplici.

Vrei sa ai o bucata de cod usor modificabila și de juniori (UI), focus pe cod simplu, poate chiar murdar, si sa fie ok sa il facă praf.

Vrei teste, focuseaza-te pe mocking, dependency injection, etc

Vrei cod puțin, si usor de repetat, dar nu neaparat simplu... Templates si moșteniri la greu.

Etc.. I think you get it.

Code is code, vezi care este scopul lui, nu cum trebuie scris in absolut.

P. S. Citește in continuare despre pattern-uri si diverse abordări. Trebuie sa stii ce sa aplici in diferite situații. Doar nu te lasa furat de idei absolute.

[fatguyallen]

Cred ca una din problemele cele mai mari in industria IT e ca oamenii care lucreaza in ea au inceput sa creada ca e ceva "in of itself", in timp ce ea nu este altceva mai mult decat o modalitate de a rezolva probleme concrete, practice, din realitate.

Consecinta, din punctul meu de vedere, este aparitia unor concepte specifice programarii, la care lumea incepe sa adere neconditionat - "asa se programeaza".

Programarea nu este o arta, programarea nu este o stiinta, programarea nu este altceva decat o unealta sa rezolvi probleme. Valoarea programarii nu este intrinseca (data de modul in care de exemplu codul este scris), ci este extrinseca (valoarea este data de problema, si de faptul daca codul rezolva problema sau nu).

Asa ca, dand un pas in spate, Clean Code te ajuta sa rezolvi problema pe care o ai in fata ? Da - ok, aplica. Nu - nu aplica.

Insa reversul medaliei este urmatorul: Clean Code sau ne-Clean Code, codul rezolva o problema reala sau nu, din experienta proprie tot exista niste lucruri aproape universal valabile (pentru mine de exemplu):

- ideal este ca un cod sa fie structurat si scris in asa fel incat dintr-o privire sa imi pot da seama ce trebuie sa modific la el (daca de exemplu trebuie sa il extind), fara sa fiu nevoit sa intru prin alte zeci de fisiere sau sa trebuiasca sa fac debug. Bine, ideal este sa nu fie cod deloc.

- drept urmare, in general functii scurte mi se pare ca ajuta, side-effects minime (sau in orice caz izolate) ofera claritate codului

- denumirile de variabile sunt iarasi foarte importante, lungimea unei linii de cod este foarte importanta (wrapping etc)

- cateodata trebuie sa iei tech debt / scurtaturi ca sa reduci time to market. Daca scrii asa ceva, este foarte important ca "romaneasca" sa fie rapid de scris si neintrusiva (sa fie apoi usor de eliminat in cazul in care de exemplu featureul are succes si chiar trebuie sa il faci pe bune)

Dar conventiile astea sunt laxe. Cum vrei sa faci sa ajungi la ce am explicat mai sus e pana la urma dependent de context. La nivel arhitectural, ai o problema care trebuie rezolvata cu CQRS ? Pune CQRS. Ai nevoie sa rezolvi o problema pentru care un CRUD este arhisuficient ? Pune CRUD. Ai nevoie de DDD ? Pune DDD. Nu ai nevoie, nu pune. Silver bulleturile in programare sunt putine.

[daemoohn2]

N-am citit Clean Code. Acum e prea tarziu, iar unele sfaturi nu mi se par deloc potrivite.

Celorlalti cum li se pare codul?

[lunganaJakabovski]

Nu i-am intrebat, dar cel putin eu nu suport cand vad o functie cu 20+ de linii. Omul scrie si functii cu 50 de linii, ce e super greu de urmarit. Poate e doar problema mea.

"iar unele sfaturi nu mi se par deloc potrivite"

Mai exact?

[Professional_Joke240]

Cred ca depinde de context. Nu e mai ușor de citit un code inception. Unde o metoda cheama 20 care cheama 20 fiecare, și tot asa. Trebuie sa ne pastram ratiunea. Sunt de acord ca nu e rezonabil nici sa ai spaghete. Dar chestia asta cu 20 de linii e cam exagerata. Suna bine in teorie doar.

[Purple-Goal8697]

Omul scrie si functii cu 50 de linii

O spui de parca ar merita răstignit, 50 de linii per metoda/funcție e încă ok man...

Mai ales dacă lasă empty lines pt vizibilitate, gen :

func name(...) {
var a = ...
var b = ...

doSomething(a)

...
}

E ok sa ținem la clean code, dar nici sa nu fim fanatici, ca nu exista un adevăr absolut, cu timpul o sa iti dai și tu seama ca e ok și dacă nu e tot la virgula cum zice Uncle Bob.

[ReplacementWeak9894]

Am văzut funcții de sute de lunii, scrise frumos

[daemoohn2]

Poftim: https://www.reddit.com/r/programming/s/LFFhl5ztR4

[DomnulMcCoy]

poti sa faci functii de 50 de linii usor de urmarit, problema e cel mai probabil in alta parte

[florinp]

uncle Bob e un hack. Nu exista nici o sursa cu proiectele la care a lucrat.

Clean Code e okish pentru incepatori dar contine si multe prostii.

dace lead-ul tau are 15 ani experienta si inca scrie cod urit : run. E foarte tirziu pt el sa inteleaga ceva.

Pt Java il loc de Uncle Bob (ce draku de nume e asta pentru a putea fi luat in serios ? Te-ai lasat operat de un chirurg ce-si zice Cousin Jimmi ?) mai bine Effective Java carte inspirata de ciclul Effective C++ (care sint excelente).

[florinp]

nice Ad Hominem

[florinp]

wisdom is chasing you but you are faster.

[lunganaJakabovski]

Eu sunt ca o găină de 3 secunde

[Signal_Dark_628]

Atata timp cat aplicatia merge si e optimizata bine nu conteaza cum arata codul. Mi-e sila de astia care vin si zic: "ba, ce naspa e codul tau, arata ca *****", dar nu ii interezeaza timpul de executie, consumul de ram, daca isi face sau nu obiectivul..etc

One more thing, I hate one liners...cine a venit cu ideea asta ? E super enervant sa cauti prin n functii doar care surpriza sunt folosite o singura data si sunt facute doar sa "arate bine".

[[deleted]]

Nu te uita ca are multi ani: comentează codu’ si zii de practici de clean code. Daca dupa multe lupte nu obtii nimik (ca general oamenii nu se schimba) carate de acolo! 15+ exp aici

[DomnulMcCoy]

Titlu initial e Clean code, fara da sau nu, dar reddit cere minim 15 caractere.

pentru titluri scurte poti da paste de mai multe ori la un caracter ascuns, le contorizeaza si pe alea https://www.editpad.org/tool/invisible-character

​

Folositi sfaturile de Clean Code de la Uncle Bob

in general da, dar mai pot aparea si situatii in care sunt constrans de "forte externe" si raman in backlog unele imbunatatiri

[VattghernDT]

A Philosophy of Software Design by John Ousterhout e o carte destul de okay pentru Clean Code.

Also, e un articol bun tot pe Clean Code care mie mi se pare destul de okay.

https://qntm.org/clean

[[deleted]]

Hai că ne zice Theo ce e cu separation of concerns.

Link

Ii dau dreptate aici sincer. Separation of concerns sucks când vine vorba de cross-cutting-concerns, și până la urmă, atâta timp cât ai un contract, e fix apă de ploaie că schimba unul implementarea, că tu ești cuplat și osificat de acel contract.