Megjegyzések
- Jó kód, ha két év után megnézed, és az első gondolatod nem ' t " Haver, wtf ".
- a Honnan tudná, ha ' olvashatóan írtad volna és könnyen karbantartható kód?
Válasz
A jó kódoló olyan, mint egy jó pool-lejátszó.
Amikor profi pool játékost lát, elsőre nem biztos, hogy lenyűgözi: “Persze, minden labdát megszereztek, de csak könnyű lövéseik voltak!” Ennek az az oka, hogy amikor a medence játékosa lövést készít, nem gondol arra, hogy melyik labda melyik zsebbe kerül, hanem arra is, hogy hová kerül a céllabda . A következő felvételhez való felkészülés óriási szakértelmet és gyakorlatot igényel, de ez azt is jelenti, hogy könnyűnek tűnik.
Most, hogy ezt a metaforát kódba hozzuk, jó A kódoló olyan kódot ír, amely úgy tűnik, hogy könnyű és egyértelmű volt ezt megtenni . Brian Kernighan könyveiben szereplő számos példa ezt a mintát követi. A “trükk” egy része a probléma és annak megoldásának megfelelő konceptualizálásával áll elő . Ha nem értünk elég jól egy problémát, akkor valószínűbb, hogy túlbonyolítjuk a megoldásainkat, és nem fogunk látni egyesítő ötleteket.
A probléma megfelelő fogalmának megfogalmazásával mindent megkapsz egyéb: olvashatóság, karbantarthatóság, hatékonyság és helyesség. Mivel a megoldás annyira egyszerűnek tűnik, valószínűleg kevesebb lesz a megjegyzés, mert nincs szükség további magyarázatokra. Egy jó kódoló a termék hosszú távú jövőképét is láthatja, és ennek megfelelően alakíthatja ki a koncepciójukat.
Megjegyzések
- " egy jó kódoló olyan kódot ír, amely látszólag könnyű és egyszerű volt. " < < PONTOSAN! Szerintem ez azért van, mert az emberek általában azt gondolják, hogy a jó kódoló az, aki nagyon " okos " hackeket tud írni. Ha a kód tiszta, és nem túlzottan " okos ", akkor könnyűnek kell lennie, igaz?
- Saját 2 cent: amikor ' EASY automatikus refaktorozással rendelkezik – a Java és a C # a két példa, amit legjobban ismerek – ez ' s könnyen áthelyezhető a jó kódra iteratív módon. Ellenkező esetben elsősorban jól kell konceptualizálnia, de van egyfajta csirke-tojás probléma.
- Egyes algoritmusok önmagukban összetettek. A jó kódolóknak nem okozhat gondot azok megírása, amikor valóban szükség van rájuk – és a lehető legolvashatóbbak maradnak. hülye emberek írnak kódot, amit a fordító ért. Az okos emberek kódot írnak, a hülye emberek megértik.
Válasz
s percenként
( eredeti )
SZERKESZTÉS: Az az alapötlet, hogy a “Kódminőség” nem illeszthető be a szabályokba, ugyanúgy, ahogyan a “Jó művészet” vagy a “Jó költészet” kifejezéseket sem illesztheti a szabályokba, így hagyhatja, hogy a számítógép meghatározza az “Igen,” jó művészet “vagy” Nem, rossz költészet “. Jelenleg az egyetlen módja annak megnézése, hogy a kód mennyire könnyen érthető más emberek számára.
Megjegyzések
- Ez a munkahelyi táblán ragadt meg: -)
- @Cape Cod Gunny Bob bácsi ' könyvében is szerepelt
- Amellett, hogy remek rajzfilm, azt hiszem, valóban a lényegre tér – a jó kód az a kód, amelyet más emberek kellemesnek tartanak olvasni és fenntartani.
- Tehát igaz, a jó kód minden olyan kód, amely nem rossz. Pl. Nehéz meghatározni a jó kódot, könnyebb a rossz kódot meghatározni.
- Általában azokat a " WTF? " ' seket a jó kódgyűlésen rövidesen követi " Oooooh Oké … Látom, mit tettél."
Válasz
Valójában nincsenek jó kritériumok mint hogy milyen gyorsan értheti meg a kódot. A kódot jól nézi ki, ha megtalálja a tökéletes kompromisszumot a tömörség és az olvashatóság között.
A “WTF” percenként “(fent) igaz, de ez csak az általánosabb szabály következménye. Minél több WTF van, annál lassabb a megértés.
Megjegyzések
- @rmx: define " a munka elvégzése well "
- Nos, hogy a
RemoveCustomermódszer valójában csavarozás nélkül távolítja el a cutomert. Órákig tölthet, hogy szép legyen, de ez nem azt jelenti, hogy valóban működik. A ' a ' kód nem csak a ' jó kód kritériuma ' ezt mondom. ' m. - @rmx: de hibátlannak minősül, nem ' t ez? Ha a kód nem ' nem látja el megfelelően a munkát, akkor ' nem kódolja (még).
- @ rmx: valójában nem. Ha a kódja könnyen érthető, akkor végül ' könnyen érthető, ha rosszul teszi ' feladatát. OTOH, ha ' nehezen érthető, akkor ' nehéz megérteni, ha megteszi ' egyáltalán a munkája.
- @rmx: PS Egyszerűen fogalmazva, a decrement () egy klasszikus WTF, és így lelassítja a kód azon részeinek megértését, ahol ezt a függvényt használják
Válasz
Tudod, hogy jó kódot írsz, amikor …
- Az ügyfél elégedett
- A munkatársak kiindulópontként kölcsönözik a kódodat
- A vadonatúj srácnak / galnak csak annyit mondtak, hogy végezzen módosításokat egy 6 hónappal ezelőtt létrehozott rendszeren, és soha nem tett fel kérdést
- Főnöke arra kér, hogy dolgozzon ki új modulokat a csapat használni
- Megnézed a ma írt kódot, és azt mondod magadnak: “bárcsak két éve írtam volna ilyen kódot”
mérje meg, hogy jó-e a kód …
- Mennyi a válaszidő?
- Hány oda-vissza utat vezet a szerverhez?
- Használnád személyesen az alkalmazást, vagy szerinted “ügyetlen”?
- Legközelebb ugyanúgy építenéd?
A jó kód akkor működik, amikor kellene. A jó kód szükség esetén könnyen módosítható. A jó kód felhasználható nyereség elérése érdekében.
Megjegyzések
- " Az ügyfél elégedett " ezzel merőleges.
- @TRA – Ha az ügyfél elégedett, ez azt jelenti, hogy megértette a követelményeket és megoldást nyújtott az elvártra.
- a biztos, de rossz kód ugyanezt megteheti.
Válasz
Olyan kód, amely
-
hibamentes
-
újrafelhasználható
-
független
-
kevésbé bonyolult
-
jól dokumentált
-
könnyen összekeverhető
jó kódnak hívják.
Egy jó program hibátlanul működik és nincs hibája. De milyen belső tulajdonságok eredményeznek ilyen tökéletességet? Ez nem rejtély, csak alkalmi emlékeztetésre van szükségünk. Akár C / C ++, C #, Java, Basic, Perl, COBOL vagy ASM nyelven kódolunk, minden jó programozás ugyanazokat az elismert tulajdonságokat mutatja: egyszerűség, olvashatóság, modulárisság , rétegezés, tervezés, hatékonyság, elegancia és tisztaság, hatékonyság, elegancia és tisztaság
Forrás: MSDN
Megjegyzések
- Az egyszerűség, az olvashatóság, az elegancia és az áttekinthetőség ugyanaz. A modularitás és a rétegezés csak a kód egyértelművé tételének módszerei elegáns. Ekkor a listában csak a hatékonyság marad meg, ami egyfajta implicit, és emellett gyakran a hatékonyság és az egyértelműség közötti kompromisszumokról van szó.
- Ellenőrizze ezt: goo.gl/hdQt8
- A kód hibamentes lehet?
- Nem ' t. (Gyakorlatilag)
- Hatékony t kell hozzáadni a listához. A sebesség nem ' nem szükséges a jó kód elsődleges mutatója, de a jó kódnak nem szabad ' lennie szükségtelenül lassúnak vagy pazarlónak.
Válasz
Ez ismerősnek tűnik?
A Philips lehetőséget adott arra, hogy megnézzem egy új termék tervezését. Ahogy fejlődött, egyre nyugtalanabb lettem, és gondjaimat a felügyelőmnek kezdtem el bizalmaskodni. Többször elmondtam neki, hogy a tervek nem voltak „tiszták”, és hogy „szépeknek” kell lenniük, úgy, ahogy a Dijkstra tervei szépek voltak. Nem találta hasznos kommentnek ezt.Arra emlékeztetett, hogy mérnökök voltunk, nem művészek. Gondolatában egyszerűen kifejeztem az ízlésemet, és tudni akarta, milyen kritériumot használtam megítélésemhez. Képtelen voltam elmondani neki! Mivel nem tudtam megmagyarázni, hogy milyen elveket sértenek meg, kommentjeimet egyszerűen figyelmen kívül hagyták, és a munka folytatódott. Érezve, hogy az „ízlésemnek” meg kell magyaráznia és motiválnia kell, megpróbáltam olyan alapelvet találni, amely megkülönbözteti a jó mintákat a rosszaktól. A mérnökök nagyon pragmatikusak; csodálhatják a szépséget, de keresik a hasznosságot. Próbáltam magyarázatot találni arra, hogy miért volt hasznos a „szépség”.
A többit itt találja. .
megjegyzések
- Mivel a @mlvljr ' bejegyzésben lévő link megszakadt , itt van egy link a Google Könyvek oldalára: books.google.co.in/…
- @balajeerc Köszönet (A linket is kijavítottam, így az ugyanannak a PDF-nek a Springer által tárolt változatára mutat) 🙂
Válasz
A természetes kód minőségi kritériumaitól eltekintve (minimális másolás / beillesztés, spagetti nélkül stb.) egy jó ipari kódnak mindig kissé naivnak, kissé túl bőbeszédűnek kell lennie, mint például
int key = i; const bool do_not_create = false; Record r = cache.get(key, do_not_create); ++i; szemben a
Record r = cache.get(i++, false); megjegyzésekkel
- De vajon a
do_not_create = falsejelentése “passfalsemintdo_not_createargumentum úgy, hogy létrejön ”vagy„ pas sfalsemintdo_createargumentum, így nem jön létre? Olyan nyelven, ahol argumentumneveket használhat, acache.get (key:i, create: false); i += 1;-et részesíteném előnyben.
Válasz
Talán az ellenkezőjének szemléltetésével adott válasz segíthet (ráadásul ez mentség arra, hogy XKCD ide kerüljön).
A jó kód
- egyszerűen érthető,
- könnyen karbantartható ,
- nem próbálja megoldani az összes problémát, amely csak a kezünkben áll > Példák:
- Apache Commons
- Tavaszi keret
- Hibernált keret
Válasz
Egyszerűen a “karbantarthatóval” megyek
Minden kódot karbantartani kell: nem kell a feladatot a szükségesnél nehezebbé tenni
Ha bármelyik olvasó nem érti ezt az egyszerű követelményt, vagy szükség van rá, akkor az olvasó ne írjon kódot …
Válasz
A jó kód minden ember számára más lesz, és az a nyelv, amellyel dolgoznak, hatással van a megfontolásokra is hogy jó kód legyen. Általában amikor egy projekthez fordulok, a következő dolgokat keresem:
- Hogyan szerveződik a projekt? A forrásfájlok tiszta módon vannak rendezve, és túl nagy erőfeszítés nélkül találok kódot?
- Hogyan szerveződik a kód? Egyértelműen dokumentálja, hogy mit csinál a fájl kódja, például egy fájl fejlécének használatával, vagy a saját fájljában található egyes osztályok használatával? Vannak olyan funkciók a fájlban, amelyeket már nem használnak az alkalmazásban?
- Hogyan szerveződnek a függvények? Van-e egyértelmű minta a változók deklarálásának helyéről, vagy meglehetősen véletlenszerű minta? Van-e logikai folyamata a kódnak, és elkerüli a felesleges vezérlő struktúrákat? Minden egyértelműen dokumentálva van, a kód öndokumentálja, ahol szükséges, és a megjegyzések egyértelműen kifejezik a kód miért és / vagy miként működését?
Mindezeken túl a alkalmazásnak van értelme egészében? Az alkalmazásban található kód lehet a legjobb a világon, de akkor is fájdalmat okozhat a munka, ha az alkalmazás általános kialakításának nincs értelme.
Válasz
Engedje meg, hogy ne értsek egyet az olvashatósággal kapcsolatban. Nem, nem teljesen: A jó kódnak olvashatónak kell lennie, és ez könnyen elérhető elegendő megjegyzéssel.
De kétféle WTF-t tartok szem előtt: azokat, ahol kíváncsi, hogy a programozó továbbjutott-e, mint a 101-es programozása, és azokat, ahol egyáltalán nem fogja fel a kód genialitását. Egyes kódok nagyon furcsának tűnhetnek Először is, de valójában nagyon ötletes megoldás egy nehéz problémára. A másodiknak nem szabad beleszámítania a WTF-mérőbe, és kommentekkel elkerülhető.
A nagyon olvasható kód nagyon-nagyon lassú lehet . Egy kevésbé olvasható megoldás a sebesség sokszoros javulását eredményezheti. Az R remek példa egy olyan nyelvre, ahol ez gyakran igaz. Az ember a lehető legnagyobb mértékben szereti elkerülni a for-loop-okat.Általában a leggyorsabb kódot tartanám jobbnak, bár kevésbé olvasható. Ez azt jelenti, hogy ha a fejlesztés jelentős, természetesen nem, és elég megjegyzést fűzünk ahhoz, hogy elmagyarázzuk, mi a kód.
A memóriakezelés még fontosabb lehet számos tudományos alkalmazásban. A nagyon olvasható kód általában hanyag a memóriahasználatban: csak több objektum jön létre. Sok esetben a memória intelligens használata miatt a kód ismét kevésbé olvasható. De ha például gigabájt DNS-szekvenciákkal zsonglőrködünk, a memória döntő tényező. Ismét úgy gondolom, hogy a kevésbé memóriaigényes kód a jobb kód, függetlenül az olvashatóságtól.
Tehát igen, az olvashatóság fontos a jó kódhoz. Ismerem Uwe Liggis adagiumát: A gondolkodás fáj, és a számítógépek olcsók. De az én szakterületemen (statisztikai genomika) egy hét számítási ideje és a 40 Gb feletti memóriahasználat nem tekinthető rendellenesnek. Tehát a sebesség kétszeresének és a memória felének javítása sokkal többet ér, mint az extra olvashatóság.
Megjegyzések
- Nincsenek szabályok / szabályok kivétel nélkül
- Hadd ne értek egyet egyet nem értéseddel: azt mondod, hogy a területeden nagyon fontos a sebesség, és azt mondod, hogy sokkal fontosabb, mint az olvashatóság. Nem értek egyet, törekednie kell a megfelelő egyensúly használatára. Ha nincs szükség sebességre, például egy magas szintű interfészhez, akkor érdemes valami könnyen karbantarthatót használni, ha sebességre van szükség, akkor egyetértek veled. A szigorú szabályok helyett jobb a józan ész használata, és mindenképpen kerülni kell az idő előtti optimalizálást.
- @BlueTrin id = “668bace25d”>
ott folynak (kommentekben ott)?
Válasz
Ami engem illet … Tudom, hogy jó kódot írok, amikor egy munkatárs, aki egy másik projekten dolgozik, bejön, és képes beugrani és megérteni, hogy mit csinálok anélkül, hogy minden blokkot átmennék. kódot és megmutatja, hogy mit csinál.
Ahelyett, hogy azt mondaná: “Várj egy percet, mi van ?!” Azt mondja: “Ó, oké, látom, mit csináltál ott.”
A jó kódnak “nincs sok alattomos megoldása vagy” feltörése “sem. Vonalak, amikor miközben írod, azt is mondod magadnak: “Tudom, hogy ez nem jó módszer erre, de egyelőre csak így kell csinálnom. Emlékeztetni fogom magam arra, hogy később javítsam … “
Válasz
A” jó “kód számos funkciója van , de a legfontosabbak, az IMHO, az olvashatóság és a karbantarthatóság.
A kódod hibákat fog tartalmazni, valószínűleg kibővítik és újra felhasználják, és kellene valamikor újra figyelembe venni – még akkor is, ha újra felkeresi, valószínű, hogy fogalmának sincs, hogy mi a fenét csinált egyáltalán magadnak egy szívességet, és ne állíts akadályokat az útjába.
Persze, használja ezt a bonyolult, mégis uber-hatékony algoritmust, de ügyeljen arra, hogy egy kis több időt fordítson a dokumentálására, de különben tegye meg kód egyértelmű és következetes.