Czy prostota zawsze poprawia czytelność?
Powiedziałbym, może z odrobiną kontrowersji, absolutnie nie .
Możesz podać mi klasę z 200 funkcjami członka w interfejsie publicznym i może to być najbardziej czytelny dla ludzi interfejs publiczny. Może to być radość po prostu swobodnie czytając taki kod i jego dokumentację. Nie nazwałbym tego jednak „prostym”, ponieważ pomimo czytelności musiałbym się martwić, w jaki sposób wszystkie te funkcje współdziałają ze sobą, i potencjalnie uważać na skomplikowane przypadki krawędzi wynikające z niewłaściwego użycia.
Wolałbym klasę z 20 funkcjami składowymi, które nie były tak łatwe do odczytania, niż 200, ponieważ „czytelność” nie jest dla mnie najwyższym priorytetem pod względem zapobiegania błędom ludzkim i poprawiania możliwości utrzymania kodu (łatwości, z jaką możemy to zmienić, tj.).
Wszystko to będzie jednak zależeć od naszej osobistej definicji „prostoty”. „Czytelność” zazwyczaj nie różni się tak bardzo wśród nas, chyba że ktoś zdobył tak dużą wiedzę i biegłość, że uważają wyrażenia regularne za bardzo „czytelne”, np. Zapominając o reszcie z nas zwykłych śmiertelników.
Prostota
Dawno, dawno temu myślałem, że „prostota” oznacza „tak łatwy do odczytania, jak to możliwe”. Pisałbym więc kod C z wieloma wygodnymi funkcjami, starając się poprawić składnię i uczynić rzeczy tak łatwymi do odczytu i zapisu, jak to możliwe.
W rezultacie zaprojektowałem bardzo duże, bogate biblioteki wysokiego poziomu, próbując modelować funkcję dla każdej naturalnej ludzkiej myśli: pomocników na pomocników na pomocników, wszystko w celu ukształtowania kodu klienta do bardziej czytelnej składni. Kod, który wtedy napisałem, mógł być najbardziej „czytelny”, ale był również najbardziej „niemożliwy do utrzymania” i „złożony”.
Seplenienie
Jednak miałem krótką pasję do LISP w połowie lat 90. (późny). Zmieniło to moją ideę „prostoty”.
LISP nie jest najbardziej czytelnym językiem. Mam nadzieję, że nikt nie myśli, że wyodrębnianie CDR i CAR podczas wywoływania funkcji rekurencyjnej z mnóstwem zagnieżdżonych nawiasów jest bardzo „czytelne”.
Niemniej jednak, po tym, jak starałem się owinąć mózg dziwną składnią języka i całkowicie rekurencyjnymi sposobami robienia rzeczy, na stałe zmieniłem mój pomysł na prostotę.
Z kodu, który napisałem w LISP, znalazłem to, że nie popełniłem już subtelnych błędów, chociaż podstępność myślenia w ten sposób sprawiła, że popełniłem więcej rażących błędów (ale są one łatwe do wykrycia i poprawienia). Nie pomyliłem się co do tego, co robi funkcja, i pominąłem subtelny, nieoczekiwany efekt uboczny. Po prostu łatwiej mi było wprowadzać zmiany i pisać poprawne programy.
Po LISPu prostota stała się dla mnie minimalizmem, symetrią, elastycznością, mniejszymi efektami ubocznymi, mniejszymi, ale bardziej elastycznymi funkcjami, które łączą się w nieskończenie różnorodny sposób.
Doceniłem sposób myślenia, że najbardziej niezawodny kod ze wszystkich to kod, który nie istnieje. Chociaż jest to tylko prymitywna metryka, widzę potencjał zawodności kodu na podstawie jego ilości. Poszukiwanie jak największej wygody syntaktycznej i czytelności ma tendencję do zwiększania tej wielkości o duży czynnik.
Minimalizm
Z osadzonym we mnie sposobem myślenia LISP, wolałem minimalistyczne API. Wolałbym bibliotekę z mniejszą, ale bardziej niezawodną, elastyczną funkcją, która jest mniej wygodna i potencjalnie trudniejsza do odczytania, niż ta, która oferuje mnóstwo „wygodnych” pomocników i takich, które mogą ułatwić „odczytanie” kodu, ale potencjalnie potkną się więcej problemów z zawodnością i niespodziankami, które wynikają z niezrozumienia, co robi jedna z tych tysięcy funkcji.
Bezpieczeństwo
Kolejną rzeczą w LISP było bezpieczeństwo. Promował minimalne skutki uboczne i czyste funkcje, i wtedy już nie widziałem, że popełniam subtelne błędy, mimo że trudność w czytaniu i pisaniu w języku zwiększyła więcej rażących błędów, które mogłem zauważyć 10 sekund później.
Czyste funkcje i niezmienne stany stały się dla mnie lepsze, gdy tylko było mnie na to stać, nawet jeśli składnia:
sword = sharpen(sword)
... jest nieco mniej bezpośredni i oderwany od ludzkiego myślenia niż:
sharpen(sword)
Czytelność VS. Prostota
Po raz kolejny LISP nie jest najbardziej „czytelnym” językiem. Może spakować dużo logiki do małej sekcji kodu (być może więcej niż jednej ludzkiej myśli w wierszu). Idealnie wolę jedną myśl ludzką na wiersz dla „czytelności”, ale niekoniecznie dla „prostoty”.
Przy takiej definicji „prostej”, czasami „prosta” może w rzeczywistości konkurować z „czytelną”. Rozważa to więcej z punktu widzenia projektowania interfejsu.
Prosty interfejs oznacza, że musisz nauczyć się znacznie mniej rzeczy do korzystania z niego, a potencjalnie ma większą niezawodność i mniej gotów dzięki minimalizmowi. Kompleksowa dokumentacja na ten temat może pasować do broszury, a nie do ogromnej ilości książek. Niemniej jednak może to wymagać nieco więcej pracy i uzyskania mniej czytelnego kodu.
„Prosty” dla mnie poprawia naszą zdolność do zrozumienia funkcjonalności naszego systemu na szerokim poziomie. „Czytelny” dla mnie poprawia naszą zdolność łączenia każdej małej linii kodu z naturalnym językiem i myślami i może przyspieszyć nasze rozumienie tego, co robi jedna linia kodu, szczególnie jeśli nie znamy tego języka.
Regex jest przykładem tego, co uważam za „wyjątkowo proste”. To „zbyt proste i zbyt nieczytelne” jak na mój osobisty gust. Pomiędzy tymi ekstremami jest dla mnie równowaga, ale regex ma taką prostotę jak LISP, jak ją definiuję: minimalizm, symetrię, niesamowitą elastyczność, niezawodność itp. Problem z regexem jest taki, że jest tak prosty, że stał się tak nieczytelny, że nie sądzę, żebym kiedykolwiek się nim posługiwał (mój mózg po prostu nie działa w ten sposób i zazdroszczę ludziom, którzy potrafią płynnie pisać kod wyrażenia regularnego).
W każdym razie taka jest moja definicja „prostoty” i jest ona całkowicie niezależna od „czytelności”, a czasami może nawet zakłócać inne, prowadząc do równowagi między bardziej „wygodną syntaktycznie” i czytelną, ale większą biblioteką lub „syntaktycznie” niewygodna ”, mniej czytelna, ale mniejsza biblioteka. Zawsze znajdowałem prawdziwe priorytety „wygody rozumienia” i prawdziwe „łatwości konserwacji”, aby dostosować się do tych ostatnich, z silną preferencją wobec minimalizmu, nawet przy pewnym koszcie czytelności i bardziej naturalnej ludzkiej składni (ale nie do regexu) . YMMV.