Co to znaczy pisać „dobry kod”? [Zamknięte]

41

W tym pytaniu zapytałem, czy bycie złym pisarzem utrudnia pisanie dobrego kodu. Wiele odpowiedzi zaczyna się od „to zależy od tego, co rozumiesz przez dobry kod”.

Wydaje się, że terminy „dobry kod” i „zły kod” są bardzo subiektywne. Ponieważ mam jeden pogląd, może się bardzo różnić od poglądów innych.

Co to znaczy pisać „dobry kod”? Co to jest „dobry kod”?

gablin
źródło
15
Dobry kod jest, jeśli spojrzysz na niego po dwóch latach, a twoja pierwsza myśl nie brzmi „Koleś, wtf”.
Bobby,

Odpowiedzi:

91

Dobry programista jest jak dobry gracz w puli.

Kiedy widzisz profesjonalnego gracza w bilard, na początku możesz nie być pod wrażeniem: „Jasne, wbili wszystkie piłki, ale mieli tylko łatwe strzały!” Wynika to z tego, że kiedy gracz w bilard strzela, nie myśli o tym, do której piłki trafi, do której kieszeni, zastanawia się także, gdzie skończy się kula bilowa . Przygotowanie do następnego strzału wymaga ogromnych umiejętności i wprawy, ale oznacza również, że wygląda na łatwe.

Teraz, przenosząc tę ​​metaforę do kodu, dobry programista pisze kod, który wygląda na to, że było to łatwe i łatwe do zrobienia . Wiele przykładów Briana Kernighana w jego książkach jest zgodnych z tym wzorem. Część „sztuczki” polega na właściwej koncepcji problemu i jego rozwiązaniu . Kiedy nie rozumiemy wystarczająco dobrze problemu, jesteśmy bardziej skłonni do nadmiernego komplikowania naszych rozwiązań i nie zobaczymy ujednolicających pomysłów.

Dzięki odpowiedniej konceptualizacji problemu otrzymujesz wszystko inne: czytelność, łatwość konserwacji, wydajność i poprawność. Ponieważ rozwiązanie wydaje się takie proste, prawdopodobnie będzie mniej komentarzy, ponieważ dodatkowe wyjaśnienia nie są konieczne. Dobry programista może również zobaczyć długoterminową wizję produktu i odpowiednio sformułować ich konceptualizacje.

Macneil
źródło
10
„dobry programista pisze kod, który wygląda na łatwy i prosty do wykonania”. << DOKŁADNIE! Myślę, że dzieje się tak, ponieważ ludzie zwykle myślą, że dobrym programistą jest ktoś, kto potrafi pisać bardzo „sprytne” hacki. Jeśli kod jest czysty i niezbyt „sprytny”, musi być łatwy, prawda?
hasen
3
Moje 2 centy: kiedy masz język z automatycznymi refaktoryzacjami EASY - Java i C # to dwa przykłady, które znam najlepiej - iteracyjnie łatwo przejść do dobrego kodu. W przeciwnym razie trzeba przede wszystkim dobrze pojęć, ale jest tam pewien problem z jajkiem kurzym.
Dan Rosenstark,
3
Niektóre algorytmy są z natury złożone. Dobry programista nie powinien mieć problemu z pisaniem ich, gdy są naprawdę potrzebne - i utrzymywaniem ich na tyle, na ile to możliwe.
J-16 SDiZ
2
@hasenj: tak, to z powodu tego lematu: głupi ludzie piszą kod, który kompilator rozumie. Mądrzy ludzie piszą kod, głupi ludzie rozumieją.
v.oddou
49

WTF za minutę

( oryginał )


EDYCJA: Podstawową ideą jest to, że „Jakość kodu” nie może być poddana regułom, w taki sam sposób, w jaki nie można umieścić w regułach „Dobrej sztuki” lub „Dobrej poezji”, aby komputer mógł określić „Tak, dobra sztuka” lub „Nie, zła poezja”. Obecnie jedynym sposobem jest sprawdzenie, jak łatwo kod jest zrozumiały dla innych ludzi.


źródło
1
Utknęliśmy na tablicy w pracy :-)
Nikt
1
@Cape Cod Gunny był także w książce wuja Boba
mlvljr,
2
Poza tym, że jest świetną kreskówką, myślę, że to naprawdę do rzeczy - dobry kod to kod, który inni ludzie uważają za przyjemny do czytania i utrzymywania.
FinnNk,
1
Tak więc dobry kod to każdy kod, który nie jest zły. Np. Trudno jest zdefiniować dobry kod, łatwiej jest zdefiniować zły kod.
Ernelli,
5
Zwykle znajduję te „WTF?” Na dobrym spotkaniu z kodem, a po nim „Oooooh, dobra ... Rozumiem, co zrobiłeś.”
AndrewKS
7

Naprawdę nie ma dobrych kryteriów poza tym, jak szybko można zrozumieć kod. Sprawiasz, że kod wygląda dobrze, znajdując idealny kompromis między zwięzłością a czytelnością.

„WTF na minutę” (powyżej) jest prawdą, ale jest to jedynie następstwo bardziej ogólnej zasady. Im więcej WTF, tym wolniejsze zrozumienie.

mojuba
źródło
1
@rmx: zdefiniuj „dobrze wykonując zadanie”
mojuba,
2
Cóż, ta RemoveCustomermetoda faktycznie usuwa cutomer bez zepsucia. Możesz spędzać godziny, aby wyglądać ładnie, ale to nie znaczy, że faktycznie działa. „Szybkość rozumienia kodu” nie jest jedynym kryterium „dobrego kodu”, mówię.
Nikt
2
@rmx: ale implikacja, że ​​jest wolna od błędów, prawda? Jeśli twój kod nie wykonuje zadania poprawnie, nie jest to kod (jeszcze).
mojuba,
4
@rmx: w rzeczywistości nie. Jeśli twój kod jest łatwy do zrozumienia, to na koniec łatwo zrozumieć, czy źle działa. OTOH, jeśli trudno to zrozumieć, trudno jest zrozumieć, czy w ogóle spełnia swoje zadanie.
pillmuncher
2
@rmx: PS po prostu, twoja dekrementacja () jest klasycznym WTF, a zatem spowalnia rozumienie części kodu, w których używana jest ta funkcja
mojuba,
5

Wiesz, że piszesz dobry kod, gdy ...

  1. Klient jest zadowolony
  2. Współpracownicy pożyczają twój kod jako punkt wyjścia
  3. Zupełnie nowemu facetowi / galowi powiedziano, żeby wprowadził modyfikacje do systemu zbudowanego 6 miesięcy temu i nigdy nie zadał ci pytania
  4. Twój szef prosi cię o opracowanie nowych widżetów dla zespołu
  5. Patrzysz na kod, który piszesz dzisiaj i mówisz sobie: „Szkoda, że ​​nie napisałem takiego kodu dwa lata temu”

Jak zmierzyć, czy kod jest dobry ...

  • Jaki jest czas reakcji?
  • Ile odbywa się w obie strony na serwer?
  • Czy osobiście użyjesz aplikacji, czy uważasz, że jest niezgrabna?
  • Czy następnym razem zbudowałbyś go w ten sam sposób?

Dobry kod działa, kiedy powinien. Dobry kod można łatwo modyfikować, gdy jest to konieczne. Dobry kod może być ponownie wykorzystany do osiągnięcia zysku.

Michael Riley - AKA Gunny
źródło
2
„Klient jest szczęśliwy” jest do tego ortogonalny.
1
@TRA - Jeśli klient jest zadowolony, oznacza to, że zrozumiałeś wymagania i dostarczył oczekiwane rozwiązanie.
Michael Riley - AKA Gunny
6
jasne, ale zły kod może zrobić to samo.
4

Kod, który jest

  1. bez błędów

  2. wielokrotnego użytku

  3. niezależny

  4. mniej skomplikowane

  5. dobrze udokumentowane

  6. łatwe do zaryzykowania

nazywa się dobrym kodem.

Dobry program działa bezbłędnie i nie zawiera błędów. Ale jakie cechy wewnętrzne dają taką doskonałość ?. To nie jest tajemnica, potrzebujemy tylko od czasu do czasu przypomnienia. Niezależnie od tego, czy kodujesz w C / C ++, C #, Java, Basic, Perl, COBOL lub ASM, wszystkie dobre programy wykazują te same uświęcone cechy: prostotę, czytelność, modułowość, nakładanie warstw, projektowanie, wydajność, elegancję i przejrzystość, elegancję i jasność

Źródło: MSDN

Chankey Pathak
źródło
Prostota, czytelność, elegancja i przejrzystość są tym samym. Modułowość i nakładanie warstw to tylko metody na uczynienie kodu czytelnym i eleganckim. Jedyne, co pozostało na liście, to wydajność, co jest swego rodzaju dorozumiane, a poza tym często chodzi o kompromis między wydajnością a klarownością.
mojuba,
Sprawdź to: goo.gl/hdQt8
Chankey Pathak
2
Kod może być wolny od błędów?
Casey Patton
Nie, nie może. (Praktycznie)
Chankey Pathak
Wydajne należy dodać do listy. Szybkość niekoniecznie jest podstawowym wskaźnikiem dobrego kodu, ale dobry kod nie powinien być niepotrzebnie powolny ani marnotrawny.
Caleb
3

Czy to wydaje się znajome?

Philips dał mi możliwość obejrzenia projektu nowego produktu. Z biegiem czasu stałem się coraz bardziej niespokojny i zacząłem zwierzyć się mojemu przełożonemu. Wielokrotnie powtarzałem mu, że projekty nie były „czyste” i że powinny być „piękne”, tak jak projekty Dijkstry były piękne. Nie uważał tego za użyteczny komentarz. Przypomniał mi, że jesteśmy inżynierami, a nie artystami. W jego umyśle po prostu wyrażałem swój gust, a on chciał wiedzieć, jakiego kryterium użyłem przy ocenie. Nie mogłem mu powiedzieć! Ponieważ nie mogłem wyjaśnić, jakie zasady były naruszane, moje komentarze zostały po prostu zignorowane i praca trwała. Wyczuwając, że musi istnieć sposób na wyjaśnienie i motywację mojego „smaku”, Zacząłem szukać zasady, która odróżniałaby dobre projekty od złych. Inżynierowie są bardzo pragmatyczni; mogą podziwiać piękno, ale szukają użyteczności. Próbowałem znaleźć wyjaśnienie, dlaczego „piękno” było przydatne.

Zobacz resztę tutaj .

mlvljr
źródło
1
Ponieważ link w poście @ mlvljr jest uszkodzony, oto link do strony Książek Google: books.google.co.in/…
balajeerc
@balajeerc Dzięki (naprawiłem również link, więc wskazuje na wersję hostowaną przez Springera w tym samym pliku pdf) :)
mlvljr
1

poza naturalnymi kryteriami jakości kodu (minimalna liczba kopii / wklejenia, bez spaghetti itp.) dobry kod przemysłowy powinien zawsze wyglądać naiwnie, trochę zbyt gadatliwie, jak

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

w przeciwieństwie do

Record r = cache.get(i++, false);
Bobah
źródło
Ale czy do_not_create = falseoznacza „ podać falsejako do_not_createargument, aby został utworzony” lub „przekazać falsejako do_createargument, aby nie został utworzony”? W języku, w którym można używać nazw argumentów, wolałbym cache.get (key:i, create: false); i += 1;.
PJTraill,
1

Być może pomoc w zilustrowaniu czegoś przeciwnego pomogłaby (plus wymówka, aby uzyskać tutaj XKCD ).

alternatywny tekst

Dobry kod to

  • prosty do zrozumienia,
  • łatwy w utrzymaniu,
  • nie próbuje rozwiązać wszystkich problemów tylko pod ręką
  • żyje długo, nie zmuszając programistów do szukania alternatyw

Przykłady obejmują

  • Apache Commons
  • Ramy wiosenne
  • Hibernacja frameworka
Gary Rowe
źródło
1

Po prostu pójdę z „utrzymywalnym”

Cały kod musi być zachowany: nie ma potrzeby, aby to zadanie było trudniejsze niż to konieczne

Jeśli któryś czytelnik nie rozumie tego prostego wymogu lub potrzebuje go przeliterować, to ten czytelnik nie powinien pisać kodu ...

gbn
źródło
1

Dobry kod będzie różny dla każdej osoby, a język, z którym pracuje, ma również wpływ na coś, co może być uważane za dobry kod. Zasadniczo, kiedy podchodzę do projektu, szukam następujących rzeczy:

  • Jak zorganizowany jest projekt? Czy pliki źródłowe są uporządkowane i czy mogę bez trudu znaleźć kod?
  • Jak zorganizowany jest kod? Czy jest jasno udokumentowane, co robi kod w pliku, na przykład poprzez użycie nagłówka pliku lub użycie każdej klasy znajdującej się w jego własnym pliku? Czy w pliku są funkcje, które nie są już używane w aplikacji?
  • Jak zorganizowane są funkcje? Czy istnieje wyraźny wzorzec do deklarowania zmiennych, czy jest to dość losowy wzorzec? Czy kod ma logiczny przepływ i unika niepotrzebnych struktur kontrolnych? Czy wszystko jest w pełni udokumentowane, a kod jest samodokumentujący tam, gdzie jest potrzebny, a komentarze jasno wyrażają, dlaczego i / lub co robi kod?

Poza tym, czy projekt aplikacji ma sens jako całość? Kod znajdujący się w aplikacji może być najlepszy na świecie, ale nadal może być trudny w pracy, jeśli ogólny projekt aplikacji nie ma sensu.

rjzii
źródło
1

Pozwólcie, że nie zgadzam się co do czytelności. Nie, nie do końca: dobry kod powinien być czytelny i można to łatwo osiągnąć za pomocą wystarczającej liczby komentarzy.

Rozważam jednak dwa rodzaje WTF: te, w których zastanawiasz się, czy programista przekroczył programowanie 101, i te, w których absolutnie nie rozumiesz genialności kodu. Niektóre kody na początku mogą wyglądać bardzo dziwnie, ale w rzeczywistości są bardzo pomysłowym rozwiązaniem trudnego problemu. Drugi nie powinien się liczyć w mierniku WTF i można tego uniknąć dzięki komentarzom.

Bardzo czytelny kod może być bardzo, bardzo wolny. Mniej czytelne rozwiązanie może wielokrotnie zwiększyć prędkość. R jest doskonałym przykładem języka, w którym często tak jest. Lubi się unikać pętli for jak najwięcej. Ogólnie uważam, że najszybszy kod jest lepszy, nawet jeśli jest mniej czytelny. Oznacza to, że jeśli poprawa jest znaczna poza kursem i wstawiono wystarczającą liczbę komentarzy, aby wyjaśnić, co robi kod.

Co więcej, zarządzanie pamięcią może mieć kluczowe znaczenie w wielu zastosowaniach naukowych. Kod, który jest bardzo czytelny, jest raczej niechlujny w użyciu pamięci: powstaje tylko więcej obiektów. W niektórych przypadkach inteligentne wykorzystanie pamięci powoduje, że kod jest mniej czytelny. Ale jeśli na przykład żonglujesz gigabajtami sekwencji DNA, kluczowym czynnikiem jest pamięć. Ponownie uważam, że kod wymagający mniejszej ilości pamięci jest lepszy, niezależnie od czytelności.

Tak, więc czytelność jest ważna dla dobrego kodu. Znam adagium Uwe Liggisa: myślenie boli, a komputery są tanie. Ale w mojej dziedzinie (genomika statystyczna) obliczeniowe czasy tygodnia i zużycie pamięci powyżej 40 Gb nie są uważane za nieprawidłowe. Tak więc poprawa dwukrotnie większej prędkości i połowy pamięci jest warta dużo więcej niż ta dodatkowa odrobina czytelności.

Joris Meys
źródło
Brak reguł / reguł bez wyjątku
2664856
1
Nie zgadzam się z twoją niezgodą: mówisz, że w twoim polu prędkość jest bardzo ważna i mówisz, że jest ważniejsza niż czytelność. Nie zgadzam się, powinieneś starać się zachować właściwą równowagę. Jeśli prędkość nie jest potrzebna, na przykład dla interfejsu wysokiego poziomu, możesz preferować coś łatwego w utrzymaniu, jeśli prędkość jest potrzebna, zgadzam się z tobą. Zamiast twardych zasad lepiej jest kierować się zdrowym rozsądkiem i i tak należy unikać przedwczesnej optymalizacji.
BlueTrin
@BlueTrin Dlaczego nie skompilujesz mózgu tych kodeków źródłowych wysokiej jakości, a także udokumentujesz, co się tam dzieje (tam, w komentarzach)?
mlvljr
1

Jeśli chodzi o mnie ... Wiem, że piszę dobry kod, gdy pojawia się współpracownik, który pracuje nad innym projektem i jest w stanie wskoczyć i zrozumieć, co robię, bez przechodzenia przez każdy blok kodu i pokazując, co robi.
Zamiast tego powiedział: „Chwileczkę, co ?!” Mówi: „Och, ok, widzę, co tam zrobiłeś”.

Dobry kod również nie zawiera wielu podstępnych obejść ani „hacków”. Linie, kiedy pisząc to, mówisz także do siebie: „Wiem, że to nie jest dobry sposób, aby to zrobić, ale na razie będę musiał to zrobić w ten sposób. Przypomnę sam, aby to poprawić później ... ”

chiurox
źródło
1

Istnieje wiele funkcji „dobrego” kodu, ale najważniejsze, IMHO, to czytelność i łatwość konserwacji.

Twój kod będzie zawierał błędy, prawdopodobnie zostanie rozszerzony i ponownie użyty, i w pewnym momencie powinien zostać ponownie uwzględniony - nawet jeśli ponownie go odwiedzasz, są szanse, że nie będziesz miał pojęcia, co do cholery Zrobiliście to przede wszystkim, aby zrobić sobie przysługę i nie stawiać żadnych przeszkód.

Jasne, użyj tego złożonego, ale jeszcze wydajniejszego algorytmu, ale upewnij się, że poświęcasz mu trochę czasu na dokumentowanie go, ale w przeciwnym razie spraw, aby kod był przejrzysty i spójny.

cjmUK
źródło