Python’ın Zeni’inden Çıkarılan Dersler

Python’ın Zeni’i nedir? 

Python’ın Zeni’i, Python’un tasarımına yön veren on dokuzaforizmadan oluşan bir bütünüdür. Aslında yirmi aforizma olması düşünülmüştü; ancak Python’un yaraticısı Guido van Rossum, Python’ın Zeni’inin yaraticısı Tim Peters’ın niyet ettiği gibi son aforizmayı hâlâ eklemedi. Guido’nun, eksik olan yirminci aforizmanın “Tim Peters’a özgü tuhaf bir iç şaka” olduğunu söylediği aktarılır.

Eksik yirminci aforizmaya rağmen, Python geliştiricilerinin geliştirme süreci üzerindeki büyük etkisi nedeniyle Python’ın Zeni’i 2004’te PEP 20 olarak standartlaştırıldı. Python’ın Zeni’ini izlemek zorunlu değildir, ancak bilmek ve akılda tutmak önerilir. Dersleri bir gün unutursanız, Python yorumlayıcısında import this çalıştırarak hafızanızı kolayca tazeleyebilirsiniz. 

>>> 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!

Bu yazıda, her bir dersi daha ayrıntılı ele alacağız. 

#1 Güzel, çirkinden daha iyidir 

Bir programcıysanınız, hiç şüphesiz oldukça yeteneklisiniz. Kodla sorun çözebilmek kolay bir iş değil; ancak bir Python kullanıcısı olarak sizden fazlası beklenir. Güzel kod, çirkin koddan daha iyidir. Python’un hızlı şöhret yükselişi kısmen erişilebilirliğine bağlıdır: basit, okunabilir ve zariftir. Bir Python geliştiricisi olarak göreviniz, güzel kod yazarak Pythonik standardı sürdürmektir. 

Güzel kod nedir? Şey, bu öznel bir konu — güzellik görünene göredir vs. Sizi doğruda tutacak basit bir kural, diğer geliştiricilerin kolayca anlayabileceği temiz, okunabilir kod yazmaktır. Örneğin: 

"""
Initial code was created by Vishal Sharma
See:  https://towardsdatascience.com/the-zen-of-python-a-guide-to-pythons-design-principles-93f3f76d088a
"""
def collatz(num):
    if num % 2 == 0:
        return num // 2
    else:
        return 3 * num + 1

number = input("Enter a number: ")

while number != 1:
    number = collatz(int(number))
    print(number)

"""
Enter a number: 5
16
8
4
2
1
"""

Yukarıdaki kod gayet iyi çalışıyor, ancak illa ki güzel olduğu söylenemez. collatz fonksiyonumuzda gereksiz bir else koşulu var; aşağıdaki gibi kaldırabiliriz: 

def collatz(num):
  if num % 2 == 0:
      return num // 2
 
  return 3 * num + 1

Dolayısıyla, elinizde çalışan iki kod parçası olduğunda, daha basit, daha okunabilir ve anlaşılması daha kolay olanı tercih etmelisiniz. 

#2 Açık, üstü kapalıdan daha iyidir

Herhangi bir aforizmayı “kendi kendini açıklıyor” diye açıklamak büyük bir hatadır — yine de böyle yapanlara rastlarsınız. “Açık, üstü kapalıdan daha iyidir” sözündeki ana fikir, dolaylı koda karşı daha açık seçik, sözü uzatan kodun tercih edilmesidir. Kodunuzun işlevinin muğlak ifadelerin arkasına saklanmaması için elinizden geleni yapın. Programınızı hiç bilmeyen biri bile kodunuzda neler olduğunu anlayabilmelidir. 

#3 Basit, karmaşıktan daha iyidir

Bir dostunuz yemekten sonra bulaşıkları yıkmak için basınçlı yıkayıcı çıkarırsa muhtemelen gülersiniz. Sadece aşırı anlamsız bir çözüm değil, ayrıca tabakların zarar görme olasılığı da yüksektir. Benzer şekilde, basit bir programlama sorununa aşırı karmaşık bir çözüm uygulamak son derece kullanışsızdır. Çözümünüzü gereksiz yere karmaşıklaştırmanıza gerek yok; bu sizi zeki gösterecek diye düşünseniz bile. Daha çok zarar verebilirsiniz ve bu Python’da hoş karşılanmaz. 

Bir dizeyi terse çevirmek için kullanılan şu fonksiyona bakın: 

def reverse_string(string):
    if len(string) == 1:
        return string
    else:
        return reverse_string(string[1:]) + string[0]


string = "kurtis"

print(reverse_string(string))

"""
sitruk
"""

Yukarıdaki kod elbette sorunu çözüyor ama gereksiz yere karmaşık. Python’a iyi hâkimseniz bir dizenin indekslemeyle terse çevrilebileceğini bilirsiniz. 

string = "kurtis"

# annonymous function solution
reverse_string = lambda x: x[::-1]

# function solution
def reverse(string):
    return string[::-1]

print(reverse_string(string))
print(reverse(string))

"""
sitruk
sitruk
"""

#4 Karmaşık, karmakarışıktan daha iyidir 

Tabakları basınçlı yıkayıcıyla yıkamak kullanışlı değildir: akan musluk suyuyla basit bir çözüm daha iyidir. Peki sorun bir 4x4 Range Rover’ı temizlemek olsaydı? Önceki aforizma ile bu aforizma, tek bir sorunu çözmek için hem basit hem de karmaşık tekniklerin uygulanabileceğini hatırlatır. Bir 4x4 Range Rover’ı temizlemek basit bir sorun değildir ve bulaşık yıkarken kullandığınız teknikleri uygulamaya çalışmak işe yarayabilir ama basınçlı yıkayıcı kullanmaktan daha karmaşıktır. Bu nedenle, sadeliği karmaşıklığa tercih etmelisiniz; ancak sadeliğin işe yaramadığı durumlarda karmaşıklığı seçmek daha iyidir — sadeliğin sınırlarını bilin. 

#5 Yatay düzen, iç içe yapıdan daha iyidir 

Programcılar, işlevselliği ayırmak için şeyleri kategorilere, alt kategorilere ve altın alt kategorilere ayırmayı sever. Düzenli gibi dursa da kodu bu şekilde düzenlemek, düzen getirmekten çok kafa karışıklığına yol açabilir. 

Tüm kodunuzu tek bir üst düzey modüle koymanızda bir sakınca yoktur: belirli bir işlevselliğe erişmek için from spam.foo.bar.john.doe import chicken gibi bir şey yapmanız gerekmez. Eklediğiniz her alt kategori, kodunuzu daha karmaşık hale getirir. Mümkün olduğu sürece düz bir yapıya bağlı kalmak için elinizden geleni yapın.

#6 Seyrek, yoğundan daha iyidir

Programcılar en zeki insanlar arasında sayılır; dolayısıyla zekânızı aşırı incelikli numaralarla sergilemenize gerek yok. En sık duyacağınız, “[bir karmaşık görevi] 1 satır kodla nasıl yaparsınız” olur. Bazen tek satırlıklar mantıklıdır, ancak tüm işlevi tek satıra sığdırmak uğruna okunabilirlikten ödün vermekten kaçının. 

Şu kod parçasını örnek alalım: 

"""
Code source Al Sweigart
See: https://inventwithpython.com/blog/author/al-sweigart.html0
"""
print('\n'.join("%i bytes = %i bits which has %i possible values." % (j, j*8, 256**j-1) for j in (1 << i for i in range(8))))
"""
1 bytes = 8 bits which has 255 possible values.
2 bytes = 16 bits which has 65535 possible values.
4 bytes = 32 bits which has 4294967295 possible values.
8 bytes = 64 bits which has 18446744073709551615 possible values.
16 bytes = 128 bits which has 340282366920938463463374607431768211455 possible values.
32 bytes = 256 bits which has 115792089237316195423570985008687907853269984665640564039457584007913129639935 possible values.
64 bytes = 512 bits which has 13407807929942597099574024998205846127479365820592393377723561443721764030073546976801874298166903427690031858186486050853753882811946569946433649006084095 possible values.
128 bytes = 1024 bits which has 179769313486231590772930519078902473361797697894230657273430081157732675805500963132708477322407536021120113879871393357658789768814416622492847430639474124377767893424865485276302219601246094119453082952085005768838150682342462881473913110540827237163350510684586298239947245938479716304835356329624224137215 possible values.
"""

Kod elbette çalışıyor ama anlamak tam bir kâbus: sıkışık ve okumayı zorlaştırıyor. 

Aynı kodu seyrek biçimde yazsak nasıl olur, bakalım: 

# Sparse example
bytes_and_bits = {j: j*8 for j in (1 << i for i in range(8))}

for bytes, bits in bytes_and_bits.items():
    print(f"{bytes} bytes = {bits} which has {256**bytes-1} possible values")

"""
1 bytes = 8 which has 255 possible values
2 bytes = 16 which has 65535 possible values
4 bytes = 32 which has 4294967295 possible values
8 bytes = 64 which has 18446744073709551615 possible values
16 bytes = 128 which has 340282366920938463463374607431768211455 possible values
32 bytes = 256 which has 115792089237316195423570985008687907853269984665640564039457584007913129639935 possible values
64 bytes = 512 which has 13407807929942597099574024998205846127479365820592393377723561443721764030073546976801874298166903427690031858186486050853753882811946569946433649006084095 possible values
128 bytes = 1024 which has 179769313486231590772930519078902473361797697894230657273430081157732675805500963132708477322407536021120113879871393357658789768814416622492847430639474124377767893424865485276302219601246094119453082952085005768838150682342462881473913110540827237163350510684586298239947245938479716304835356329624224137215 possible values
"""

Yukarıdaki kod okumasi çok daha kolay ve tek satırlıkla aynı işi yapıyor.

#7 Okunabilirlik önemlidir

Henüz anlamadıysanız, Python söz konusu olduğunda okunabilirlik önemlidir. Siz kodu bir kez yazarsınız. Ancak kodun birçok kez okunma olasılığı yüksektir. Bunu göz önüne alırsak, değişken ve fonksiyon adlarından ünlüleri atmak iyi bir fikir değildir: bir fonksiyona create_lst ya da create_list adını verme seçeneğiniz varsa, ikincisini seçin. 

#8 Özel durumlar, kuralları bozacak kadar özel değildir

Python [ve genel olarak programlama] uymamiz gereken birçok en iyi uygulamayla doludur. Genellikle kendi yolunuza gitmek tutarsız, okunması zor koda yol açtığı için, en iyi uygulamaları izlemek daha iyidir. 

#9 Ancak kullanışlılık saflığı yener

Dokuzuncu ders, sekizinci dersin devamıdır. Evet, en iyi uygulamaları izlemek daha iyidir; ancak kurallara uymak uğruna aşırı çabalamak da okunması zor koda yol açabilir. Bu nedenle, her kuralın bir istisnası olabilir. Bir sorunu çözme yönteminiz daha pratik, daha okunabilir ve daha kolay anlaşılıyorsa, yerleşik en iyi uygulamalardan sapmak daha iyidir. 

#10 Hatalar asla sessizce geçmemelidir 

Sessiz hata, bir programın istisna yükseltmek yerine bir hata kodu ya da None döndürmesi durumudur. Bir programın çökmesi, hatanın susturulup çalışmaya devam etmesinden daha iyidir. Uzun vadede, hataları susturmak programınızda çok daha zor giderilecek hatalara yol açabilir. 

#11 Tabii açıkça susturulmadıkça

On birinci ders, onuncunun devamıdır. Programınızın neden olduğu hataları görmezden gelmek isteyebileceğiniz bazı durumlar olabilir. Bu gibi hallerde, en iyi uygulama hatayı kodunuzda açıkça susturmaktır. 

#12 Belirsizlik karşısında, tahmin etme cazibesine karşı koyun

Bilgisayarlar sadece onlara söylediğimiz şeyi yapar: Kodunuz istediğiniz gibi davranmıyorsa, bu sizin ona söylediğinizi yapmasındandır. Gelişigüzel farklı çözümler deneyerek birinin işe yarayana kadar denemek kötü bir stratejidir — sorunu çözmek yerine örtbas edebilirsiniz. Bu cazibeye direnin. Bunun yerine, sorunun mantığını düşünün ve uygun bir çözüm bulmak için eleştirel düşünceyi uygulayın. 

#13 Bunu yapmanın bir — tercihen yalnızca bir — açık, bariz yolu olmalıdır 

Perl programlama dilinin sloganı şöyledir: “Bunu yapmanın birden çok yolu var!” Seçenek fazlası genellikle seçim felcine yol açar. Aynı amaca ulaşan kodu yazmanın birden çok yolu olduğunda da benzer bir durum ortaya çıkar. Kodu yazma biçiminizde daha esnek olursunuz, ancak artık kodu okumak için yazılmış olabilecek tüm yollan öğrenmeniz gerekir: tüm senaryoları öğrenmek için gereken fazladan çaba gereksizdir. 

#14 Ancak o yol, Hollandalı değilseniz ilk bakışta bariz olmayabilir

Bu aforizma, Tim Peters’ın mizah anlayışını yansıtır: Python programlama dilinin yaraticısı ve Python için Ömür Boyu Hayırsever Diktatör (BDFL) olan Guido van Rossum Hollandalıdır. Bu, Python’un dil kurallarını anlamanın ve hatırlamanın, yaraticısı dışındaki herkes için zorlu olduğunu anımsatan bir şakadır. 

#15 Şimdi, hiçbir zamandan daha iyidir

Bu aforizma, sonsuz döngüye sıkışan ya da takılan kodun, takılmayan koda göre daha kötü olduğunu söyler. 

#16 Ancak bazen şimdi *hemen* yapmaktan sağduyulu biçimde hiç yapmamak daha iyidir

On altıncı dersten devamla: Programınızın çalışmasını bitirmesini beklemek, onu erken sonlandırıp yanlış sonuçlar almaktan daha iyidir. 

#17 Uygulamasını açıklamak zorsa, kötü bir fikirdir

Sadece kendi uygulamalarınızı anlamanız yeterli değildir — “Ne demek istediğimi biliyorum” işlemez. Programlama bir ekip işidir ve uygulamanızı ekip arkadaşlarınıza açıklayamıyorsanız, muhtemelen çözümü fazla karmaşık hale getirmişsinizdir. 

#18 Uygulamasını açıklamak kolaysa, iyi bir fikir olabilir

Ancak kolay açıklanabilir kod illa ki kötü olmadığı anlamına gelmez — sadece açıklamasının kolay olduğunu gösterir. Yine de kötü kodunuz olabilir; ama açıklaması kolaysa doğru yolda olduğunuz anlamına gelir. 

#19 İsim alanları muhteşem bir fikirdir — onlardan daha çok yapalım!

İsim alanı, Python’da bir programdaki nesnelere atanan adları düzenlemek için kullanılan bir soyutlamadır. Belirli bir isim alanı ve kapsam verildiğinde, Python, sembolik bir ada çağrı yaptığınızda hangi nesneden söz ettiğinizi belirleyebilir. Bu aforizmanın söylediği, Python’un perde arkasında sembolik adları düzenleme biçiminin oldukça harika olduğudur. 

Sonuç 

Bu yazıda, Python geliştiricilerini temiz, okunabilir kod yazmaya teşvik etmek için oluşturulmuş yönergeler olan Python’ın Zeni’ine kendi yorumumuzu sunduk. Kimileri Python’ın Zeni’ine kusursuz kod yazmanın nihai plani olarak bakarken, kimileri daha az ciddiye alır. İlkeleri kendi kodunuza uygulamayı deneyerek işinize nasıl doğrudan katki sağlayabileceklerini görmenizi öneririz. İyileştirilmiş kod yazma konusunda daha fazla öğrenmek isterseniz DataCamp’in Writing Efficient Python Code kursuna göz atın.