Co to znamená psát “ dobrý kód ”? [uzavřeno]

Ve skutečnosti neexistují žádná dobrá kritéria jiná než jak rychle pochopíte kód. Váš kód bude vypadat dobře, když najdete perfektní kompromis mezi stručností a čitelností.

„WTF“ za minutu „(výše) je pravda, ale je to jen důsledek obecnějšího pravidla. Čím více WTF, tím pomalejší porozumění.

Komentáře

• @rmx: define " provádění práce well "
• No, tato RemoveCustomer metoda ve skutečnosti odstraní cutomer bez zašroubování. Můžete strávit hodiny tím, že to bude vypadat hezky, ale to neznamená, že to skutečně funguje. ' Jak rychle rozumíte kódu ' není jediným kritériem pro dobrý kód ' ' je to, co říkám '.
• @rmx: ale bezchybnost je naznačena, není ' t? Pokud váš kód ' nedělá práci správně, ' to zatím nekóduje.
• @ rmx: ve skutečnosti ne. Pokud je váš kód snadno srozumitelný, pak je na závěr ' snadno pochopitelný, pokud funguje ' špatně. OTOH, pokud je ' těžko srozumitelný, ' je těžko pochopitelný, pokud to dokáže ' úkol vůbec.
• @rmx: PS jednoduše řečeno, vaše decrement () je klasický WTF a tím zpomaluje porozumění částem kódu, kde se tato funkce používá.

Víte, že píšete dobrý kód, když …

1. Zákazník je šťastný
2. spolupracovníci si váš kód vypůjčí jako výchozí bod
3. Zcela novému muži / galovi právě řekli, aby provedl úpravy v systému, který jste postavili před 6 měsíci, a nikdy vám nepoložil otázku.
4. Váš šéf vás požádá, abyste vyvinuli nové widgety pro tým k použití
5. Podíváte se na kód, který dnes napíšete, a řeknete si: „Přál bych si, abych takový kód napsal už před dvěma lety.“

Jak se vám daří změřte, zda je kód dobrý …

• Jaká je doba odezvy?
• Kolik zpáteční cesty na server to dělá?
• Využili byste aplikaci osobně nebo si myslíte, že je neohrabaná?
• Vytvořili byste ji příště stejným způsobem?

Dobrý kód funguje, i když je měl. Dobrý kód lze snadno upravit, když je potřeba. Dobrý kód lze znovu použít k dosažení zisku.

Komentáře

• " Zákazník je šťastný " je k tomu ortogonální.
• @TRA – Pokud je zákazník šťastný, znamená to, že jste pochopili požadavky a poskytli řešení, které očekávali.
• jistý, ale špatný kód může udělat totéž.

Kód, který je

1. bez chyb

2. opakovaně použitelné

3. nezávislé

4. méně složité

5. dobře zdokumentované

6. snadno použitelné

se nazývá dobrý kód.

Dobrý program funguje bezchybně a nemá žádné chyby. Ale jaké vnitřní vlastnosti produkují takovou dokonalost ?. Není to žádná záhada, potřebujeme jen občasné připomenutí. Ať už kódujete v C / C ++, C #, Javě, Basic, Perlu, COBOLu nebo ASM, všechny dobré programy vykazují stejné časem uznávané kvality: jednoduchost, čitelnost, modularita , vrstvení, design, efektivita, elegance a srozumitelnostefektivita, elegance a srozumitelnost

Zdroj: MSDN

Komentáře

• Jednoduchost, čitelnost, elegance a srozumitelnost jsou totéž. Modularita a vrstvení jsou jen způsoby, jak váš kód vyjasnit. a elegantní. Jediné, co v seznamu zbývá, je efektivita, což je jaksi naznačeno, a kromě toho často jde o kompromis mezi efektivitou a srozumitelností.
• Zkontrolujte toto: goo.gl/hdQt8
• Může být kód bez chyb?
• Ne, může ' t. (Prakticky)
• Efektivní by měl být přidán do vašeho seznamu. Rychlost není ' t nutnost je primárním ukazatelem dobrého kódu, ale dobrý kód by neměl být ' zbytečně pomalý nebo zbytečný.

Zdá se vám to povědomé?

Společnost Philips mi dala příležitost sledovat design nového produktu. Jak se to vyvíjelo, začal jsem být stále více nesvůj a začal jsem svěřovat své obavy svému nadřízenému. Opakovaně jsem mu říkal, že designy nejsou „čisté“ a že by měly být „krásné“ tak, jak byly Dijkstraovy designy krásné. Nepovažoval to za užitečný komentář.Připomněl mi, že jsme inženýři, ne umělci. V jeho mysli jsem prostě vyjádřil svůj vkus a on chtěl vědět, jaké kritérium používám při rozhodování. Nemohl jsem mu to říct! Protože jsem nedokázal vysvětlit, jaké zásady byly porušovány, byly moje komentáře jednoduše ignorovány a práce pokračovala. S pocitem, že musí existovat způsob, jak vysvětlit a poskytnout motivaci pro můj „vkus“, jsem se začal snažit najít princip, který by rozlišoval dobré designy od špatných. Inženýři jsou velmi pragmatičtí; mohou obdivovat krásu, ale hledají užitek. Snažil jsem se najít vysvětlení, proč byla „krása“ užitečná.

Zbytek naleznete zde .

Komentáře

• Protože je odkaz v příspěvku @mlvljr ' nefunkční , zde je odkaz na stránku Knihy Google: books.google.co.in/…
• @balajeerc Díky (také jsem opravil odkaz, takže ukazuje na verzi stejného pdf hostovanou Springerem) 🙂

kromě kritérií kvality přirozeného kódu (minimální kopírování / vkládání, žádné špagety atd.) by dobrý průmyslový kód měl vždy vypadat trochu naivně, trochu příliš podrobně, jako

int key = i; const bool do_not_create = false; Record r = cache.get(key, do_not_create); ++i; 

na rozdíl od

Record r = cache.get(i++, false); 

komentářů

• Ale do_not_create = false znamená „projít false jako argument do_not_create tak, aby bude vytvořeno “nebo„ pas s false jako argument do_create tak, aby nebyl vytvořen „? V jazyce, kde můžete použít názvy argumentů, bych raději cache.get (key:i, create: false); i += 1;.

Možná by pomohla odpověď ilustrující opak (plus je to výmluva, aby se sem dostalo XKCD ).

Dobrý kód je

• snadno srozumitelný,
• snadno se udržuje ,
• se nepokouší vyřešit všechny problémy, pouze ten, který je po ruce
• žije dlouho, aniž by vývojáři hledali alternativy

Mezi příklady patří

• Apache Commons
• Jarní rámec
• Hibernační rámec

Já prostě půjdu s výrazem „udržovatelný“

Je třeba udržovat veškerý kód: není třeba, aby byl tento úkol obtížnější, než je nutné

Pokud některý čtenář tomuto jednoduchému požadavku nerozumí nebo jej potřebuje vysvětlit, pak by tento čtenář neměl psát kód …

Dobrý kód se bude u každé osoby lišit a jazyk, se kterým pracuje, má také vliv na to, co by mohlo být považováno být dobrý kód. Obecně, když přistupuji k projektu, hledám následující věci:

• Jak je projekt organizován? Jsou zdrojové soubory organizovány čistým způsobem a mohu najít kód bez přílišného úsilí?
• Jak je kód organizován? Je jasně zdokumentováno, co kód v souboru dělá, například pomocí záhlaví souboru nebo pomocí každé třídy umístěné ve vlastním souboru? Jsou v souboru funkce, které se již v aplikaci nepoužívají?
• Jak jsou funkce organizovány? Existuje jasný vzor, kde jsou deklarovány proměnné, nebo je to docela náhodný vzor? Má kód logický tok a vyhýbá se zbytečným řídicím strukturám? Je vše jasně zdokumentováno s tím, že kód je sám dokumentující, kde je to nutné, a komentáře jasně vyjadřují proč a / nebo jak to, co kód dělá?

Kromě toho všeho má design aplikace dává smysl jako celek? Kód, který se nachází v aplikaci, může být nejlepší na světě, ale přesto může být obtížné s ním pracovat, pokud celkový design aplikace nedává smysl.

Dovolte mi laskavě nesouhlasit s čitelností. Ne, ne úplně: Dobrý kód by měl být čitelný a toho lze snadno dosáhnout dostatečným počtem komentářů.

Ale uvažuji o dvou druzích WTF: těch, kde se divíte, jestli se programátor dostal dále než programování 101, a těch, kde absolutně nerozumíte genialitě kódu. Některý kód může vypadat velmi divně zaprvé, ale ve skutečnosti je velmi vynalézavým řešením těžkého problému. Druhý by se neměl počítat v metru WTF a lze se mu vyhnout komentáři.

Velmi čitelný kód může být velmi, velmi pomalý . Méně čitelné řešení může mnohonásobně zlepšit rychlost. R je skvělým příkladem jazyka, kde to často platí. Jeden se tam rád vyhne smyčkám co nejvíce.Obecně považuji nejrychlejší kód za lepší kód, i když je méně čitelný. To znamená, že pokud je vylepšení zásadní, samozřejmě, a je vloženo dostatek komentářů, které vysvětlují, co kód dělá.

Ještě více může být správa paměti klíčová v mnoha vědeckých aplikacích. Kód, který je velmi čitelný, má tendenci být trochu nedbalý ve využití paměti: je vytvořeno jen více objektů. V některých případech je díky inteligentnímu využití paměti kód opět méně čitelný. Ale pokud například žongluješ s gigabajty sekvencí DNA, paměť je zásadním faktorem. Znovu považuji kód méně náročný na paměť za lepší kód bez ohledu na čitelnost.

Takže ano, čitelnost je pro dobrý kód důležitá. Znám adagium Uwe Liggise: Myšlení bolí a počítače jsou levné. Ale v mém oboru (statistická genomika) se výpočetní doba týdne a využití paměti přes 40 Gb nepovažují za abnormální. Zlepšení dvojnásobné rychlosti a poloviční paměti tedy stojí mnohem víc než ten extra čitelnost.

Komentáře

• Žádné pravidlo / pravidla bez výjimky
• Dovolte mi nesouhlasit s vaším nesouhlasem: říkáte, že ve vašem poli je rychlost velmi důležitá a říkáte, že je to důležitější než čitelnost. Nesouhlasím, měli byste se snažit používat správnou rovnováhu. Pokud rychlost není nutná, například pro rozhraní na vysoké úrovni, můžete upřednostňovat něco snadno udržovatelného, pokud je rychlost potřebná, pak s vámi souhlasím. Spíše než tvrdá pravidla je lepší používat zdravý rozum a měli byste se stejně vyhnout předčasné optimalizaci.
• @BlueTrin Proč si oba mozek nezkompilovat ty zdroje hi-perf codez a také zdokumentovat peklo toho, co ' děje se to tam (přímo tam v komentářích)?

Pokud jde o mě … Vím, že píšu dobrý kód, když přijde spolupracovník, který pracuje na jiném projektu, a je schopen naskočit a pochopit, co dělám, aniž bych prošel každý blok kódu a ukázat, co dělá.
Místo toho, aby řekl: „Počkej, co ?!“ Říká: „No, dobře, chápu, co jsi tam udělal.“

Dobrý kód také nemá spoustu záludných řešení ani „hacků“. Řádky, když, když to píšete, také si říkáte: „Vím, že to není dobrý způsob, jak to udělat, ale zatím to budu muset udělat jen tak. „Připomenu si to později vylepšit …“

Existuje spousta funkcí „dobrého“ kódu , ale nejdůležitější, IMHO, jsou čitelnost a udržovatelnost.

Váš kód bude obsahovat chyby, pravděpodobně bude rozšířen a znovu použit a mělo by být v určitém okamžiku znovu zapracováno – i když jste to znovu navštívili, je pravděpodobné, že nebudete mít ponětí, co jste sakra udělali udělejte si laskavost a nedávejte do cesty žádné překážky.

Jistě, použijte tento složitý a přesto efektivní algoritmus, ale věnujte tomu jeho dokumentaci trochu času, ale jinak si vytvořte kód jasný a konzistentní.