Răspuns
Un coder bun este ca un jucător de pool bun.
Când vezi un jucător profesionist de biliard, la început s-ar putea să nu fii impresionat: „Sigur, au primit toate mingile, dar au avut doar lovituri ușoare!” Acest lucru se datorează faptului că, atunci când un jucător de biliard își face lovitura, ea nu se gândește la ce minge va intra în ce buzunar, se gândește și la unde va ajunge mingea cu tac . Configurarea pentru următoarea fotografie necesită abilități și practici extraordinare, dar înseamnă și că arată ușor.
Acum, aducând această metaforă în cod, un bine coder scrie cod care arată că a fost ușor și simplu de făcut . Multe dintre exemplele lui Brian Kernighan din cărțile sale urmează acest model. O parte din „truc” vine cu o conceptualizare corectă a problemei și a soluției sale . Când nu înțelegem suficient de bine o problemă, este mai probabil să ne complicăm excesiv soluțiile și nu vom reuși să vedem idei unificatoare.
Cu o conceptualizare adecvată a problemei, veți obține totul altfel: lizibilitate, mentenabilitate, eficiență și corectitudine. Deoarece soluția pare atât de simplă, va exista probabil mai puține comentarii, deoarece nu este nevoie de explicații suplimentare. Un bun programator poate vedea, de asemenea, viziunea pe termen lung a produsului și își poate forma conceptualizările în consecință.
Comentarii
Răspuns
s pe minut
( original )
EDITARE: Ideea de bază este că „Calitatea codului” nu poate fi pusă în reguli, în același mod în care nu puteți pune „Arta bună” sau „Poezia bună” în reguli, astfel încât să puteți lăsa un computer să spună „Da, artă bună ”sau„ Nu, poezie proastă ”. În prezent, singura modalitate este de a vedea cât de ușor de înțeles este codul pentru ceilalți oameni.
Comentarii
Răspuns
Nu există într-adevăr alte criterii bune decât cât de repede puteți înțelege codul. Îți faci codul să arate bine găsind compromisul perfect între succintitate și lizibilitate.
„WTF” s pe minut ”(mai sus) este adevărat, dar este doar un corolar al regulii mai generale. Cu cât sunt mai multe WTF-uri, cu atât este mai lentă înțelegerea.
Comentarii
Răspuns
Știi că scrii un cod bun când …
Clientul este mulțumit
Colegii de serviciu împrumută codul tău ca punct de plecare
Tipul nou / tipul nou a fost spus să facă modificări la un sistem pe care l-ați construit acum 6 luni și el / ea nu v-a pus niciodată o întrebare
Șeful dvs. vă cere să dezvoltați noi widgeturi echipa pe care o folosești
Te uiți la codul pe care îl scrii astăzi și îți spui „îmi doresc să fi scris un cod ca acesta acum doi ani”
Cum faci măsurați dacă codul este bun …
Care este timpul de răspuns?
Câte călătorii dus-întors la server face?
Ați folosi personal aplicația sau credeți că este greșită?
Ați construi-o în același mod data viitoare?
Codul bun funcționează atunci când ar trebui să. Un cod bun poate fi modificat cu ușurință atunci când este necesar. Codul bun poate fi reutilizat pentru a obține profit.
Comentarii
Răspuns
Un cod care este
fără erori
reutilizabil
independent
mai puțin complex
bine documentat
ușor de urmărit
se numește cod bun.
Un program bun funcționează perfect și nu are erori. Dar ce calități interne produc o astfel de perfecțiune ?. Nu este un mister, avem nevoie doar de o reamintire ocazională. Indiferent dacă codificați în C / C ++, C #, Java, Basic, Perl, COBOL sau ASM, toate programările bune prezintă aceleași calități onorate în timp: simplitate, lizibilitate, modularitate , stratificare, design, eficiență, eleganță și claritateeficiență, eleganță și claritate
Sursă: MSDN
Comentarii
Răspuns
Vi se pare familiar?
Philips mi-a oferit ocazia să urmăresc designul unui nou produs. Pe măsură ce s-a dezvoltat, am devenit din ce în ce mai neliniștit și am început să-mi confiez îngrijorările supervizorului meu. I-am spus în repetate rânduri că desenele nu erau „curate” și că ar trebui să fie „frumoase” în felul în care desenele Dijkstra erau frumoase. El nu a găsit acest lucru ca fiind un comentariu util.Mi-a amintit că eram ingineri, nu artiști. În mintea lui îmi exprimam pur și simplu gustul și el voia să știe ce criteriu foloseam pentru a-mi judeca. Nu am putut să-i spun! Deoarece nu puteam explica ce principii erau încălcate, comentariile mele au fost pur și simplu ignorate și lucrarea a continuat. Simțind că trebuie să existe o modalitate de a explica și de a oferi motivația „gustului” meu, am început să încerc să găsesc un principiu care să distingă modelele bune de cele rele. Inginerii sunt foarte pragmatici; pot admira frumusețea, dar caută utilitate. Am încercat să găsesc o explicație a motivului pentru care „frumusețea” a fost utilă.
Vă rugăm să consultați restul aici .
Comentarii
Răspuns
în afară de criteriile de calitate ale codului natural (copiere / lipire minimă, fără spaghete etc.) un cod industrial bun ar trebui să arate întotdeauna un pic naiv, puțin prea detaliat, ca
int key = i; const bool do_not_create = false; Record r = cache.get(key, do_not_create); ++i;
spre deosebire de
Record r = cache.get(i++, false);
Comentarii
Răspunde
Poate că un răspuns prin ilustrarea opusului ar ajuta (plus este o scuză pentru a introduce XKCD aici).
Codul bun este
simplu de înțeles,
ușor de întreținut ,
nu încearcă să rezolve toate problemele doar cea la îndemână
trăiește mult timp fără a face ca dezvoltatorii să caute alternative
Exemplele includ
Apache Commons
Framework de primăvară
Cadru de hibernare
Răspuns
Voi purta pur și simplu cu „mantenibil”
Tot codul trebuie menținut: nu este nevoie ca acea sarcină să fie mai dificilă decât este necesar
Dacă un cititor nu înțelege această cerință simplă sau are nevoie de o precizare, atunci cititorul nu ar trebui să scrie cod …
Răspuns
Codul bun va fi diferit pentru fiecare persoană și limba cu care lucrează are, de asemenea, un impact asupra a ceea ce ar putea fi luat în considerare a fi cod bun. În general, când abordez un proiect, caut următoarele lucruri:
Cum este organizat proiectul? Fișierele sursă sunt organizate într-un mod curat și pot găsi cod fără prea mult efort?
Cum este organizat codul? Este clar documentat ceea ce face codul din fișier, cum ar fi prin utilizarea unui antet de fișier sau prin utilizarea fiecărei clase care se află în propriul său fișier? Există funcții în fișier care nu mai sunt utilizate în aplicație?
Cum sunt organizate funcțiile? Există un model clar în care sunt declarate variabilele sau este un model destul de aleatoriu? Codul are un flux logic către el și evită structurile de control inutile? Este totul clar documentat cu codul care se autodocumentează acolo unde este nevoie și comentariile exprimă în mod clar motivul și / sau modul în care face codul?
Dincolo de toate acestea, proiectarea aplicația are sens ca întreg? Codul care se află în aplicație poate fi cel mai bun din lume, dar ar putea fi totuși dificil să lucrezi dacă designul general al aplicației nu are sens.
Răspuns
Permiteți-mi să nu sunt de acord cu privire la lizibilitate. Nu, nu complet: codul bun ar trebui să poată fi citit și acest lucru poate fi realizat cu ușurință cu suficiente comentarii.
Dar consider două tipuri de WTF: cele în care vă întrebați dacă programatorul a ajuns mai departe de programarea 101 și cele în care nu înțelegeți în mod absolut genialitatea codului. Unele coduri pot părea foarte ciudate la în primul rând, dar este de fapt o soluție foarte inventivă la o problemă dificilă. A doua nu ar trebui să fie luată în considerare în WTF-meter și poate fi evitată prin comentarii.
Codul foarte lizibil poate fi foarte, foarte lent . O soluție mai puțin lizibilă poate oferi o îmbunătățire mult mai mare a vitezei. R este un excelent exemplu de limbaj în care acest lucru este adesea adevărat. Unora îi place să evite buclele for acolo cât mai mult posibil.În general, aș considera că cel mai rapid cod este codul mai bun, deși este mai puțin lizibil. Adică, dacă îmbunătățirea este substanțială și sunt inserate suficiente comentarii pentru a explica ce face codul.
Și mai mult, gestionarea memoriei poate fi crucială în multe aplicații științifice. Codul care este foarte lizibil, are tendința de a fi cam cam neglijent în utilizarea memoriei: există doar mai multe obiecte create. În unele cazuri, utilizarea inteligentă a memoriei face codul din nou mai puțin lizibil. Dar dacă jonglați în jurul gigabytes-ului de secvențe de ADN, de exemplu, memoria este un factor crucial. Din nou, consider că, cu cât este mai puțin intensiv memoria, codul este mai bun, indiferent de lizibilitate.
Deci, da, lizibilitatea este importantă pentru un cod bun. Cunosc adagiul lui Uwe Liggis: gândirea doare și computerele sunt ieftine. Dar în domeniul meu (genomică statistică), timpii de calcul dintr-o săptămână și utilizarea memoriei de peste 40 Gb nu sunt considerate anormale. Deci, o îmbunătățire de două ori mai mare decât viteza și jumătate din memorie merită mult mai mult decât acel bit suplimentar de lizibilitate.
Comentarii
se întâmplă acolo (chiar în comentarii)?