The Invent with Python Blog

the Zen of Python by Tim Peters are 20 guidelines for the design of the Python language. Twój kod Pythona niekoniecznie musi być zgodny z tymi wytycznymi, ale warto o nich pamiętać. Zen Pythona to Pisanka lub ukryty żart, który pojawia się, jeśli uruchomisz import this:

>>> import thisThe Zen of Python, by Tim PetersBeautiful is better than ugly.Explicit is better than implicit.Simple is better than complex.Complex is better than complicated.Flat is better than nested.Sparse is better than dense.Readability counts.Special cases aren't special enough to break the rules.Although practicality beats purity.Errors should never pass silently.Unless explicitly silenced.In the face of ambiguity, refuse the temptation to guess.There should be one-- and preferably only one --obvious way to do it.Although that way may not be obvious at first unless you're Dutch.Now is better than never.Although never is often better than *right* now.If the implementation is hard to explain, it's a bad idea.If the implementation is easy to explain, it may be a good idea.Namespaces are one honking great idea -- let's do more of those!

UWAGA: TYLKO 19 wytycznych jest spisanych. Guido van Rosum podobno powiedział, że brakujący 20. aforyzm to ” jakiś dziwaczny żart Tima Petersa.”

W końcu te wytyczne są opiniami, które można argumentować za lub przeciw. Jak wszystkie dobre zestawy kodeksów moralnych, czasami zaprzeczają sobie, aby zapewnić jak największą elastyczność. Oto moja własna interpretacja tych aforyzmów:

piękne jest lepsze niż brzydkie.

programiści często piszą Kod szybko, nie martwiąc się o czytelność. Chociaż kod nie musi być czytelny, kod samego języka Python musi być przemyślany, spójny i przyjemny w użyciu. Oczywiście nie każdy skrypt musi być piękny, a piękno jest subiektywne, ale duża część popularności Pythona wynika z łatwości pracy.

Explicit jest lepszy niż implicit.

„ten aforyzm jest oczywisty”, to byłoby straszne Wyjaśnienie dla każdego aforyzmu. Podobnie, lepiej, aby Kod był gadatliwy i jawny. Należy unikać ukrywania funkcjonalności kodu za niejasnymi funkcjami języka, które wymagają znajomości, aby w pełni zrozumieć.

proste jest lepsze niż złożone. Kompleks jest lepszy niż skomplikowany.

te dwa aforyzmy przypominają nam, że budowanie wszystkiego można zrobić za pomocą prostych lub złożonych technik. Z prostym problemem, takim jak budowa domku dla ptaków, proste rozwiązanie jest lepsze. Z drugiej strony, budowa silnika spalinowego jest złożonym problemem, który wymaga skomplikowanych technik. Nawet jeśli można technicznie zrobić silnik Diesla za pomocą technik birdhouse, prawdopodobnie skończy się skomplikowanym, układ Rube Goldberg części birdhouse, które nie byłoby idealnym rozwiązaniem. Wolą prostotę od złożoności, ale znają granice prostoty.

mieszkanie jest lepsze niż zagnieżdżone.

Programiści uwielbiają porządkować rzeczy w kategorie, zwłaszcza kategorie zawierające podkategorie, które zawierają inne podkategorie. Hierarchie te często nie dodają organizacji tak bardzo, jak dodają biurokracji. Dobrze jest mieć Kod tylko w jednym module lub klasie górnej warstwy, zamiast dzielić się na wiele podmodułów lub podklas. Jeśli tworzysz pakiety i moduły, które wymagają kodu, takiego jak import spam.eggs.bacon.ham.foo.bar, to Twój kod jest zbyt skomplikowany.

oszczędność jest lepsza niż gęsta.

programiści często lubią wpychać jak najwięcej funkcjonalności w jak najmniejszą ilość kodu, np. jednolinijkowe: print('\n'.join("%i bytes = %i bits which has %i possible values." % (j, j*8, 256**j-1) for j in (1 . While code like this may impress their friends, it'll infuriate their coworkers who have to try to understand it. Code that is spread out over multiple lines is often easier to read than dense one-liners.

liczy się czytelność.

podczas gdy strcmp() może oczywiście oznaczać funkcję „string compare” dla kogoś, kto programuje w C od lat 70., nowoczesne komputery mają wystarczająco dużo pamięci, aby zapisać pełną nazwę funkcji. Nie upuszczaj samogłosek ze swoich imion ani nie pisz zbyt zwięzłego kodu. Kod jest czytany częściej niż pisany, więc jawny, czytelny kod jest ważniejszy niż zwięzły, nieudokumentowany kod.

specjalne przypadki nie są na tyle specjalne, aby złamać zasady. Chociaż praktyczność bije czystość.

te dwa aforyzmy, które są zbiorem, są ze sobą sprzeczne. Programowanie jest pełne „najlepszych praktyk”, do których programiści powinni dążyć w swoim kodzie. Pomijanie tych praktyk w celu szybkiego włamania może być kuszące, ale może prowadzić do gniazda szczurów niespójnego, nieczytelnego kodu. Jednak pochylanie się do tyłu w celu przestrzegania reguł może skutkować wysoce abstrakcyjnym, nieczytelnym kodem. Próba dopasowania całego kodu do jego obiektowego paradygmatu często skutkuje dużą ilością kodu boilerplate dla nawet najmniejszego programu. Przejście granicy między tymi dwoma aforyzmami staje się łatwiejsze z doświadczeniem. Z czasem nauczysz się nie tylko zasad, ale także dowiesz się, kiedy je łamać.

błędy nigdy nie powinny przebiegać po cichu. Chyba że wyraźnie wyciszony.

to, że programiści często ignorują komunikaty o błędach, nie oznacza, że program powinien przestać je emitować. Ciche błędy mogą wystąpić, gdy funkcje zwracają kody błędów lub None zamiast zgłaszać wyjątki. Te dwa aforyzmy mówią nam, że lepiej dla programu fail fast i zawiesić się niż wyciszyć błąd i kontynuować uruchamianie programu. Błędy, które nieuchronnie zdarzają się później, będą trudniejsze do debugowania, ponieważ są one dalekie od pierwotnej przyczyny. Chociaż zawsze możesz wyraźnie zignorować błędy, które powodują twoje programy, po prostu upewnij się, że dokonujesz świadomego wyboru, aby to zrobić.

w obliczu niejednoznaczności Odrzuć pokusę zgadywania.

Komputery sprawiły, że ludzie są przesądni: aby egzorcyzmować demony w naszych komputerach, wykonujemy święty rytuał ich wyłączania, a następnie włączania. Podobno to rozwiąże każdy tajemniczy problem. Jednak komputery nie są magiczne. Jeśli twój kod nie działa, istnieje powód i tylko ostrożne, krytyczne myślenie go rozwiąże. Odrzuć pokusę ślepego próbowania rozwiązań, aż coś wydaje się działać; często po prostu zamaskowałeś problem, a nie rozwiązałeś go.

powinien być jeden—a najlepiej tylko jeden-oczywisty sposób.

to jest szeroka strona przeciwko motto języka programowania Perl, ” istnieje więcej niż jeden sposób, aby to zrobić!”Okazuje się, że trzy lub cztery różne sposoby pisania kodu, które robią to samo, to miecz obosieczny: masz elastyczność w pisaniu kodu, ale teraz musisz nauczyć się każdego możliwego sposobu, w jaki mógł zostać napisany, aby go odczytać. Ta elastyczność nie jest warta wysiłku 3x lub 4x potrzebnego do nauki języka programowania.

chociaż ten sposób może nie być oczywisty na początku, chyba że jesteś Holendrem.

ten tekst To żart. Guido van Rossum, twórca i Bdfl (życzliwy dyktator życia) Pythona, jest Holendrem. Jednak nawet ten aforyzm nie uniemożliwił Pythonowi włączenia trzech różnych sposobów formatowania ciągów.

teraz jest lepiej niż wcale. Chociaż nigdy nie jest często lepiej niż * teraz*.

te dwa aforyzmy mówią nam, że kod, który zawiesza się lub zostaje złapany w nieskończone pętle, jest oczywiście gorszy niż kod, który nie. jednak prawie na pewno lepiej jest poczekać na zakończenie programu, niż zakończyć go zbyt wcześnie z błędnymi wynikami.

jeśli implementacja jest trudna do wyjaśnienia, to zły pomysł. Jeśli implementacja jest łatwa do wyjaśnienia, może to być dobry pomysł.

Python stara się, aby praca programisty była łatwiejsza niż przystosowanie komputera, aby program działał szybciej. A programy muszą być zrozumiałe nie tylko dla programisty, który je napisał, ale także dla innych programistów, którzy utrzymują kod. Te dwa aforyzmy przypominają nam, że jeśli” wysokowydajny ” kod jest tak skomplikowany, że programiści nie mogą go zrozumieć i debugować, to jest to zły kod. Ale niestety, tylko dlatego, że łatwo jest wytłumaczyć komuś kod programu, nie oznacza to, że nie jest to zły kod. Programowanie jest trudne.

Przestrzenie nazw to świetny pomysł-zróbmy ich więcej!

Przestrzenie nazw (a także globalne i lokalne zakresy) są kluczem do zapobiegania konfliktom nazw w jednym module lub zakresie z nazwami w innym. Ale pamiętaj też, że płaskie jest lepsze niż zagnieżdżone: tak wielkie, jak są, przestrzenie nazw powinny być tworzone tylko po to, aby zapobiec konfliktom nazw i nie dodawać niepotrzebnej kategoryzacji.

jak wszystkie opinie na temat programowania, te, które tu napisałem, mogą być przeciwne lub po prostu nieistotne dla twojej sytuacji. Kłócenie się o to, jak należy pisać kod, rzadko jest tak produktywne, jak myślisz. (Chyba, że piszesz całą książkę pełną opinii programistycznych.)