Czy celem kodu jest „idiomatyczność” w celu zmniejszenia narzutu poznawczego?

Próbuję wyjaśnić komuś, że sposób, w jaki napisał kod, sprawia, że ​​trudno go zrozumieć, a jeśli go zrestrukturyzujesz, łatwiej będzie go przeczytać. Ten styl kodu, który używam, jest powszechnie nazywany „kodem idiomatycznym”.

Ale wyrażenie idiomatyczny kod niesie ze sobą bagaż moralnej poprawności , co nie jest świetną motywacją do nakłaniania ludzi do zmiany stylu kodowania. Bardziej pozytywnym sposobem powiedzenia tego jest kod zgodny ze wspólnym stylem - ale dla krytycznego myśliciela, który pojawia się jako rozumowanie mentalności stada.

Sposób, w jaki wymyśliłem wyjaśnienie tego pomysłu w sposób, który motywuje ludzi do zmiany kodu, to:

• pisanie kodu w taki sposób, aby zmniejszało ogólne obciążenie czytelnika (np. nie pamiętam, czy jest to pierwszy rodzaj wektora - czy piąty rodzaj wektora)
• kod, który ułatwia zrozumienie zamiaru (np. do czego służy ten wektor?)

(Nawiasem mówiąc, wiem, że książka Radość z Clojure przed pierwszym wydaniem miała tytuł Idiomatic Clojure. Wydawałoby się więc powód, by kod „idiomatyczny”, „przynosić radość” czytelnikowi ).

Moje pytanie brzmi: czy celem kodu jest „idiomatyczność” w celu zmniejszenia narzutu poznawczego?

Po pierwsze, nie jestem pewien, czy istnieje termin „poprawność moralna” w określeniu „idiomatyczny”. Zwykły słownikowa definicja jest po prostu

specyficzne lub charakterystyczne dla określonego języka lub dialektu: idiomatyczny francuski.

Tak, kod idiomatyczny ogólnie zmniejsza obciążenie poznawcze, szczególnie w definicjach interfejsów, w których standardowe biblioteki i wszelkie biblioteki stron trzecich, których potrzebuje projekt, są (praktycznie) idiomatyczne.

Jako punkt sprzedaży chciałbym jednak skupić się na tym, co robi dla ciebie redukcja kosztów poznawczych. Ułatwia to programistom wykrywanie błędów, ponieważ nie próbują rozwikłać kodu napisanego w unikalnym stylu, aby dowiedzieć się, gdzie jest to subtelnie spowodowane przez jeden błąd lub niewłaściwe obchodzenie się z przypadkiem marginalnym. Ułatwia przeglądanie kodu innych osób, co zwiększa prawdopodobieństwo, że zespół dokona prawdziwych recenzji, które identyfikują prawdziwe problemy, zamiast spierać się o składnię.

Kod idiomatyczny, oprócz zmniejszenia narzutu poznawczego, jest na ogół bardziej wydajnym kodem. Większość idiomów w danym języku ewoluuje, ponieważ język ma na celu podejście do problemów w określony sposób. Kompilatory lub interpretatory, których używasz, skoncentrują swoje optymalizacje na kodzie idiomatycznym. Jeśli na przykład używasz języka, w którym rekursja jest idiomatycznym sposobem strukturyzacji fragmentu kodu, możesz być prawie pewien, że Twój kompilator implementuje rekursję ogona. Jeśli używasz języka, w którym rekurencja nie jest idiomatyczna, jest to znacznie mniej prawdopodobne. Jest mało prawdopodobne, aby rekurencja ogona nie mogła być wdrożona wszędzie, ale większość autorów kompilatorów nie będzie koncentrować się na rzeczach, które nie zdarzają się często.

Nie jestem pewien, skąd bierze się pomysł, że idiomy mają jakiekolwiek konotacje moralne. Idiomy to tylko sposób na wyrażenie rzeczy. Są to wzory w skali większej niż pojedyncze słowa lub frazy.

Gdybym ci powiedział, że trzeba wyć z wilkami, nie wiedziałbyś, co mam na myśli, mimo że jest to dobrze znany niemiecki idiom. Gdyby, OTOH, powiedziałem wam, będąc w Rzymie, postępujcie tak jak Rzymianie, od razu wiedzielibyście o czym mówię, ponieważ użyłem właściwego angielskiego idiomu.

Języki komputerowe nie różnią się.

W rzeczywistości alternatywną nazwą „idiomu” w świecie programowania jest „wzorzec implementacji”. Odnosi się to do idei wzorów, która pochodzi od architekta (cegiełka, a nie bity) Christopher Alexander. Większość programistów wie o wzorach projektowych, niektórzy wiedzą o wzorcach architektury, które są wzorami w skali większej niż wzorce projektowe. Idiomy są wzorami w skali mniejszej niż wzorce projektowe.

Większość języków celowo nadaje się do określonego stylu. Kod napisany w tym stylu jest idiomatyczny. Jeśli pominąć okoliczność, że wybór środowiska wykonawczego zawęża dostępny wybór języków, należy wybrać języki, ponieważ problem jest łatwy do wyrażenia w poszczególnych idiomach danego języka.

Jednak większość ludzi tego nie rozumie. Na przykład wielu programistów Java stara się zachować ten sam styl, gdy muszą pisać JavaScript (mogliby napisać Javę i skompilować ją krzyżowo, pamiętaj) i do pewnego stopnia - pisząc kod JavaScript w języku JavaScript - ale zawsze będą mieli poczucie walki z JavaScriptem. Brakuje niektórych funkcji lub trudno jest je emulować.

Kod idiomatyczny jest dobry. To trudne dla osób postronnych, ale mogą się uczyć. Ostatecznie kod musi być utrzymywany przez lata, więc jeśli potrafisz znaleźć język w idiomach, w którym program podstawowy można wyrazić w prosty sposób, to powinieneś to zrobić.

Pozwólcie, że wyjaśnię, że zdecydowanie istnieje coś takiego jak nadużywanie idiomów (lub podstawowych funkcji językowych). Jeśli używasz szablonów C ++ do wykonywania znacznych części logiki aplikacji w czasie kompilacji lub jeśli twój kompletny program Lisp jest wywołaniem jakiegoś makra, które rozwija się do rzeczy w praktycznie nieprzewidywalny sposób, jeśli twoje proste rozwiązanie Java rozwiąże problem proporcje FizzBuzzEnterpriseEdition ... robisz to źle.

Ludzie mówią, że kod musi być łatwy do odczytania. To tylko połowa prawdy. Musi być łatwy do zrozumienia, co wymaga również łatwego rozumowania. Wymaga to odpowiedniego wykorzystania abstrakcji. Podobnie jak w przypadku większości rzeczy, chodzi o zachowanie właściwej równowagi.