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

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?

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

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.

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.

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

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.

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.

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

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

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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

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.

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

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