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

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”?

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.

( 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.

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.

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.

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

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 .

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);

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

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

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 ...

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.

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.

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 ... ”

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.