Желите да постанете бољи у писању Питхон кода? Ево како вам Зен оф Питхон може помоћи да направите прве кораке ка томе.
Питхон је супер једноставан за учење. Али писање идиоматског и Питхониц кода који је лако одржавати може бити изазов — посебно за програмере почетнике. ПЕП-20 је представио „Зен Питхона“, песму Тима Петерса, која истиче важност писања Питхониц кода који се придржава најбољих пракси.
Да бисте прочитали Зен оф Питхон, можете покренути Питхон РЕПЛ и покренути:
>>> import this
The Zen of Python, by Tim Peters Beautiful 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!
Као што се види, већина афоризама у Зен оф Питхон је сама по себи разумљива. Неке афоризме треба спојити са следећим приликом тумачења, док су неки други у супротности са ранијим афоризмом. Без обзира на то, Зен оф Питхон је забавно, занимљиво и практично читање!
Преглед садржаја
Тумачење зена Пајтона
Предложено је да Зен оф Питхон има 20 водећих принципа за програмирање у Питхон-у. Међутим, до сада постоји само 19 афоризама. Хајдемо преко њих.
Лепо је боље него ружно.
Овај афоризам наглашава важност писања елегантног и Питхониц кода.
Следећи исечак кода има мирис кода:
def square(num):
squares = []
for i in range(num):
squares.append(i*i)
return squares
Функција:
- Иницијализује празну листу
- Има петљу унутар функције која додаје елементе на крај листе и
- Коначно враћа листу
Иако је ово функционално исправно — није Питхониц — и тешко га је одржавати.
Можете га написати много елегантније користећи генераторе. Ево функције генератора еквивалентне горњој функцији:
def square(num):
for i in range(num):
yield i*i
Или још боље, можете имати следећи израз за разумевање генератора:
num = ... squares = (i*i for i in range(num))
Експлицитно је боље него имплицитно.
Када пишете код, не остављајте друге програмере и кориснике да нагађају подразумевано или подразумевано понашање кода. Будите експлицитни. Узмимо пример увоза џокер знакова:
from some_module import * # wildcard import from some_other_module import * result = some_function() # where did this come from?
Избегавајте увоз џокер знакова што је више могуће. Зато што није експлицитно и неефикасно. Будите прецизни када увозите функције и класе из других модула:
from some_module import this_function # explicit import result = this_function() # we now know.
Једноставно је боље од сложеног.
Овај афоризам каже да код треба да буде једноставан и да избегавамо непотребну сложеност. На пример: можда ћете желети да обрнете стринг и примените следеће рекурзивно решење:
def reverse_string(my_string):
if my_string == "":
return my_string
else:
return reverse_string(my_string[1:]) + my_string[:1]
Иако ово функционише, ово је вероватно претерано пројектовано решење за овај проблем — с обзиром на то да постоје једноставнији и више Питхониц начина да се то уради.
Ево приступа сечења низова:
>>> rev_string = my_string[::-1] >>> rev_string 'nohtyP'
А ево приступа који користи уграђене методе и функције:
>>> rev_string = ''.join(reversed(my_string)) >>> rev_string 'nohtyP'
Комплексно је боље него компликовано.
Дакле, шта овај следећи афоризам у Зен оф Питхон преноси?
Преокретање стрингова у Питхон-у је супер једноставна операција. У пракси, међутим, можда ће нам требати сложенија логика. Ево прилично једноставног примера:
Рецимо да морате да се повежете са базом података:
- Прво би требало да анализирате томл конфигурациону датотеку—да бисте преузели информације о конфигурацији базе података.
- Конектор базе података треба да буде инсталиран.
- Затим можете дефинисати функцију за повезивање са базом података, предвиђање грешака у повезивању, имплементацију руковања грешкама и још много тога.
- Коначно, након повезивања са базом података, можете је поставити упит.
Иако је ово и даље довољно једноставно, потребна му је сложенија логика у поређењу са преокретом низа. Али то не значи да мора бити компликовано. И даље можете ефикасно да користите функционалност кода уграђених модула и организујете свој код тако да други програмери могу да га читају, разумеју и доприносе.
Стан је бољи од угнежђеног.
Равну структуру је лако рашчланити и разумети него угнежђену структуру. Док радите на пројекту, можда ћете бити у искушењу да изолујете функционалност креирањем засебних модула. Међутим, превелика грануларност може бити претерана.
Уз то, можда ћете често морати да идете даље од равне структуре. Али чак и ако вам је потребно гнежђење, смањите га на минимум.
Ево примера:
from db_info.config.actions.parse.parse_config import parse_toml # too difficult to parse! ... from db_config.parse_config import parse_toml # much better! ...
Ретко је боље него густо.
Ако тек почињете на свом путу програмера, можда ћете бити у искушењу да претерано користите неке од карактеристика језика. Разумевања листе, на пример, су Питхониц — али само када их користите тамо где су потребна.
Погледајте следеће разумевање:
prices_dict = {'melons':40,'apples':70,'berries':55}
items = [(fruit,price) for fruit in prices_dict.keys() if fruit.startswith('m') for price in prices_dict.values() if price < 50]
print(items)
# Output: [('melons', 40)]
Разумевање листе је превише густо и тешко за рашчлањивање. У овом случају, коришћење еквивалентне петље фор са условним биће читљивије. То значи да је разумевање тешко разумљиво. 🙂
Читљивост се рачуна.
Увек треба да пишете читљив код. Ево неколико једноставних начина да побољшате читљивост кода:
- Коришћење описних имена променљивих
- Додавање низова докумената за функције и класе
- Коментар код где је потребно
- Додавање типова наговештаја за аргументе и враћање типова функција
Посебни случајеви нису довољно посебни да би прекршили правила.
Требало би — колико год је то могуће — да се придржавате правила језика и препоручених најбољих пракси.
Али да ли је ово увек могуће? Не, и зато имамо следећи афоризам.
Иако практичност побеђује чистоћу.
Ово је наставак претходног афоризма. Иако се препоручује да се придржавате правила језика, у одређеним случајевима је сасвим у реду не поштовати неке од принципа.
Грешке никада не би требало да прођу тихо.
У Питхон рунтиме грешке су прилично честе. Као добра пракса, увек треба да решавате грешке и да их не утишавате као брзо решење.
Можете предвидети и применити одговарајуће руковање грешкама—за различите типове грешака:
try:
# doing this
except ErrorType1:
# do something
except ErrorType2:
# do something else
...
Требало би да избегавате голе и генеричке изузетке. Новије верзије Питхон-а (од Питхон-а 3.11) подржавају уланчавање изузетака и групе изузетака како би се извршило софистицираније руковање изузецима.
Осим ако се изричито не ућутка.
Ово следи претходни афоризам. Ако дизајн захтева или дозвољава да се грешка утиша, онда то треба да се уради експлицитно.
На пример: када се повезујете са базом података, можете наићи на ОператионалЕррор због неважећих информација о конфигурацији. Покушајте да се повежете користећи прилагођену конфигурацију. У случају да постоји ОператионалЕррор, користите подразумевану конфигурацију и покушајте да се повежете са базом података.
try: # connecting using custom config except OperationalError: # connect using default config
Суочени са нејасноћом, одбијте искушење да погађате.
Овај афоризам у Зен оф Питхон је сам по себи разумљив. Када сте у недоумици, немојте погађати. Али покрените код и проверите излаз. Затим, у зависности од тога да ли имате жељено понашање, побољшајте читљивост или модификујте логику по потреби.
Узмите следећи једноставан пример са низом Булових вредности:
>>> True, True == (True, True) (True, False) >>> True, (True == (True, True)) (True, False) >>> (True, True) == (True, True) True
Требало би да постоји један – и по могућности само један – очигледан начин да се то уради.
Да би се извршио одређени задатак, требало би да постоји један и само један препоручени питонски начин да се то уради. Међутим, за сваки проблем можемо имати више решења.
Чак иу једноставном примеру преокретања стрингова, погледали смо рекурзивно решење, пресецање стрингова и метод јоин().
Ово је такође унутрашња шала с обзиром на недоследну употребу ем-цртица. Обично користимо ем-цртице без водећих и завршних размака. Или га користимо и са водећим и са задњим размацима.
Дакле, ево шта можемо закључити. Афоризам који наглашава да треба да постоји један — и само један — питонски начин да се ствари ураде може се написати на више од два начина.
Иако тај начин можда неће бити очигледан у почетку осим ако нисте Холанђанин.
Написано на лаганој ноти, ово се односи на Гвида Ван Росума, творца Питхона (који је Холанђанин). (Нај)Питхониц начин да се постигне одређени задатак—природан је само за творце Питхона.
Дакле, за програмере је потребно искуство — и учење из искуства — да би боље искористили карактеристике језика.
Сада је боље него никад.
Као и са неколико других афоризама у Зен оф Питхон, и овај се може тумачити на неколико различитих начина.
Једно тумачење је да је као програмер прилично уобичајено одлагати почетак кодирања пројекта. Уместо да чекате да планирате најситније детаље пројекта, боља је идеја почети сада.
Друга могућа интерпретација је: код који се покреће у коначном броју корака — и завршава се — често је бољи од кода који греши и заглави се у бесконачној петљи.
Иако никада није често боље него сада.
Чини се да је овај афоризам у супротности са претходним. Иако је боље не одлагати, ипак бисмо требали размислити о проблему и дизајнирати код у складу с тим.
Лоша идеја је кодирање модула — без размишљања о њему — са мирисима кода и анти-узорцима. Зато што је такав код тешко рефакторирати и применити корективне мере.
Ако је имплементацију тешко објаснити, то је лоша идеја.
Било која логика – колико год сложена била – увек се може применити у облику који је једноставан за објашњење и разумљив.
Ако је имплементацију тешко објаснити, вероватно постоји нека непотребна сложеност. Код се може модификовати или рефакторисати тако да га је лакше пратити.
Ако је имплементацију лако објаснити, то би могла бити добра идеја.
Ово је повезано са претходним афоризмом и такође је само по себи разумљиво. Ако се имплементација може објаснити једноставним речима, онда је то вероватно добра идеја.
Зато што ће такав код чија се имплементација може описати — једноставним речима — врло вероватно бити читљив и лак за праћење — уз минималну сложеност.
Простори имена су једна сјајна идеја – хајде да урадимо више њих!
У Питхон-у се објектима у одређеном опсегу може приступити користећи њихова имена у њиховом именском простору. На пример, можете креирати класу и користити је као шаблон за креирање инстанци класе. Сада ће све променљиве инстанце бити у именском простору инстанце.
Ово нам омогућава да користимо објекте са истим именом — без сукоба — јер се налазе у различитим именским просторима. Међутим, требало би да их користите само по потреби и обезбедите да једноставност и читљивост кода нису угрожени.
Закључак
То је све за овај водич! Надам се да вам је овај водич помогао да разумете како Зен оф Питхон наглашава стил кода и добре праксе кодирања у Питхон-у. Што више кодирате, то ћете боље добити.
Ако сте заинтересовани да научите како да пишете концизан и читљив код, прочитајте овај чланак о Питхон једноструким.