Czy powinieneś poświęcić czytelność kodu z jego wydajnością? [Zamknięte]

Czy powinieneś poświęcić czytelność kodu z jego wydajnością?

np. 3 linie kodu w 1 linii.

W Code Craft autorstwa Pete'a Goodliffe'a przeczytałem, że kluczem jest czytelność.

Twoje myśli?

„Mniej linii” nie zawsze jest tym samym, co „bardziej wydajny”. Zakładam, że masz na myśli „Skrócenie programu kosztem czytelności”.

Programy muszą być napisane, aby ludzie mogli je czytać, a tylko przypadkowo, aby maszyny mogły je uruchomić.

-Abelson i Sussman, Struktura i interpretacja programów komputerowych

Ogólnie myślę, że ważniejsze jest, aby program był łatwiejszy do zrozumienia niż krótki. Powinienem jednak zauważyć, że skrócenie programu często sprawia, że ​​jest on bardziej czytelny (istnieje oczywisty próg, który osiągasz, gdy kod zaczyna wyglądać jak szum linii, ale do tego momentu wyrażanie czegoś bardziej zwięźle wydaje się bardziej zrozumiałe).

Istnieją szczególne wyjątki (takie jak osobiste skrypty powłoki lub jeden z kodów munging danych), których nikt nigdy nie będzie musiał utrzymywać i tylko Ty będziesz musiał przeczytać. W tej sytuacji prawdopodobnie można poświęcić trochę czytelności dla wygody, o ile nadal można to zrozumieć.

Czasem tak.

Należy dążyć do czytelności. Większość kodu napisanego dla typowych aplikacji biznesowych będzie wystarczająco wydajna i ważne jest skupienie się na czytelności. W obszarach wymagających większej wydajności (takich jak programowanie gier wideo lub ciężkie obliczenia) może być ważne, aby zrezygnować z czytelności na rzecz korzystania z określonej funkcji języka, która jest strasznie nieczytelna, a jednocześnie niezwykle wydajna.

Przykład tego ostatniego znajduje się w artykule Fast Inverse Square Root na Wikipedii.

Ogólnie myślę, że lepiej jest najpierw zrobić coś czytelnego, a potem martwić się o wydajność, pod warunkiem, że zostaną podjęte rozsądne środki ostrożności, takie jak nie wybieranie algorytmu O (n ^ 2) zamiast O (n). W mojej opinii poświęcanie czytelności dla samej zwięzłości jest błędne.

Jedyny raz, kiedy poświęcę czytelność, to wtedy, gdy kod zostanie pokazany jako wąskie gardło wydajności, a przepisanie go naprawi. W takim przypadku intencja kodu powinna być dobrze udokumentowana, aby w przypadku błędu można go łatwiej wyśledzić.

To nie znaczy, że przepisywanie musi być oczywiście nieczytelne.

I zacytował go przed , a ja go zacytować ponownie:

Popraw
to,
wyjaśnij, zwięźle,
szybko.

W tej kolejności.

Wes Dyer

Czy powinieneś poświęcić czytelność kodu z jego wydajnością?

Pod względem kodu zawsze miło jest samokontraktować. Ale czasami to się nie zdarza. Czasami trzeba zoptymalizować, a czasem ten kod sam w sobie nie jest bardzo czytelny.

Do tego właśnie wymyślono komentarze . Użyj ich. Nawet zgromadzenie ma komentarze. Jeśli napisałeś masę kodu i nie widać komentarza, martwię się. Komentarze nie wpływają na wydajność w czasie wykonywania, ale kilka uwag na temat tego, co się dzieje, zawsze pomaga.

Moim zdaniem nie ma absolutnie żadnej wymówki, aby nie mieć kilku podstawowych komentarzy. Najwyraźniej if ( x == 0 ) /* check if x is 0 */jest całkowicie bezużyteczny; nie powinieneś dodawać niepotrzebnego szumu do kodu, ale coś takiego:

; this is a fast implementation of gcd
; in C, call as int gcd(int a, int b)
; args go in rdi, rsi, rcx, r8, r9
gcd:
    push rdp
    ; ...

Jest bardzo pomocny.

Czy powinieneś poświęcić czytelność kodu z jego wydajnością?

Jeśli Twoim głównym celem jest wydajność (jak na etapie optymalizacji) i wiesz - masz wskaźniki, prawda? - ta linia (linie) kodu jest bieżącym wąskim gardłem, a następnie tak.

W przeciwnym razie no: czytelność pozwoli ci (lub innemu) na zmianę tego kodu w celu zwiększenia jego wydajności, ponieważ jest łatwiejszy do zrozumienia.

Nikt nie wygrywa Code Golf

np. 3 linie kodu w 1 linii

Szczególnie okropny pomysł.

Koszt gry w golfa kodowego - bardzo wysoki.

Koszt utrzymania nieczytelnych programów - astronomiczny.

Wartość tego rodzaju zminimalizowanego kodu - zero. Nadal działa, ale nie działa „lepiej”.

Mądrze wybrana wydajność

Koszt wyboru właściwego algorytmu i struktury danych - umiarkowany.

Koszt utrzymania właściwego algorytmu i struktury danych - niski.

Wartość właściwego algorytmu i struktury danych - wysoka. Zużycie zasobów jest niskie.

Głupia („mikrooptymalizacja”) Wydajność

Koszt zabawy wokół mikrooptymalizacji - wysoki.

Koszt utrzymania nieczytelnego, mikrooptymalizowanego kodu - bardzo wysoki.

Wartość mikrooptymalizacji - jest różna. Gdy jest tu wartość niezerowa, koszty wciąż ją przewyższają.

Zależy od tego, czy mówimy o wydajności pod względem szybkości wykonania kodu, czy o wydajności, z jaką programista może napisać kod. Jeśli poświęcasz czytelność kodu na rzecz szybkiego pisania kodu, prawdopodobnie będziesz musiał poświęcić czas na debugowanie.

Jeśli jednak mówimy o poświęceniu czytelności kodu pod względem szybkości działania kodu, prawdopodobnie jest to akceptowalny kompromis, o ile kod musi wykonać się skutecznie. Pisanie czegoś, co działa tak szybko, jak to możliwe tylko dlatego, że nie jest to tak dobry powód, jak to, że jest to coś w rodzaju szybkiego odwrotnego pierwiastka kwadratowego, w którym kluczowa jest wydajność. Sztuczka polega na zrównoważeniu kodu i upewnieniu się, że nawet jeśli źródło może być trudne do odczytania, komentarze opisujące to, co się dzieje, wyjaśniają, co się dzieje.

Wiele sztuczek, które miały sprawić, że kod jest szybszy, ale zwykle sprawiają, że kod jest mniej czytelny, nie są już konieczne, ponieważ albo kompilatory stały się bardzo sprytne (nawet sprytniejsze niż większość programistów), albo maszyny stały się absurdalnie szybkie.

Nie akceptuję argumentu „czytelność ponad wydajność”. Pozwól, że dam ci odpowiedź z innym obrotem.

Trochę tła: wiesz, co mnie rozchorowało? Kiedy dwukrotnie klikam Mój komputer i muszę czekać, aż się zapełni. Jeśli to potrwa dłużej niż 5 sekund, jestem naprawdę sfrustrowany. Głupie jest to, i nie obwiniaj za to Microsoft, że w niektórych przypadkach powodem tak długiego czasu jest decyzja o tym, jaką ikonę pokazać! Zgadza się. Więc tutaj siedzę, zainteresowany tylko przejściem na mój dysk C: i muszę poczekać, aż sterownik uzyska dostęp do mojej płyty CD-ROM i odczytać stamtąd ikonę (zakładając, że w napędzie znajduje się płyta CD).

DOBRZE. Wyobraźmy sobie przez chwilę, że wszystkie warstwy między mną klikają dwukrotnie Mój komputer i rozmawiają przez sterowniki na CD-ROM. Teraz wyobraź sobie, że każda warstwa była ... szybsza ...

Widzisz, za tym wszystkim stoi tysiące szczęśliwych programistów, ponieważ ich kod jest „bardziej czytelny”. To wspaniale. Cieszę się z ciebie Ale z punktu widzenia użytkownika jest do bani (termin techniczny). I tak śpisz w nocy, mówiąc sobie, że zrobiłeś dobrą rzecz, upewniając się, że kod jest bardziej czytelny, a jednocześnie wolniejszy. Nawet nieco wolniej niż może być. I tak robi to tysiące programistów, a my czekamy na nasze komputery z twojego powodu. Moim zdaniem nie jesteś godny. Nie twierdzę, że twoje pierwsze wiersze muszą być najlepsze.

Oto moje podejście: po pierwsze, spraw, aby działało, a następnie przyspiesz. Zawsze staraj się pisać efektywny kod, a jeśli musisz poświęcić czytelność, uzupełnij go komentarzami. Nie poświęcę wydajności, aby jakiś mierny programista mógł ją utrzymać. Wyjaśnię jednak mój kod, ale jeśli to nie wystarczy, przepraszam, jesteś po prostu niezdolny do pracy tutaj. Ponieważ tutaj piszemy kod, który jest szybki i czytelny, i chociaż istnieje równowaga, czytelny kod można wyjaśnić, podczas gdy nieefektywność jest po prostu niedopuszczalna.

To pytanie często przychodziło mi do głowy, gdy w biurze omawia się wywiady. Wiele lat temu, jako absolwent, zadano mi pytanie „Czy uważasz, że kod sam się dokumentuje?”. Miałem teraz odpowiedzieć na to pytanie jako programista, a jeśli chodzi o ankietera, było to pytanie czarno-białe, więc nie było żadnych podstaw. Proces powinien przeżyć to, co indywidualne, ponieważ ludzie będą bardziej niż żywi przychodzić i odchodzić, a Ty chcesz jak najszybciej przygotować nowe starty, a im łatwiejszy do odczytania kod, tym szybciej zrozumiesz, co się dzieje.

Niedawno przeczytałem książkę, która była całkiem niezła, zatytułowana Rozwój oparty na domenach: Projektowanie oparte na domenach: rozwiązywanie złożoności w sercu oprogramowania Wprawdzie na początku jest to trochę sucha lektura, ale materiał jest dobrze zaprezentowany. To pokazuje dobre podejście, które prowadzi do systemów, które dobrze się dokumentują. Język jest medium do komunikowania się z twoim rozwiązaniem, więc im wyraźniejsze jest to rozwiązanie, tym łatwiej jest je dostosować, jeśli wydajność staje się czynnikiem cytycznym. Takie jest moje przekonanie i wydaje się, że zadziałało dla mnie dobrze.

W rzadkich przypadkach warto było ROI przyspieszyć działanie kodu kosztem czytelności. Nowoczesne komputery działają tak szybko, że wątpię, by istniał scenariusz, w którym byś tego chciał. Jeśli kod działa na komputerze, kod ten należy zachować.

W tym celu uważam, że czytelność jest bardzo ważna. Oczywiście, jak stwierdzono wiele razy, tylko dlatego, że kod jest czytelny, nie musi oznaczać, że jest wolniejszy.

Dobrym przykładem jest nazwa zmiennej: $a

Co to jest $a?? To jest poza kontekstem, więc nie możesz na to odpowiedzieć, ale czy kiedykolwiek natrafiłeś na to w prawdziwym kodzie? Załóżmy teraz, że ktoś napisał $file_handle- co to takiego? Jest jasne, nawet poza kontekstem. Długość nazwy zmiennej stanowi nieznaczną różnicę dla komputera.

Myślę, że należy tu zachować zdrowy rozsądek.

Niektóre aplikacje mogą wymagać skrótu bitowego, którego nie wszyscy zrozumieją, ale myślę, że w pewnym momencie dochody są mniejsze, a znalezienie scenariusza jest rzadkie *.

* to zależy od branży i innych podobnych rzeczy. Patrzę na to z perspektywy twórcy oprogramowania biznesowego (Business Information Systems).

Aby spojrzeć na to z jeszcze innej perspektywy (ale nie po to, by wędrować), pracuję w firmie zajmującej się SAAS. Gdy strona się psuje, musimy ją naprawić naprawdę, naprawdę szybko - zwykle ktoś inny naprawia kod innego programisty.

Chciałbym dużo raczej ktoś czegoś bardzo nieefektywnie ale czytelny niż Niech będzie wyszukane i „szybko”. Nasze serwery sieciowe są najnowocześniejsze i żądanie nie musi być dostarczone w milionowych częściach sekundy. Nie mamy problemów z ładowaniem.

Tak więc w praktyce myślę, że jesteś bardziej skłonny do zranienia siebie lub innych ... (Wolę odzyskać weekend).

W większości przypadków odpowiedź brzmi „Ufaj swojemu kompilatorowi, że wykona swoją pracę” i napisz czytelny kod. Oznacza to, że kod jest logicznie skonstruowany (tj. Bez spaghetti) i samodokumentujący (tj. Wystarczająco jasne nazwy zmiennych, funkcji itp.). Uzupełnij kod, który nie jest dokumentowany sam przez siebie znaczącymi komentarzami. Nie komentuj ze względu na komentowanie, tj.

x++; // Add one to x

Komentuj raczej dla ciebie, czytelnika, w ciągu 6 miesięcy lub 12 miesięcy lub w innym wystarczająco długim czasie. Przyjmij standard kodowania i postępuj zgodnie z nim.

Czysty kod to szybki kod. Wyraźnie napisany, łatwy w utrzymaniu kod wydaje się być szybszy, ponieważ jest wskaźnikiem, że programista zrozumiał dane zadanie i przekształcił kod do jego podstawowego celu.

Poza tym nowoczesne kompilatory bardzo skutecznie optymalizują instrukcje. Ile linii kodu wpisujesz, aby coś zrobić, i to, co kompilator tworzy pod względem instrukcji, niekoniecznie jest powiązane. Przeczytaj o kompilatorach, aby zrozumieć, dlaczego tak jest.

Kiedy pracuję nad czymś opartym na wydajności, takim jak grafika, czasami poświęcam czytelność / łatwość konserwacji, gdy robię takie rzeczy, jak przetwarzanie obrazu, gdy pracuję na najgłębszych z zagnieżdżonych algorytmów, w których małe optymalizacje mogą mieć duży wpływ. I nawet wtedy robię to dopiero po profilowaniu, aby zmiany rzeczywiście przyspieszyły. Nie mogę powiedzieć, ile razy próbowałem „ręcznie zoptymalizować” optymalizacje, ale okazało się, że faktycznie spowolniło aplikację ze względu na sposób, w jaki kompilator zoptymalizował ręcznie wpisany kod.

Czytelność jest usprawiedliwieniem dla niekompetentnych i leniwych programistów (w rzeczywistości to samo dotyczy „prostoty”, gdy jest używana jako argument w obronie głupiego algorytmu / projektu)!

Do każdego problemu powinieneś dążyć do optymalnego rozwiązania! Fakt, że obecnie komputery są szybkie, nie usprawiedliwia marnowania cykli procesora. Jedynym ograniczeniem powinien być „czas dostarczenia”. Zauważ, że „optymalne rozwiązanie” oznacza tutaj to, co TY możesz wymyślić (nie wszyscy możemy wymyślić najlepsze rozwiązanie; lub mieć umiejętności / wiedzę do ich wdrożenia).

Jak ktoś wspomniał, jeśli istnieją „trudne do zrozumienia” aspekty rozwiązania, właśnie po to są komentarze. Kolejność „poprawna, czytelna, szybka” (lub coś w tym rodzaju), o której ktoś wspomniał, to tylko strata czasu.

Naprawdę ciężko mi uwierzyć, że są tam programiści, którzy, gdy przedstawią im problem, myślą w linijce: „… trzeba to zrobić w ten sposób, ale zrobię to w taki sposób, aby był mniej wydajny, ale bardziej czytelny / łatwe w utrzymaniu i inne takie badziewie ... ”. Błędem tego jest to, że następny programista (widząc nieefektywności) najprawdopodobniej zmodyfikuje kod, a następny zrobi to samo i tak dalej ... W efekcie po kilku wersjach kod stanie się tym, co oryginał programista powinien napisać na pierwszym miejscu. Jedynym usprawiedliwieniem dla oryginalnego programisty jest. on / ona nie pomyślał o tym (wystarczająco uczciwie) i (jak wspomniano wcześniej) b. ograniczenia czasu i zasobów.

jeśli zmniejszenie czytelności pomaga w wydajności / optymalizacji kodu (jak w bibliotekach swfobject i innych bibliotekach js), to jest powód, aby nadal pisać dobrze sformatowany i czytelny kod i przekonwertować go na nieczytelny / zoptymalizowany jako część procesu „kompilacji” / wydania.