Czy faktycznie piszesz „czysty kod”? [Zamknięte]

54

Widziałem, jak niektórzy programiści ciągle poprawiali swój kod nie tylko po to, aby „działał dobrze”, ale także aby „wyglądał dobrze”.

IMO, „czysty kod” jest tak naprawdę komplementem wskazującym, że twój kod jest elegancki, doskonale zrozumiały i łatwy w utrzymaniu. Różnica ujawnia się, gdy trzeba wybierać między estetycznym kodem a kodem, który jest stresujący.

Ilu z was pisze „czysty kod”? Czy to dobra praktyka? Jakie są inne zalety lub wady tego?

ykombinator
źródło
Podczas wszystkich moich prób pisania „czystego” kodu zgodnie z dobrze ustalonymi zasadami, nigdy tak naprawdę nie stwierdziłem, że utrzymanie tak dużej skali w oparciu o taką przesłankę jest tak łatwe. Znacznie bardziej istotna była jego niezawodność oraz to, jak dobrze przetestowano i jak dobrze nadaje się do swoich celów (które mogą dotyczyć zarówno implementacji, jak i projektu). Cała czystość na świecie nie może zrekompensować braku któregokolwiek z nich, a czasami najbardziej niezawodny kod, którego nadal używam, nie jest najczystszy, podczas gdy mój najczystszy nie zawsze był najbardziej niezawodny.
Przede wszystkim - ponad czytelność, piękno, SOLID, cokolwiek innego - uznałem za użyteczne nadanie priorytetu niezawodności i „stabilności” (jakość niezmienności w mojej książce, a ponadto brak potrzeby lub chęci zmiany dalej). Wiarygodne i stabilne rzeczy to te, które przetrwały dla mnie próbę czasu, a czasem nie są bardzo czyste w wielu książkach (niektóre z moich najczęściej używanych kodów to kod C z końca lat 80. i wczesnych 90. która stosuje takie rzeczy, jak hackowanie, które prawie nikt już nie rozumie - nadal działa tak niezawodnie).

Odpowiedzi:

52

Twierdziłbym, że wielu z nas nie pisze czystego kodu . Ogólnie rzecz biorąc, to nie jest nasza praca . Naszym zadaniem jako programistów jest dostarczanie produktu, który działa na czas.

Przypomina mi się wpis na blogu Joela Spolsky'ego: The Duct Tape Programmer .

Cytuje z Coders at Work :

Pod koniec dnia wyślij f ***** g rzecz! Wspaniale jest przepisać kod i uczynić go czystszym, a po raz trzeci będzie naprawdę ładny. Ale nie o to chodzi - nie ma cię tutaj, aby pisać kod; jesteś tutaj, aby wysyłać produkty. - Jamie Zawinsky

Przypomina mi się również odpowiedź Roberta Martina na blogu :

Więc. Bądź mądry. Być czystym. Bądź prosty. Statek! I trzymaj małą rolkę taśmy izolacyjnej w gotowości i nie bój się jej użyć. - Wujek Bob

Jeśli kod, który pisze programista, okazuje się być czysty ORAZ działa (jest dostarczalny), niech tak będzie, dobry dla wszystkich. Ale jeśli programiści majstrują wokół, próbując stworzyć czysty i czytelny kod kosztem możliwości dostarczenia go w odpowiednim czasie, to źle. Uruchom to, użyj taśmy izolacyjnej i wyślij. Możesz zmienić go później i sprawić, by był super wspaniały i wydajny.

Tak, dobrą praktyką jest pisanie czystego kodu, ale nigdy nie kosztem dostarczenia. Korzyści z dostarczenia na czas produktu z taśmą przewyższają zalety czystego kodu, który nigdy nie został ukończony i dostarczony.

Dobry fragment kodu, z którym się spotkałem, nie jest czysty. Niektóre są wręcz brzydkie. Ale wszystkie zostały wydane i wykorzystane w produkcji. Niektórzy mogą powiedzieć, że pisanie niechlujnego kodu jest nieprofesjonalne. Nie zgadzam się. Profesjonalną rzeczą jest dostarczanie kodu, który działa, bez względu na to, czy jest czysty, czy bałagan. Deweloper musi zrobić co w jego mocy, biorąc pod uwagę czas przydzielony przed dostawą. Następnie wróć do sprzątania - to profesjonalne. Mamy nadzieję, że dostarczony kod nie jest czystą taśmą klejącą i jest „wystarczająco czysty”.

gąbki
źródło
45
Tak długo, jak dług techniczny ( en.wikipedia.org/wiki/Technical_debt ) nie doprowadzi Cię do „technicznego bankructwa” (niezdolności do dostarczenia nowych funkcji, naprawienia jednej części psuje drugiej itp.) Oraz pilnowania w tej sprawie zgadzam się.
Matthieu,
3
@HeathLilley wyraził zgodę. Po prostu nie wierzę, że programiści, którzy twierdzą, że należy pisać tylko czysty kod. To nieprawda. Zdarza się bałagan. Pomysł, że programiści powinni pisać czysty i poprawny kod od samego początku, jest iluzją. Promuję ideę, że zawsze ponownie odwiedzamy stronę i zmieniamy ją, gdy poprawimy nasze zrozumienie domeny.
gąbka
40
Problem z „po prostu wyślij kurwa teraz” polega na tym, że kierownictwo nie kupi później powodów do refaktoryzacji, ale jeśli zrobisz to niewidocznie TERAZ, wszystko będzie dobrze.
Job
5
Innym złudzeniem jest myślenie, że będziesz miał czas, aby wyczyścić go później. To się nie stanie. Będziesz miał inne rzeczy do wysłania. Nie powinieneś dostarczać niechlujnego kodu. Nawiasem mówiąc, powinieneś również pracować nad terminami, jesteś technikiem, który wie, ile czasu zajmie napisanie czystego kodu. Nie oznacza to nadmiernego sprzątania i majsterkowania przez szalony czas, to oznacza, że ​​należy wziąć pod uwagę czas na refaktoryzację przed wysłaniem kodu.
Steve Chamaillard
3
„Możesz to zmienić później” [potrzebne źródło]
Carl Leth
39

Musisz upewnić się, że Twój kod jest bardzo czytelny, czysty i łatwy w utrzymaniu. Właśnie to muszą zrobić wszyscy programiści .

Ale mówisz o over styling(jak ten termin lepiej niż kod-girl ), który służy wyłącznie ego jego autora.

W przeszłości widziałem wielu programistów, którzy byli tak dumni ze swojego dzieła (wiesz, jak w toaletach;)), spędzili godziny na czyszczeniu i dopracowywaniu kodu. Niektóre z nich były tak skrupulatne, że zapewniały przestrzeganie prawidłowych białych przestrzeni między członkami.

To za dużo.

Uważam, że takie zachowanie przynosi efekt przeciwny do zamierzonego. W kontekście zawodowym musisz być profesjonalistą . Możesz uzyskać satysfakcję, pisząc czysty, bardzo czytelny i łatwy do utrzymania kod oraz rozmawiając ze szczęśliwymi użytkownikami lub współpracownikami.

2567
źródło
13
Cóż, szlifuję, dopóki kod nie będzie przeze mnie czytelny. Jeśli wrócę dwa tygodnie później i muszę dowiedzieć się, co zrobiłem, prawdopodobnie nie jest to wystarczająco jasne, aby inni mogli to łatwo zrozumieć.
Robert Harvey
14
Elegancki kod jest z natury łatwiejszy w utrzymaniu i, jak sądzę, łatwiejszy do odczytania.
Craige
6
+1, widziałem kiedyś doskonale zaprojektowany KOD SPAGHETTI.
Jas
23
Zgadzam się z tym sentymentem, ale piszę mój kod z poprawną liczbą spacji między członkami i denerwują mnie ludzie, którzy tego nie robią. Jest to łatwe do zrobienia (jeszcze łatwiejsze dzięki zautomatyzowanym narzędziom takim jak StyleCop), a spójność, którą zapewnia, jest warta niewielkiego wysiłku.
Robert Harvey
3
@sunpech: Napisz to czyste, a dużo łatwiej jest utrzymać to w czystości.
David Thornley,
24

Nie zgadzam się z przyjętą odpowiedzią na to pytanie.

Twoim obowiązkiem jest oczywiście wysyłka, ale zwykle masz również obowiązek wysłać coś, co jest możliwe do utrzymania tak opłacalnie, jak to możliwe, przez ciebie i przyszłych programistów.

Spędziłem okresy jako kiepski programista lub konsultant ds. Konserwacji na miejscu, który musi zrozumieć i debugować ogromny, nieudokumentowany system, i mogę powiedzieć, że złe projekty i bałaganiarski kod mogą prowadzić do godzin, a nawet dni marnowania wysiłku. Mogę wymyślić wiele sytuacji, w których dodatkowe N godzin pracy początkowego programisty mogłoby doprowadzić do oszczędności kosztów w wysokości 5 N.

Wiem, że płynie wokół tego statystyka, ale z mojego doświadczenia w wielu projektach, każdy wiersz napisanego kodu jest odczytywany 5-20 razy podczas rozszerzenia i konserwacji.

Powiedziałbym więc, żeby wyczyścić kod w ciągu jednego cala jego życia . Zajmuje to trochę czasu, ale prawdopodobnie oznacza to oszczędność kosztów netto w trakcie trwania projektu.

Benjamin Wootton
źródło
2
Nie, czyścisz kod, gdy jest czas i budżet, A ryzyko takiego działania jest mniejsze niż ryzyko, że tego nie zrobisz. W środowiskach produkcyjnych oznacza to dość często, że nie będziesz dopracowywać istniejącego kodu, aby był ładniejszy, po prostu nie jest opłacalny, ale stwarza ryzyko wprowadzenia nowych błędów.
jwenting
Zależy to również od tego, w jakim zakątku tworzenia oprogramowania pracujesz. Pracowałem dla agencji marketingu cyfrowego, która z przyjemnością obciążyła swojego klienta opłatami, jeśli następna faza miałaby potrwać dłużej z powodu problemów z kodem bazowym. Nasze dążenie do dłuższego czasu pracy deweloperów w celu rozwiązania istniejących problemów zostało odrzucone na korzyść dłuższego czasu tworzenia, który równa się większej ilości pieniędzy dla firmy.
Simon Whitehead
1
Zgadzam się z tym, powinieneś dostarczyć kod, ale jeśli nie możesz naprawić / zaktualizować / uaktualnić, to nie dostarczyłeś kodu, ale dziurę pieniężną. Uważam, że ludzie, którzy walczą z tym pomysłem, są przyzwyczajeni do pracy w złym środowisku i argumentują system, którego nigdy nie doświadczyli. Utrzymałem zarówno czysty, jak i nieoczyszczony kod, i powiem ci, że czysty kod jest znacznie tańszy i szybszy w utrzymaniu i rozwijaniu.
Jdahern
21

Czy ktokolwiek z nas kupiłby samochód, gdybyśmy wiedzieli, że pod maską wszystko jest nieuporządkowane i trudne do rozwiązania, konserwacji lub naprawy, a uruchomienie zajmuje więcej zasobów niż powinno?

Dlaczego powinno być inaczej w przypadku oprogramowania?

To, że użytkownicy końcowi nie mogą patrzeć pod maską, nie oznacza, że ​​nigdy się tego nie dowiedzą. Wcześniej czy później pojawi się.

Odpowiadając na pytanie „Czy faktycznie piszesz„ czysty kod ”? -- O tak.!

Sifar
źródło
Nie zgodziłbym się - oprogramowanie nie rdzewieje (jak to ujmuje Joel), w przeciwieństwie do wnętrza samochodu. Możesz argumentować, że po uaktualnieniu systemu operacyjnego oprogramowanie również musi zostać zaktualizowane, ale to coś innego. Piszę też czysty kod, ale nie sądzę, że jest to najważniejsza cecha mojego wkładu.
K.Steff
18

Jeśli przez „czysty kod” rozumiesz, czy robię wszystko, co w mojej mocy, aby upewnić się, że kod jest tak jasny, jak to możliwe?

Pewnie, ze tak.

Im czystszy, wyraźniejszy kod, tym łatwiej go utrzymać, a tym samym oszczędza czas na dłuższą metę. Nie traktuj czystego kodu jako próżności; traktuj to jako inwestycję w oszczędzanie przyszłego wysiłku i czasu.

GrandmasterB
źródło
15

Szczerze mówiąc to zależy. Podoba mi się, jak wszyscy wypowiadają się na temat partii o tym, że „cokolwiek mniej niż czysty, dobrze udokumentowany kod jest czystą parodią!”, Ale pracuję w firmie z absurdalnymi cyklami wdrażania i zerowym nadzorem: robię co mogę, ale piszę tak dużo kodu jest niezwykle trudne do napisania czystego idealnego kodu, który wszyscy twierdzą, że piszą.

Staram się pisać kod, który może z łatwością obsługiwać ktoś, kto ma z grubsza moje umiejętności. Komentuję trudne części, nazywam przyjazne nazwy programów, zmiennych i klas, wdrażam i kontynuuję. Nie mam czasu na nic innego.

Czasami czuję się trochę winny, ale niezbyt. Powinieneś zobaczyć niektóre z okropności, z którymi mam do czynienia na co dzień. Dekady niestandardowego kodu w nieznanych językach bez zerowej dokumentacji. Jeden z moich współpracowników rozwija się wyłącznie w języku Visual Basic 6.0 i wdraża w każdym miejscu pliki binarne o kryptografii. Kobieta, którą zastąpiłem, zaprogramowana wyłącznie w RPG .

Po prostu niezwykle trudno mi uwierzyć, tak okropne bzdury, jakie widziałem w życiu jako programista, że wszyscy generują czysty kod.

Satanicpuppy
źródło
Zgoda. Większość ludzi nie zamierza napisać czystego kodu, aby wysłać / wydać po raz pierwszy. Do wykonania zadania wymagana jest taśma klejąca.
gąbka
2
Wystarczy z taśmą klejącą! Spolsky nie jest bogiem. Kładzie spodnie na jednej nodze, tak jak my!
Job
5
Jednym z powodów, dla których piszesz czysty kod, jest to, że szybciej jest pisać czysty kod niż brudny kod na dowolnym, ale najkrótszym czasie (powiedzmy kilka godzin). Jeśli myślenie przez kilka sekund o nazwach zmiennych i metod spowoduje, że spóźnisz się z terminem, to również cenny czas, który tracisz, gdy ty i / lub twoi współpracownicy wprawicie się w zakłopotanie. Sprawiasz, że kod wydaje się prawie jednorazowy, tak jak go napiszesz, będzie używany przez pewien czas bez konserwacji, a następnie wycofany. Może w twojej szczególnej sytuacji kod jest jednorazowy. Nigdy nie widziałem, żeby tak się działo w ciągu dekady praktycznych doświadczeń.
PeterAllenWebb
1
@peter: Przez dwie dekady nigdy nie widziałem miejsca, w którym każdy fragment kodu byłby czysty. Rzadko widziałem nawet miejsce, w którym była połowa . Gdzie pracujesz? NASA?
Satanicpuppy
2
@Satanicpuppy W swoim czasie widziałem wiele brudnego kodu i napisałem swoją część, ale prawie wszystko to marnowało mój czas lub cudzy. Zgadzam się z twierdzeniem, że czysty kod może być napisany SZYBCIEJ niż brudny kod w dowolnej skali czasowej dłuższej niż kilka godzin.
PeterAllenWebb
7

Nie sądzę, że podoba mi się termin „kod dziewczyny”, ale czysty kod = kod, który można utrzymać. Coś mniej jest nieprofesjonalne.

Zasadniczo uważam, że następny programista musi spojrzeć na mój bałagan.

Dużo czasu to ja ... kilka miesięcy później ... kiedy nie pamiętam, jak to działa ... i mam jeszcze mniej czasu na zmianę.

Heath Lilley
źródło
5

Staram się pisać „czysty kod” w sensie Boba Martina (np. Projekt OO). Pisanie czystego kodu ma wielką wartość. Jest o wiele łatwiejszy w utrzymaniu.

Potem pozwalam ReSharperowi zrobić dla mnie „ładny kod” (np. Wyrównanie, łamanie linii itp.). Pisanie ładnego kodu ma dobrą wartość. Ale maleją zyski. Niektóre ustawienia wstępne sprawiają, że jest to łatwiejsze w utrzymaniu ze względu na łatwość czytania.

Jeśli uważasz, że konieczne jest uporządkowanie olbrzymich bloków kodu, aby było czytelne, to problem polega na tym, że jesteś cholernym ogromnym blokiem kodu! Jest za duze. Widzę wiele przykładów ludzi, którzy zadają sobie wiele trudu, aby utrwalić bardzo źle zaprojektowany kod.

Gdybym nie miał ReSharpera, nadal miałbym czysty kod, ale nie byłby tak ładny.

Nie sądzę, że powinienem spędzać więcej niż ~ 5% mojego czasu na kodowaniu w upiększaniu. Co oznacza, że ​​im potężniejszy jest mój edytor i im bardziej jestem biegły w tym, tym więcej mogę upiększyć.

dss539
źródło
4

Wydaje się, że nikt nie podnosi znaczenia tego, co leży w najlepszym interesie Twojej firmy?

Często, jeśli nie zawsze, programiści są tylko pracownikami i chociaż decyzje kierownictwa mogą nas sfrustrować, często nie mamy wszystkich danych, które robią.

Na przykład powiedzmy, że firma jest objęta klauzulą, że jeśli oprogramowanie nie jest gotowe na czas, nie dostaniesz zapłaty (to się właśnie stało, choć wydaje mi się, że w końcu dostaliśmy płatność). Tak, czysty kod jest ważny, ale ważniejsze jest, aby kod działał do dnia płatności!

Kolejny przykład - firma ma złą sytuację finansową i musi zebrać trochę pieniędzy. Zgadnij, kto dba o jakość? Możesz to naprawić później, jeśli musisz, po prostu go wyślij!

Argumentem może być „Dlaczego mam się sprzedawać i pisać kiepski kod?”. Dlaczego twoja firma powinna płacić niezły czek co miesiąc? Wybory, przyjacielu. Jeśli szukasz idealizmu, wypróbuj Free Software Foundation ; Słyszałem, że robią całkiem fajne rzeczy (mam na myśli to i szanuję FSF i OSS).

Z drugiej strony, jeśli pracujesz nad projektem, w którym spodziewany jest gwałtowny wzrost wykorzystania (chociaż takie prognozy prawie nigdy nie są dokładne), lepiej położyć solidne podstawy z najlepszą wymaganą jakością kodu, ponieważ jest to prawie pewne utrzymanie być większym kosztem dla projektu.

Programiści uwielbiają „czysty” kod, cokolwiek to znaczy. Nie możemy nawet ustalić, co jest czyste, ale uwielbiamy to. Czasami jednak nie ma to tak wielkiego znaczenia, jak użyteczność i poprawność. Mogą się wydawać synonimami, ale tak nie jest - jeśli zobaczysz kod napisany przez prawdziwego hakera Perla w ciągu 4 godzin z zamiarem użycia go dwukrotnie i wyrzucenia, przyznasz, że nie jest czysty, ale działa.

Czasami więc ego na bok powinniśmy po prostu sprawić, by działało. Zauważ, że nie polecam pisania złego kodu jako nawyku; Po prostu wskazuję, że może to być konieczne. Doskonałość wymaga czasu, którego Twoja firma może nie mieć. Więc jeśli twój pracodawca nie ma nic przeciwko, stwórz oprogramowanie, ale jeśli potrzebujesz, po prostu napisz działający kod, nie wspominając o „czystości”. To po prostu nie jest odpowiedź „jeden rozmiar dla wszystkich” - należy nadać priorytet.

K.Steff
źródło
3

Nie jestem pewien, czy „dobrze wygląda”, a bycie „eleganckim, doskonale zrozumiałym i łatwym w utrzymaniu” jest równoważne.

Staram się pisać kod, który jest „elegancki, doskonale zrozumiały i łatwy w utrzymaniu”. Dokonuję refaktoryzacji własnego kodu, aby lepiej pasował do tych kryteriów.

Nie widzę żadnych wad, z wyjątkiem wynikającego z tego kosztu w czasie.

Aby kod „wyglądał dobrze”, istnieje wiele zautomatyzowanych narzędzi, które odpowiednio wcięcia i rozmieszczenie wszystkiego, jak chcesz.

back2dos
źródło
2
To mnie denerwuje jeszcze bardziej, gdy widzę źle sformatowany kod. Osoba, która to pisze, mogła po prostu użyć jednego z tych narzędzi, aby zrobić to za nich. Występuje również najczęściej podczas mieszania tabulatorów i spacji, aby stworzyć nieświęty bałagan.
jsternberg,
3

Zbyt wiele rzeczy nigdy nie jest dobre.

Jednak ważną rzeczą, o której należy pamiętać w przypadku „nieczystego” kodu, jest to, że może on łatwo doprowadzić do „ rozbicia okna ”. Jeśli kod jest bardzo źle sformatowany, myślę, że wiele osób początkujących w bazie kodu może czuć się mniej skłonnych do wykonania dobrej pracy z utrzymaniem i ewolucją powodującą spiralę spadkową, która ostatecznie może wpłynąć na warunki pracy oprogramowania.

Dlatego utrzymanie określonego poziomu czystości w kodzie jest korzystne nie tylko dla innych programistów. Nie poświęcaj na to zbyt wiele czasu (wspomniano o ~ 5%). Naucz się korzystać z narzędzi swojego rzemiosła do automatyzacji zadań ręcznych (w tym przypadku formatowania kodu). Weź na siebie odpowiedzialność za to, co robisz i zawsze rób to, co uważasz za najbardziej korzystne dla Twojej firmy / klientów / użytkowników.

Per Noalt
źródło
3

Oto cytat z Clean Code autorstwa Boba Martina:

Aby odwieźć ten punkt do domu, co byś zrobił, gdybyś był lekarzem i miał pacjenta, który zażądał, abyś przerwał wszystkie głupie mycie rąk w ramach przygotowań do operacji, ponieważ zajęło to zbyt wiele czasu? Najwyraźniej pacjent jest szefem; a jednak lekarz powinien absolutnie odmówić przestrzegania. Dlaczego? Ponieważ lekarz wie więcej niż pacjent o ryzyku choroby i infekcji. Przestrzeganie przez pacjenta zaleceń lekarza byłoby nieprofesjonalne (nie wspominając o przestępczości).

Także nieprofesjonalne jest, aby programiści zginali się do woli menedżerów, którzy nie rozumieją ryzyka związanego z robieniem bałaganu.

Tulains Córdova
źródło
2

Myślę, że „czysty kod” powinien być tak czysty lub czystszy, jak pisałeś na egzaminach z fizyki / inżynierii / matematyki. Jeśli jest zbyt brudny, równiarka nie zrozumie twojej pracy i prawdopodobnie oznaczy ją źle, nawet jeśli jest poprawna.

chiurox
źródło
2

Lubię kod, aby był czytelny, ale najważniejsza jest spójność. Dla mnie oznacza to zgodność z konwencjami nazewnictwa i odstępami między funkcjami, nawiasami w tym samym wierszu lub następnym wierszu instrukcji if itp.

Oczywiście zdarza się, że ktoś programuje coś ze spójnym stylem kodu, co wciąż doprowadza mnie do szaleństwa. Zwłaszcza kod, który nie „oddycha”. Na przykład:

void function1(){
    //whatever code
}
int fooBar(){
    //whatever else
}
Foo* someOtherFooBar(int value){
    if(value){
        //do something
    }
    return ...;
}

Cóż ... Wygląda gorzej z metodami Objective-C, z mnóstwem zagnieżdżonych instrukcji if i linii znacznie dłuższych niż 80 znaków. Ale wciąż mnie to denerwuje :)

żarliwość
źródło
2

Robię wszystko, aby wyczyścić kod. Myślę, że to bardzo pomaga wyróżnić błędy.

Nie zgadzam się z koncepcją „dostarcz kurwa teraz”, ponieważ czysty kod to inwestycja w przyszłość. Dostarczane jest także zbyt wiele programów zawierających zbyt wiele błędów. Rozwiązanie jednego błędu jest moim zdaniem lepsze niż wdrożenie jednej nowej funkcji.

Również jeśli spojrzysz na szacunki wydajności programisty , nie sądzę, żebym uzyskał bardzo złe wyniki. Pisanie czystego kodu jest nawykiem, a im więcej doświadczenia jako programista, tym bardziej efektywny staje się. Oczywiście, jeśli ktoś nigdy tego nie spróbuje, nigdy nie uzyska doświadczenia.

Inną kwestią, którą należy wziąć pod uwagę, jest to, że większość czasu programisty przeznaczana jest na czytanie kodu, więc czytelny kod znacznie skraca czas spędzany na czytaniu. Zrozumienie nieudokumentowanych algorytmów może być na przykład kosztowne i powodować nowe błędy.

Jedną rzeczą, za którą zdecydowanie tęsknię i chciałbym mieć jeden dzień, jest automatyczny formatator kodu, który mógłbym dostosować do mojego stylu, co naprawdę zaoszczędziłoby mi trochę czasu, szczególnie podczas czytania kodu innych osób.

Czyste kodowanie ma związek z perfekcjonizmem, który niesie ze sobą ryzyko, że nigdy się nie zmaterializuje, ale myślę, że jest to głównie problem, kiedy zaczynasz, ponieważ inwestujesz w później i ponownie wykorzystujesz własne eleganckie fragmenty kodu, w połączeniu z twoim doświadczeniem , z wiekiem będziesz bardzo produktywny i o wiele mniej nawiedzany przez błędy niż niechlujny programista.

To jest fragment kodu demonstrujący mój styl kodowania.

20416
źródło
1

Po prostu unikaj „kodu próżności”. Istnieje wielu programistów, którzy robią rzeczy wyłącznie z próżności (lub z powodu OCD) i nic więcej. Moje majtki naprawdę przekręcają się z tymi ludźmi.

ElGringoGrande
źródło
Powiedzmy, że lubią komentarze w skrzydle lub (gorzej) polu?
David Thornley,
1

Piszę kod, który próbuje rozwiązać dany problem w najbardziej wydajny i teoretycznie „elegancki” sposób. W tym sensie tylko to jest czyste. Jeśli zdarzy się, że jest „ładna”, kiedy skończę, niech tak będzie.

W moich ograniczonych doświadczeniach odkryłem, że kiedy ludzie narzekają na „czysty kod”, brzydota jest zwykle wynikiem okropnego rozwiązania, a nie konwencji kodowania.

Kurtis
źródło
1

Powiedziałbym, że staram się pisać czystszy kod, ale to może się zmienić z powodu ograniczeń czasowych lub jeśli pracuję nad czymś trudnym. Zwykle robi się bałagan, gdy skupia się na tym, aby działało. Potem wrócę i posprzątam, kiedy to sprawdzę. Jeśli wrócisz do kodu i musisz poświęcić zbyt dużo czasu na odświeżenie pamięci, nie skomentowałeś go wystarczająco.

Czysty kod jest dobry, ale podobnie jak wszystko inne, musi być wystarczająco czysty. Wcięcie 5 linii kodu 4 spacji i jednej linii 5 spacji nie zwiększa trudności z czytaniem.

JeffO
źródło
1

Myślę, że to zależy od tego, co robisz. Jeśli piszę aplikację potwierdzającą koncepcję, to po prostu koduję w dupę i nie oglądam się za siebie. Jeśli pracuję nad aplikacją, nad którą będę pracował przez jakiś czas, to upewniam się, że koduję ją wystarczająco dobrze, a także zapewniam zrozumiałość za miesiąc.

Myślę, że stylowanie twojego kodu jest nieco niepewne. Jak powiedzieli niektórzy powyżej, Twoim zadaniem jest stworzenie produktu, a nie sformatowanego kodu, ale powiedziałbym, że przynajmniej należy trzymać się określonego stylu komentowania i kodowania. Nie chciałbym widzieć połowy zmiennych wielbłąda i drugiej połowy Węgier.

Ale zależy to również od tego, co rozumiesz przez „czysty kod”.

użytkownik7007
źródło
0

Przyznaję się do tego; a korzyść nie denerwuje się za każdym razem, gdy ją widzę. Sądzę, że jest to również łatwiejsze do odczytania, a zatem błędy stają się bardziej oczywiste; ale prawdziwy powód jest taki, że nie znoszę brzydkiego kodu.

użytkownik 281377
źródło
0

Refaktoryzacja kodu w celu uczynienia go eleganckim ułatwia czytanie i utrzymanie. Nawet drobne rzeczy, takie jak wyrównanie przypisań zmiennych:

int foo    = 1;
int bar    = 2;
int foobar = 3;

jest łatwiejszy do odczytania niż

int foo = 1;
int bar = 2;
int foobar = 3;

co oznacza, że ​​łatwiej jest przejrzeć, gdy debugujesz później.

Ponadto w PHP możesz dowolną liczbę losowych bloków kodu. Używam ich do grupowania logicznych zadań:

// do x
{
    // ...
}

// do y
{
    // ...
}

To dodaje jasną definicję odpowiedniego kodu.

Edycja : Jako dodatkowy bonus łatwo jest wyprzedzić jeden z tych logicznych bloków kodu, if (false)jeśli chcesz go tymczasowo pominąć.

Craige
źródło
11
Myślę, że już wymyślili coś, co to robi - nazywa się to funkcją. Za każdym razem, gdy tworzysz jeden z tych bloków, powinieneś zamiast tego utworzyć funkcję. Stamtąd, jeśli nie chcesz go uruchomić, skomentuj wywołanie funkcji (zamiast wstawiania komentarza
zwrotnego
1
@ stargazer712: Nienawidzę funkcji php z powodu braku zdefiniowanych przestrzeni nazw. Nieuchronnie, czytając czyjś kod, na górze ma jeden „włącz”, który sam zawiera 5 innych rzeczy, z których każda zawiera jeszcze 4, a następnie muszę przeszukać całą bazę kodu, aby znaleźć definicję funkcji. Bardzo frustrujące.
Satanicpuppy
Często jest to kod, który nie gwarantuje deklaracji funkcji. na przykład. brak możliwości ponownego użycia, obliczenia / ustawienia powiązanych zmiennych o zasięgu lokalnym itp.
Craige
z drugiej strony kod bez możliwości ponownego użycia jest rzadki. Jeśli napotkasz dużo kodu, którego nie można ponownie użyć, istnieje duża szansa, że ​​można go poprawić ... znacznie.
riwalk
-2

Po prostu piszę mój kod, zgodnie ze standardami firmy. Jeśli chcę to „upiększać”, mogę uruchomić go za pomocą upiększacza kodu.

Muad'Dib
źródło
2
Z wyjątkiem tego, co zwykle się dzieje, ktoś inny uruchamia go przez urządzenie upiększające, próbując wyczyścić to, czego nie dostałeś do czyszczenia.
riwalk
@ Stargazer712 i właśnie dlatego nie zawracam sobie głowy przekraczaniem standardów firmy
Muad'Dib,
@ Maud'Dib, problem polega na tym, że wynik jest tak dobry jak upiększacz. Podczas gdy poziome białe znaki dotyczą wyłącznie zakresu (a zatem czyści bardzo dobrze), pionowe białe znaki zwykle dotyczą intencji (grupowanie powiązanych elementów) i czyści bardzo słabo. Konkluzja - zmiłuj się nad innymi programistami.
riwalk
@ Stargazer712 Problem polega na tym, że z wyjątkiem „standardów firmy” wszystko inne jest całkowicie kwestią gustu, który jest subiektywny. na przykład lubię umieszczać miejsca w miejscach, w których mój współpracownik pozytywnie ich nienawidzi. Sprawiam, że wygląda mi to ładnie i to tak daleko, jak się posuwam.
Muad'Dib,
1
Bądź ostrożny z „upiększaczami”, ponieważ mogą zepsuć scalanie zatwierdzeń przez długi czas (mam doświadczenie z pierwszej ręki :)).
Juha Untinen,