Jak wygląda kod dobrego programisty? [Zamknięte]

90

Jestem programistą hobbystą (zacząłem od VBA, aby przyspieszyć osiąganie doskonałości) i pracuję z VB.NET / C # .NET i próbuję nauczyć się ADO.NET.

Aspektem programowania, który zawsze mnie frustrował, jest to, jak wygląda „dobre”? Nie jestem profesjonalistą, więc nie mam z czym porównać. Co czyni lepszego programistę? Czy to:

  • Lepiej rozumieją wszystkie obiekty / klasy / metody w danym języku?
  • Ich programy są bardziej wydajne?
  • Projekt ich programów jest znacznie lepszy pod względem lepszej dokumentacji, dobrego wyboru nazw funkcji itp.?

Innymi słowy, gdybym miał spojrzeć na kod profesjonalnego programisty, jaka jest pierwsza rzecz, którą bym zauważył w jego kodzie w stosunku do mojego? Na przykład czytam książki takie jak „Professional ASP.NET” wydawnictwa Wrox press. Czy przykłady kodu w tej książce są „światowej klasy”? Czy to szczyt? Czy któryś z najlepszych programistów spojrzałby na ten kod i pomyślałby, że to dobry kod?

Alex P
źródło

Odpowiedzi:

131

Poniższa lista nie jest wyczerpująca, ale właśnie o tym pomyślałem, rozważając twoje pytanie.

  • Dobry kod jest dobrze zorganizowany. Dane i operacje w klasach pasują do siebie. Nie ma żadnych zewnętrznych zależności między klasami. Nie wygląda jak „spaghetti”.

  • Dobre komentarze do kodu wyjaśniają, dlaczego coś się robi, a nie to, co się robi. Sam kod wyjaśnia, co się dzieje. Potrzeba komentarzy powinna być minimalna.

  • Dobry kod używa znaczących konwencji nazewnictwa dla wszystkich obiektów oprócz tych najbardziej przejściowych. nazwa czegoś informuje o tym, kiedy i jak używać obiektu.

  • Dobry kod jest dobrze przetestowany. Testy służą jako wykonywalna specyfikacja kodu i przykłady jego użycia.

  • Dobry kod nie jest „sprytny”. Robi rzeczy w prosty, oczywisty sposób.

  • Dobry kod jest tworzony w małych, łatwych do odczytania jednostkach obliczeniowych. Te jednostki są ponownie wykorzystywane w całym kodzie.

Jeszcze tego nie przeczytałem, ale książka, którą zamierzam przeczytać na ten temat, to Clean Code autorstwa Roberta C. Martina.

tvanfosson
źródło
9
Bardzo dobre uwagi. Szczególnie podoba mi się uwaga „dobry kod nie jest mądry”. Niezwykle trudno jest napisać kod, który inni ludzie uważają za czytelny i możliwy do utrzymania. Pisanie kodu „psiego śniadania”, którego nikt nie rozumie (w tym Ciebie po chwili) jest najłatwiejszą rzeczą na świecie.
Stein Åsmul
3
Dobry kod nie jest „sprytny”. Robi rzeczy w prosty, oczywisty sposób. najlepsza część
nawfal
2
Martin's Clean Code to doskonała książka. Ogólnie rzecz biorąc, dobre programowanie to po prostu dobre pisanie. Może to zabrzmieć szaleńczo, ale polecam przeczytanie „Polityka i język angielski” Orwella . Jest bardzo krótki, ale zauważysz, że obserwacje Orwella w dużym stopniu pokrywają się z pismami ludzi takich jak Martin. Nic więc dziwnego, że ludzie tacy jak Martin są świetnymi pisarzami, a także świetnymi programistami.
0x1mason
@tvanfosson Czy przeczytałeś już książkę? :-)
Natan Streppel
Wiele się nauczyłem z tej książki i jej czytanie nie jest nudne.
reggie
94

Pierwszą rzeczą, jaką można zauważyć, jest to, że ich kod jest zgodny ze spójnym stylem kodowania . Zawsze piszą te same bloki struktury, wciskają religijnie i komentują w razie potrzeby.

Drugą rzeczą, którą można zauważyć, jest to, że ich kod jest podzielony na małe metody / funkcje obejmujące maksymalnie kilkadziesiąt linii. Używają również samoopisujących się nazw metod i generalnie ich kod jest bardzo czytelny.

Trzecią rzeczą, którą zauważysz, po tym, jak trochę pomieszałeś z kodem, jest to, że logika jest łatwa do naśladowania, łatwa do modyfikacji - a zatem łatwa w utrzymaniu.

Następnie będziesz potrzebować pewnej wiedzy i doświadczenia w zakresie technik projektowania oprogramowania, aby zrozumieć konkretne wybory, których podjęli się przy tworzeniu architektury kodu.

Jeśli chodzi o książki, nie widziałem wielu książek, w których kod można by uznać za „światowej klasy”. W książkach starają się głównie przedstawiać proste przykłady, które mogą być przydatne przy rozwiązywaniu bardzo prostych problemów, ale nie odzwierciedlają bardziej złożonych sytuacji.

Eran Galperin
źródło
1
+1 za bardzo skuteczne podsumowanie. Jeszcze jedną rzeczą, którą można dodać, jest unikanie zbyt wielu zagnieżdżonych gałęzi. Prawdopodobnie dwa poziomy są do zaakceptowania, a potem staje się zbyt trudne.
Naveen,
Masz rację. Myślałem o dodaniu tego, ale pomyślałem, że może to być zbyt szczegółowe
Eran Galperin
Naprawdę dobre podsumowanie. Jeśli chodzi o kilka linijek kodu, myślę, że dla początkujących byłoby dobrze powiedzieć, że jest to WYNIK czystego kodu, a nie sposób na uzyskanie czystego kodu - nie zmuszaj się do pisania małych funkcji, zrobisz to w każdym razie, jeśli na przykład twój projekt jest zgodny z zasadą KISS.
Klaim
Nie kładłbym zbyt dużego nacisku na „małe funkcje”, ani jako cel, ani jako wynik. Zbyt wiele małych funkcji jest tak samo trudnych do prześledzenia, jak strony z nieprzejrzystym kodem.
staticsan
1
Chociaż czasami jest to nieuniknione, generalnie, kiedy patrzę na długie metody, myślę: „czy ta metoda próbuje wiele zrobić? A może zastąpienie niektórych bloków logiki metodami o znaczących nazwach?” Uważam, że podążanie za logiką złożoną z takich metod jest znacznie łatwiejsze niż próba przetrawienia całej logiki naraz
Eran Galperin,
71

Cytując Fowlera, podsumowując czytelność:

Każdy głupiec może napisać kod zrozumiały dla komputera.
Dobrzy programiści piszą kod zrozumiały dla ludzi.

nie powiedział.

chakrit
źródło
Whoa +1, za bycie krótkim i słodkim
devsaw
5
Cóż, jest tam cały kod kiedykolwiek napisany w Perlu.
Czy będę
Cokolwiek napiszę, mój NAUCZYCIEL LABORATORIUM nigdy nie zrozumie: p
Prakash Bala
32

Osobiście będę musiał zacytować „Zen Pythona” Tima Petersa. Mówi programistom Pythona, jak powinien wyglądać ich kod, ale uważam, że dotyczy to w zasadzie całego kodu.

Piękne jest lepsze niż brzydkie.
Jawne jest lepsze niż niejawne.
Proste jest lepsze niż złożone.
Złożone jest lepsze niż skomplikowane.
Płaskie jest lepsze niż zagnieżdżone.
Rzadkie jest lepsze niż gęste.
Liczy się czytelność.
Specjalne przypadki nie są na tyle wyjątkowe, aby łamać zasady.
Chociaż praktyczność przewyższa czystość.
Błędy nigdy nie powinny przejść bezgłośnie.
Chyba że wyraźnie uciszono.
W obliczu niejasności odrzuć pokusę zgadywania.
Powinien być jeden - a najlepiej tylko jeden - oczywisty sposób na zrobienie tego.
Chociaż na początku może to nie być oczywiste, chyba że jesteś Holendrem.
Teraz jest lepiej niż nigdy.
Chociaż nigdy nie jest często lepsze niżprawo teraz.
Jeśli implementacja jest trudna do wyjaśnienia, to zły pomysł.
Jeśli implementacja jest łatwa do wyjaśnienia, może to być dobry pomysł.
Przestrzenie nazw to jeden wspaniały pomysł - zróbmy ich więcej!

Andrew
źródło
2
Jedyny problem z „Powinien istnieć jeden - a najlepiej tylko jeden - oczywisty sposób na zrobienie tego”. Oczywisty sposób zależy w dużej mierze od sposobu, w jaki myślisz o problemie. To jest konieczne, a nie funkcjonalne.
grom
„Mieszkanie jest lepsze niż zagnieżdżone” jest bardzo wątpliwe.
Íhor Mé
16

Kod to poezja.

Zacznij od tego punktu logiki, a będziesz mógł wyprowadzić wiele pożądanych cech kodu. Co najważniejsze, zauważ, że kod jest czytany znacznie częściej niż jest napisany, dlatego pisz kod dla czytelnika. Przepisuj, zmieniaj nazwę, edytuj i refaktoryzuj dla czytelnika.

Następujący wniosek:

Czytelnik będzie Tobą w czasie n od daty utworzenia kodu. Opłatą za pisanie kodu dla czytelnika jest monotonicznie rosnąca funkcja n. Czytelnik, który po raz pierwszy patrzy na twój kod, jest oznaczony przez n == nieskończoność.

Innymi słowy, im większa przerwa czasowa od momentu napisania kodu do ponownego odwiedzenia kodu, tym bardziej docenisz wysiłki związane z pisaniem dla czytelnika. Ponadto każdy, komu przekażesz swój kod, odniesie duże korzyści z kodu napisanego z czytelnikiem jako najważniejszej rzeczy.

Drugi wniosek:

Kod napisany bez uwzględnienia czytelnika może być niepotrzebnie trudny do zrozumienia lub użycia. Kiedy zysk dla czytelnika spadnie poniżej pewnego progu, czytelnik czerpie z kodu mniejszą wartość niż wartość uzyskana przez przepisanie kodu. W takim przypadku poprzedni kod jest wyrzucany i, tragicznie, wiele pracy jest powtarzanych podczas przepisywania.

Trzeci wniosek:

Wniosek drugi jest znany z wielokrotnego powtarzania się w błędnym kole źle udokumentowanego kodu, po którym następuje wymuszone przepisanie.

Jarred McCaffrey
źródło
Z wyjątkiem tego, że w przypadku kodu powinno być oczywiste, co dokładnie masz na myśli. +1
Rik,
Kiedyś widziałem, jak Richard Gabriel opowiadał programistom o pisaniu wierszy. Trochę mi zajęło nawiązanie połączenia.
Thorbjørn Ravn Andersen
15

Programuję od 28 lat i trudno mi odpowiedzieć na to pytanie. Dla mnie dobry kod to kompletny pakiet. Kod jest napisany przejrzyście, ze znaczącymi nazwami zmiennych i metod. Zawiera dobrze umieszczone komentarze, które komentują intencję kodu i nie tylko zwracają kod, który już możesz przeczytać. Kod robi to, co powinien, w efektywny sposób, bez marnowania zasobów. Musi być również napisany z myślą o łatwości konserwacji.

Najważniejsze jest jednak to, że oznacza to różne rzeczy dla różnych ludzi. To, co mogę nazwać dobrym kodem, którego ktoś inny może nienawidzić. Dobry kod będzie miał kilka wspólnych cech, które, jak sądzę, zidentyfikowałem powyżej.

Najlepszą rzeczą, jaką możesz zrobić, jest wystawienie się na kod. Spójrz na kod innych ludzi. Projekty Open Source są do tego dobrym źródłem. Znajdziesz dobry kod i zły kod. Im więcej na to patrzysz, tym lepiej rozpoznasz to, co określisz jako dobry i zły kod.

Ostatecznie będziesz swoim własnym sędzią. Kiedy znajdziesz style i techniki, które lubisz je przyjąć, z czasem wymyślisz swój własny styl, który z czasem się zmieni. Nie ma tu osoby, która mogłaby machać różdżką i powiedzieć, co jest dobre, a co inne złe.

bruceatk
źródło
8

Sam programując od prawie 10 lat i pracując z innymi, mogę bez uprzedzeń powiedzieć, że nie ma różnicy między dobrym programistą a przeciętnym programistą.

Wszyscy programiści na kompetentnym poziomie:

  • Skomentuj poprawnie
  • Struktura efektywnie
  • Dokumentuj czysto

Kiedyś usłyszałem, jak współpracownik powiedział: „ Zawsze byłem bardzo logiczny i racjonalny. Myślę, że właśnie dlatego lubię się rozwijać

Moim zdaniem taki jest umysł przeciętnego programisty. Ten, kto postrzega świat w kategoriach reguł i logiki i ostatecznie przestrzega tych zasad podczas projektowania i pisania programu.

Doświadczony programista rozumie zasady, ale także ich kontekst. To ostatecznie prowadzi do nowych pomysłów i wdrożeń, co jest znakiem eksperta programisty. Programowanie jest ostatecznie formą sztuki.

AAA
źródło
Nie tyle sztuka, co rzemiosło.
Thorbjørn Ravn Andersen
Szczerze mówiąc najbardziej podoba mi się definicja. Znam wielu programistów, którzy wierzą w super twarde i szybkie zasady i nie widzą szerszego obrazu tego, dlaczego te zasady zostały stworzone i są w przypadkach przeznaczonych do złamania
Lance Bryant
6

Krótko mówiąc, kod dobrego programisty można odczytać i zrozumieć.

Moim zdaniem dobry kod programisty jest niezależny od języka ; dobrze napisany kod można odczytać i zrozumieć w krótkim czasie przy minimalnym myśleniu, niezależnie od używanego języka programowania. Niezależnie od tego, czy kod jest napisany w Javie, Pythonie, C ++ czy Haskell, dobrze napisany kod jest zrozumiały dla osób, które nawet nie programują w tym konkretnym języku.

Niektóre cechy łatwego do odczytania kodu to: dobrze nazwane metody, brak "sztuczek" i zawiła "optymalizacja", klasy są dobrze zaprojektowane, by wymienić tylko kilka. Jak wspominali inni, styl kodowania jest spójny, zwięzły i prosty .

Na przykład pewnego dnia przyjrzałem się kodowi TinyMCE, aby odpowiedzieć na jedno z pytań dotyczących przepełnienia stosu. Jest napisany w JavaScript, języku, którego prawie nie używałem. Jednak ze względu na styl kodowania i zawarte w nim komentarze, a także strukturę samego kodu, było to dość zrozumiałe i mogłem przejść przez kod w kilka minut.

Jedną z książek, która otworzyła mi oczy w kwestii czytania dobrego kodu programisty, jest Piękny kod . Zawiera wiele artykułów napisanych przez autorów różnych projektów programistycznych w różnych językach programowania. Jednak kiedy to przeczytałem, mogłem zrozumieć, co autor pisze w swoim kodzie, mimo że nigdy nie programowałem w tym konkretnym języku.

Być może powinniśmy pamiętać, że programowanie to także komunikacja, nie tylko z komputerem, ale z ludźmi , więc dobry kod programisty jest prawie jak dobrze napisana książka, która może przekazać czytelnikowi idee, które chce przekazać .

coobird
źródło
Moim zdaniem dobry kod programisty jest
niezależny od
6
  • Łatwe do odczytania
  • łatwe do napisania
  • łatwe w utrzymaniu

wszystko inne jest filigranowe

kloucks
źródło
„Łatwy do odczytania” dla programisty A i „łatwy w utrzymaniu” dla programisty B to dwa sprzeczne cele, których nigdy nie da się osiągnąć. Każde kodowanie obejmuje kompromis między tymi dwoma w zależności od priorytetów biznesowych. Pisanie kodu, który jest łatwy do odczytania dla kogokolwiek innego, sprawia, że ​​jest on trudniejszy w utrzymaniu dla tego, kto go napisał.
alpav
@alpav: to, co mówisz, jest absolutnie prawdziwe dla programistów niespełniających standardów, NIE dla programistów średnio zaawansowanych i doświadczonych, którzy wiedzą, że za rok będą musieli utrzymywać własny kod, którego nie mają pamięci, więc chcą, aby był on dokładnie czytelny i łatwy do utrzymać. MOŻNA je osiągnąć i robiłem to wielokrotnie przez 30 lat, całkowicie się mylisz.
kloucks
1
alpav: Czy możesz podać przykład tego, jak są ze sobą sprzeczne? Wydają mi się idealnie dopasowane: jak możesz coś utrzymać, jeśli nie możesz tego przeczytać?
Ken
5

Dobry kod powinien być łatwy do zrozumienia.
Powinien być dobrze skomentowany.
Trudne fragmenty należy jeszcze lepiej skomentować.

Burkhard
źródło
Nie jestem pewien, czy możesz powiedzieć `` dobry kod powinien być łatwy do zrozumienia '' - jakiś kod wykonuje bardzo złożone funkcje, te funkcje same w sobie nie są łatwe do zrozumienia, więc nie od razu wynika, że ​​kod, którego nie możesz zrozumieć, jest złym kodem - może być świetny kod działający na podstawie złożonej koncepcji.
mięso
Czy złożony, dobry kod można by uznać za sprytny kod?
kevindaub
4

Dobry kod jest czytelny. Nie miałbyś problemu ze zrozumieniem, co robi kod po pierwszym przeczytaniu kodu napisanego przez dobrego profesjonalnego programistę.

Bill the Lizard
źródło
Niestety „czytelny” to rzecz subiektywna.
Gewthen
3

Zamiast powtórzyć wspaniałe sugestie innych, zasugeruję, abyś przeczytał książkę Code Complete autorstwa Steve'a McConnella

Zasadniczo jest to książka pełna najlepszych praktyk programistycznych dotyczących zarówno funkcjonalności, jak i stylu.

Liści
źródło
2

[Czysto subiektywna odpowiedź]
Dla mnie dobry kod jest formą sztuki, podobnie jak obraz. Mógłbym pójść dalej i powiedzieć, że to właściwie rysunek, który zawiera znaki, kolory, „formę” lub „strukturę” kodu, a wszystko to jest tak czytelne / wydajne. Kombinacja czytelności, struktury (tj. Kolumny, wcięcia, a nawet nazw zmiennych o tej samej długości!), Koloru (nazwy klas, nazwy zmiennych, komentarze itp.) - wszystko to sprawia, że ​​to, co lubię widzieć jako „piękny” obraz, który może czynią mnie albo bardzo dumnym, albo bardzo odrażającym z mojego własnego kodu.

(Jak powiedziałem wcześniej, bardzo subiektywna odpowiedź. Przepraszam za mój angielski.)

Hosam Aly
źródło
2

Popieram rekomendację „Clean Code” Boba Martina.

„Piękny kod” spotkał się z dużym uznaniem kilka lat temu.

Warto przeczytać każdą książkę McConnella.

Być może „Pragmatyczny programista” też by się przydał.

%

duffymo
źródło
2

Chciałem tylko dodać moje 2 centy ... komentarze do twojego kodu - i ogólnie twój kod - powinny powiedzieć, co robi twój kod, teraz jak to robi. Kiedy już masz pojęcie kodu „klienta”, czyli kodu wywołującego inny kod (najprostszym przykładem jest kod wywołujący metodę), zawsze powinieneś się najbardziej martwić o to, aby kod był zrozumiały z perspektywy „klienta”. Wraz z rozwojem kodu zobaczysz, że to jest ... hm, dobrze.

Wiele innych rzeczy związanych z dobrym kodem dotyczy skoków mentalnych, które wykonasz (zdecydowanie, jeśli zwrócisz uwagę) ... 99% z nich ma do czynienia z odrobiną pracy teraz, aby zaoszczędzić ci mnóstwo pracować później i wielokrotnego użytku. A także z robieniem rzeczy dobrze: prawie zawsze chcę działać w drugą stronę, zamiast używać wyrażeń regularnych, ale za każdym razem, gdy wchodzę w to, rozumiem, dlaczego wszyscy używają ich w każdym języku, w którym pracuję (są zawiłe, ale pracy i prawdopodobnie nie mogło być lepiej).

Co do tego, czy patrzeć na książki, powiedziałbym zdecydowanie nie z mojego doświadczenia. Spójrz na interfejsy API, frameworki, konwencje kodowe i kod innych ludzi, użyj własnych instynktów i spróbuj zrozumieć, dlaczego rzeczy są takie, jakie są i jakie są tego konsekwencje. To, czego kod w książkach prawie nigdy nie robi, to planowanie nieplanowanych, i właśnie o to chodzi w sprawdzaniu błędów. Opłaca się to tylko wtedy, gdy ktoś wyśle ​​Ci wiadomość e-mail i powie: „Mam błąd 321” zamiast „hej, aplikacja jest zepsuta”.

Dobry kod jest napisany z myślą o przyszłości, zarówno z perspektywy programisty, jak i użytkownika.

Dan Rosenstark
źródło
1

Odpowiedzi na to całkiem dobrze można znaleźć w książce Fowlera „Refaktoryzacja”. To brak wszystkich „zapachów”, które opisuje w całej książce.

dkretz
źródło
1

Nie widziałem „Professional ASP.NET”, ale zdziwiłbym się, gdyby było lepsze niż OK. Zobacz to pytanie w przypadku niektórych książek z naprawdę dobrym kodem. (Oczywiście jest różny, ale akceptowana odpowiedź jest trudna do pokonania).

Darius Bacon
źródło
1

Wydaje się, że to (powinno być) FAQ. Jest ACM artykuł o pięknej kodu niedawno. Wydaje się, że duży nacisk kładzie się na łatwość czytania / zrozumienia. Kwalifikowałbym to jako „łatwe do odczytania / zrozumienia przez ekspertów dziedzinowych”. Naprawdę dobrzy programiści mają tendencję do używania najlepszych algorytmów (zamiast naiwnych, łatwych do zrozumienia algorytmów O (n ^ 2)) dla danych problemów, co może być trudne do zrozumienia, jeśli nie znasz algorytmu, nawet jeśli dobrze programista podaje odniesienie do algorytmu.

Nikt nie jest doskonały w tym dobrych programistów, ale ich kod wydają się dążyć do:

  1. Poprawność i wydajność dzięki sprawdzonym algorytmom (zamiast naiwnych i doraźnych hacków)
  2. Jasność (komentarz intencyjny w odniesieniu do nietrywialnych algorytmów)
  3. Kompletność obejmująca podstawy (konwencja kodowania, wersjonowanie, dokumentacja, testy jednostkowe itp.)
  4. Zwięzłość (SUCHA)
  5. Solidność (odporność na arbitralne dane wejściowe i zakłócenia żądań zmian)
ididak
źródło
1

Jeff Atwood napisał fajny artykuł o tym, jak programiści są pierwszym odniesieniem do maszynistek: http://www.codinghorror.com/blog/archives/001188.html

Jako maszynistka zawsze musisz być elegancki w swojej pracy, bardzo ważna jest struktura i odpowiednia „gramatyka”. Teraz przekonwertowanie tego na typowanie „programowe” przyniosłoby ten sam wynik.

Struktura

Komentarze

Regiony

Jestem inżynierem oprogramowania, co oznacza, że ​​podczas mojej edukacji spotkałem się z wieloma różnymi językami, ale moje programowanie zawsze „czuję” to samo, podobnie jak moje pisanie na fekberg.wordpress.com, mam „specjalny” sposób pisania.

Teraz programując różne aplikacje w różnych językach, takich jak Java, C #, Assembler, C ++, C Doszedłem do „standardu” pisania, który lubię.

Widzę wszystko jako „pudełka” lub regiony, a każdy region ma swoje wyjaśnienia. Region może być „klasą Person”, a wewnątrz tego regionu mam kilka metod określania właściwości, które mogę nazwać „metodami dostępu” lub takimi, a każda właściwość i region mają własne wyjaśnienia.

Jest to bardzo ważne, zawsze postrzegam mój kod, który robię, jako „część interfejsu API”, podczas tworzenia struktury API, a elegancja jest BARDZO ważna.

Pomyśl o tym. Przeczytaj także mój artykuł, w Communication issues when adapting outsourcingktórym wyjaśnia w przybliżeniu, w jaki sposób zły kod może kolidować, Enterpret as you like: http://fekberg.wordpress.com/2008/12/14/communication-issues-when-adapting-outsourcing/

Filip Ekberg
źródło
0

Dobry kod jest łatwy do zrozumienia, łatwy w utrzymaniu i łatwy do dodania. W idealnym przypadku jest również tak skuteczny, jak to tylko możliwe, bez poświęcania innych wskaźników.

Nerdfest
źródło
0

Dla mnie świetny kod to coś, co jest łatwe do zrozumienia, a jednocześnie wyrafinowane. Rzeczy, które sprawiają, że idziesz, „wow, oczywiście, dlaczego nie pomyślałem o tym w ten sposób?”. Naprawdę dobry kod nie jest trudny do zrozumienia, po prostu rozwiązuje problem w prosty sposób (lub rekurencyjnie, jeśli to jest jeszcze prostsze).

HS.
źródło
0

Dobry kod to miejsce, w którym wiesz, co robi metoda z nazwy. Zły kod to miejsce, w którym musisz dowiedzieć się, co robi kod, aby nadać sens nazwie.

Dobry kod to miejsce, w którym, jeśli go przeczytasz, możesz zrozumieć, co robi, w niewiele więcej czasu niż potrzeba, aby go przeczytać. Zły kod polega na tym, że patrzysz na niego przez wieki, próbując dowiedzieć się, jak to działa.

Dobry kod ma rzeczy nazwane w taki sposób, że trywialne komentarze są niepotrzebne.

Dobry kod jest zazwyczaj krótki.

Dobry kod może być ponownie użyty, aby robić to, co robi gdziekolwiek indziej, ponieważ nie opiera się na rzeczach, które są naprawdę niezwiązane z jego przeznaczeniem.

Dobry kod to zwykle zestaw prostych narzędzi do wykonywania prostych zadań (połączonych w dobrze zorganizowany sposób, aby wykonywać bardziej wyrafinowane zadania). Zły kod jest zwykle ogromnymi narzędziami wielofunkcyjnymi, które są łatwe do złamania i trudne w użyciu.

ChrisA
źródło
0

Kod jest odzwierciedleniem umiejętności i sposobu myślenia programisty. Dobrzy programiści zawsze patrzą w przyszłość - jak będzie działał kod, gdy wymagania lub okoliczności nie będą dokładnie takie, jakie są dzisiaj. Jak bardzo będzie to skalowalne? Jak wygodne będzie, gdy to nie ja obsługuję ten kod? Jak kod będzie nadający się do ponownego wykorzystania, aby ktoś inny wykonujący podobne czynności mógł ponownie użyć kodu i nie pisać go ponownie. A co, gdy ktoś inny próbuje zrozumieć napisany przeze mnie kod.

Kiedy programista ma takie nastawienie, wszystkie inne rzeczy ładnie się układają.

Uwaga: Podstawa kodu jest opracowywana przez wielu programistów z biegiem czasu i zazwyczaj nie ma konkretnego wyznaczenia podstawy kodu dla programisty. Dlatego dobry kod jest odzwierciedleniem wszystkich standardów firmy i jakości jej pracowników.

Ather
źródło
0

(Używam „on” poniżej, ponieważ jest to osoba, do której aspiruję , czasami z sukcesem).

Wierzę, że sednem filozofii dobrego programisty jest to, że zawsze myśli "Piszę dla siebie w przyszłości, kiedy zapomnę o tym zadaniu, dlaczego nad nim pracowałem, jakie były zagrożenia, a nawet jak to kod miał działać ”.

W związku z tym jego kod musi:

  1. Praca (nie ma znaczenia, jak szybko kod dostanie złą odpowiedź. W prawdziwym świecie nie ma częściowego kredytu).
  2. Wyjaśnij, skąd wie, że ten kod działa. Jest to połączenie dokumentacji (javadoc jest moim ulubionym narzędziem), obsługi wyjątków i kodu testowego. W bardzo realnym sensie uważam, że wiersz po wierszu, kod testowy jest cenniejszy niż kod funkcjonalny, jeśli nie z innego powodu niż wyjaśnia „ten kod działa, tak powinien być używany i dlatego powinienem dostać płatny."
  3. Być utrzymywanym. Martwy kod to koszmar. Utrzymanie starego kodu jest obowiązkiem, ale trzeba go wykonać (pamiętaj, że jest „dziedzictwem” w chwili, gdy opuszcza Twoje biurko).

Z drugiej strony uważam, że dobry programista nigdy nie powinien robić takich rzeczy:

  1. Obsesja na punkcie formatowania. Istnieje wiele IDE, edytorów i ładnych drukarek, które mogą formatować kod dokładnie według standardowych lub osobistych preferencji, które uważasz za odpowiednie. Używam Netbeans, raz konfiguruję opcje formatu i od czasu do czasu wciskam alt-shift-F. Zdecyduj, jak chcesz wyglądać kod, skonfiguruj środowisko i pozwól narzędziu wykonać podstawową pracę.
  2. Obsesja na punkcie konwencji nazewnictwa kosztem komunikacji międzyludzkiej. Jeśli konwencja nazewnictwa prowadzi cię do nadawania nazw klasom „IElephantProviderSupportAbstractManagerSupport” zamiast „Zookeeper”, zmień standard, zanim utrudnisz go następnej osobie.
  3. Zapomnij, że pracuje jako zespół z prawdziwymi ludźmi.
  4. Zapomnij, że głównym źródłem błędów kodowania jest teraz jego klawiatura. Jeśli jest pomyłka lub pomyłka, powinien najpierw spojrzeć na siebie.
  5. Zapomnij o tym, co się dzieje. Każda praca, którą wykonuje teraz, aby uczynić swój kod bardziej dostępnym dla przyszłych czytelników, prawie na pewno przyniesie mu bezpośrednie korzyści (ponieważ kto będzie pierwszą osobą poproszoną o sprawdzenie jego kodu?
Bob Cross
źródło
@Ken, ho ho, twój rozum mnie oślepił, sir. Zakładanie teraz gogli: 8-p
Bob Cross,
0
  1. To działa
  2. Posiada testy jednostkowe, które dowodzą, że to działa

Reszta to lukier ...

Ali Afshar
źródło
0
  • Najlepszy kod ma pewną elegancję, którą rozpoznajesz, gdy tylko go zobaczysz.
  • Wygląda na wykonany z dbałością i dbałością o szczegóły. Jest oczywiście wyprodukowany przez kogoś z umiejętnościami i ma w sobie sztukę - można powiedzieć, że wygląda na wyrzeźbiony i wypolerowany, a nie szorstki i gotowy.
  • Jest spójny i łatwo się czyta.
  • Jest podzielony na małe, bardzo spójne funkcje, z których każda wykonuje jedną rzecz i robi to dobrze.
  • Jest minimalnie sprzężony, co oznacza, że ​​zależności są nieliczne i ściśle kontrolowane, zwykle przez ...
  • Funkcje i klasy mają zależności od abstrakcji, a nie od implementacji.
Mike Scott
źródło
0

Jak na ironię, im lepszy programista, tym mniej niezbędny staje się, ponieważ wyprodukowany kod jest łatwiejszy w utrzymaniu przez każdego (zgodnie z ogólną zgodą Erana Galperina).

Z mojego doświadczenia wynika, że ​​jest też odwrotnie. Im gorszy programista, tym trudniejszy jest jego / jej kod, tym bardziej staje się niezbędny, ponieważ żadna inna dusza nie jest w stanie zrozumieć stworzonych zagadek.

Fernando Miguélez
źródło
0

Mam dobry przykład:

Przeczytaj kod źródłowy GWT (google web tookit), zobaczysz, że każdy głupiec to rozumie (niektóre angielskie książki są trudniejsze do odczytania niż ten kod).

Nicolas Dorier
źródło