Pelajaran dari Zen of Python

Apa itu Zen of Python? 

Zen of Python adalah kumpulan sembilan belas aforisme yang menjadi prinsip panduan bagi desain Python. Sebenarnya seharusnya ada dua puluh aforisme; namun Guido van Rossum, pencipta Python, masih belum menambahkan aforisme terakhir seperti yang dimaksudkan oleh Tim Peters, pencipta Zen of Python. Menurut kabar, Guido menyatakan bahwa aforisme kedua puluh yang hilang adalah “lelucon internal Tim Peters yang aneh.”

Meski aforisme kedua puluh hilang, Zen of Python distandardisasi sebagai PEP 20 pada tahun 2004 karena pengaruh besarnya terhadap proses pengembangan para pemrogram Python. Mengikuti Zen of Python bukanlah kewajiban, tetapi mengetahuinya dan mengingatnya sangat disarankan. Jika Anda lupa pelajarannya, Anda bisa dengan mudah menyegarkan ingatan dengan menjalankan import this dari interpreter Python. 

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

Dalam artikel ini, kita akan membahas setiap pelajaran dengan lebih rinci. 

#1 Indah lebih baik daripada jelek 

Jika Anda seorang pemrogram, tidak diragukan lagi Anda sangat terampil. Kemampuan memecahkan masalah dengan kode bukan tugas mudah, tetapi sebagai Pythonista, Anda diharapkan lebih. Kode yang indah lebih baik daripada kode yang jelek. Kenaikan popularitas Python yang pesat sebagian karena aksesibilitasnya: sederhana, mudah dibaca, dan elegan. Sebagai pengembang Python, Anda bertanggung jawab menjaga standar pythonic dengan menulis kode yang indah. 

Apa itu kode yang indah? Ya, ini subjektif—soal selera. Aturan praktis sederhana untuk menjaga Anda tetap pada jalur yang benar adalah menulis kode yang rapi dan mudah dibaca sehingga mudah dipahami oleh pengembang lain. Contohnya: 

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

Kode di atas berjalan dengan baik, tetapi belum tentu indah. Kita memiliki kondisi else yang tidak perlu pada fungsi collatz yang bisa dihapus seperti berikut: 

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

Jadi, saat Anda dihadapkan pada dua potongan kode yang sama-sama bekerja, pilihlah yang lebih sederhana, lebih mudah dibaca, dan lebih mudah dipahami. 

#2 Eksplisit lebih baik daripada implisit

Menjelaskan aforisme apa pun sebagai “sudah jelas” adalah kesalahan besar—meski Anda masih sering melihat orang melakukannya. Inti dari “eksplisit lebih baik daripada implisit” adalah bahwa kode yang lugas lebih disukai daripada kode yang berputar-putar. Lakukan segala yang Anda bisa untuk memastikan fungsionalitas kode Anda tidak tersembunyi di balik bahasa yang samar. Seseorang tanpa pengetahuan awal tentang program Anda seharusnya tetap bisa memahami apa yang terjadi di dalam kode Anda. 

#3 Sederhana lebih baik daripada kompleks

Anda mungkin akan tertawa jika teman Anda mengeluarkan jetwash untuk mencuci piring setelah makan malam. Selain solusinya sangat konyol, piringnya juga berisiko rusak. Dengan cara yang sama, menerapkan solusi yang sangat kompleks untuk masalah pemrograman yang sederhana sangat tidak praktis. Tidak perlu membuat solusi Anda terlalu rumit, meski Anda pikir itu membuat Anda terlihat pintar. Anda bisa menimbulkan lebih banyak kerusakan daripada manfaat, dan hal itu tidak dihargai dalam Python. 

Lihat fungsi berikut yang digunakan untuk membalik string: 

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

Kode di atas memang menyelesaikan masalah, tetapi terlalu kompleks. Jika Anda memahami Python dengan baik, Anda tahu bahwa string dapat dibalik dengan indexing. 

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 Kompleks lebih baik daripada rumit 

Mencuci piring dengan jetwash itu tidak praktis: Anda lebih baik menggunakan solusi sederhana seperti air kran yang mengalir. Tetapi bagaimana jika masalahnya adalah membersihkan Range Rover 4x4? Aforisme sebelumnya dan yang ini mengingatkan kita bahwa teknik sederhana dan kompleks sama-sama bisa diterapkan untuk menyelesaikan satu masalah. Membersihkan Range Rover 4x4 bukan masalah sederhana dan mencoba menerapkan teknik yang sama seperti mencuci piring mungkin bisa, tetapi justru lebih rumit daripada menggunakan jetwash. Jadi, utamakan kesederhanaan daripada kompleksitas, tetapi dalam situasi di mana kesederhanaan tidak praktis, lebih baik memilih kompleksitas—kenali batas-batas kesederhanaan. 

#5 Datar lebih baik daripada bertingkat 

Pemrogram suka mengelompokkan sesuatu ke dalam kategori, subkategori, dan sub-subkategori sebagai cara memisahkan fungsionalitas. Meski terdengar tertata, mengorganisasi kode dengan cara seperti itu bisa menimbulkan lebih banyak kebingungan daripada kerapian. 

Tidak ada yang salah dengan menaruh semua kode Anda di satu modul lapisan atas: artinya Anda tidak perlu melakukan sesuatu seperti from spam.foo.bar.john.doe import chicken untuk mengakses fungsi tertentu. Semakin banyak subkategori yang Anda tambahkan, semakin rumit kode Anda. Lakukan yang Anda bisa untuk tetap menggunakan struktur yang datar bila memungkinkan.

#6 Renggang lebih baik daripada padat

Pemrogram dianggap termasuk manusia paling cerdas, jadi tidak perlu menonjolkan intelektualitas Anda dengan trik yang terlalu rumit. Yang paling sering Anda dengar adalah “cara melakukan [tugas rumit] dalam 1 baris kode.” Terkadang, one-liner dapat dibenarkan, tetapi hindari situasi di mana Anda mengorbankan keterbacaan demi memadatkan seluruh fungsionalitas dalam satu baris. 

Ambil potongan kode ini sebagai contoh: 

"""
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.
"""

Kode tersebut memang berfungsi, tetapi benar-benar sulit dipahami: terlalu rapat dan sulit dibaca. 

Mari kita lihat seperti apa kode yang sama jika ditulis secara renggang: 

# 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
"""

Kode di atas jauh lebih mudah dibaca dan melakukan hal yang persis sama seperti one-liner.

#7 Keterbacaan itu penting

Jika Anda belum menebaknya, keterbacaan itu penting dalam Python. Tugas Anda adalah menulis kode sekali. Namun, kemungkinan besar kode itu akan dibaca berkali-kali. Dengan mempertimbangkan hal ini, menghilangkan huruf vokal dari nama variabel dan fungsi bukan ide yang bagus: dalam situasi Anda bisa menamai fungsi create_lst atau create_list, pilihlah yang kedua. 

#8 Kasus khusus tidak cukup istimewa untuk melanggar aturan

Python [dan pemrograman secara umum] penuh dengan sejumlah praktik terbaik yang harus diikuti. Lebih baik mengikuti praktik terbaik daripada melakukannya dengan cara Anda sendiri karena sering kali itu menghasilkan kode yang tidak konsisten dan sulit dibaca. 

#9 Meskipun kepraktisan mengalahkan kemurnian

Pelajaran kesembilan merupakan perpanjangan dari pelajaran kedelapan. Ya, lebih baik mengikuti praktik terbaik, tetapi memaksakan diri menaati aturan juga bisa menghasilkan kode yang sulit dibaca. Jadi, setiap aturan bisa memiliki pengecualian. Jika cara Anda menyelesaikan masalah lebih praktis, mudah dibaca, dan mudah dipahami, maka lebih baik menyimpang dari praktik terbaik yang sudah mapan. 

#10 Kesalahan tidak boleh berlalu tanpa suara 

Kesalahan yang sunyi adalah saat program mengembalikan kode kesalahan atau None alih-alih melempar pengecualian. Lebih baik program mogok daripada kesalahannya dibungkam dan tetap berjalan. Dalam jangka panjang, membungkam kesalahan dapat menimbulkan bug dalam program Anda yang jauh lebih sulit diatasi. 

#11 Kecuali dibungkam secara eksplisit

Pelajaran kesebelas merupakan perpanjangan dari pelajaran kesepuluh. Ada beberapa kasus di mana Anda mungkin ingin mengabaikan kesalahan yang disebabkan oleh program Anda. Dalam kasus seperti itu, praktik terbaik adalah membungkam kesalahan tersebut secara eksplisit di dalam kode Anda. 

#12 Saat menghadapi ambiguitas, tolak godaan untuk menebak

Komputer hanya melakukan apa yang kita perintahkan: jika kode Anda tidak berperilaku seperti yang Anda inginkan, itu karena ia melakukan apa yang Anda perintahkan. Mencoba memperbaiki perilaku dengan membabi buta menjajal berbagai solusi sampai salah satunya berhasil adalah strategi yang buruk—Anda bisa jadi menutupi masalah alih-alih menyelesaikannya. Tahan godaan itu. Alih-alih, pikirkan logika masalahnya dan terapkan pemikiran kritis untuk menemukan solusi yang tepat. 

#13 Harus ada satu—dan sebaiknya hanya satu—cara yang jelas untuk melakukannya 

Moto bahasa pemrograman Perl adalah: “Ada lebih dari satu cara untuk melakukannya!” Terlalu banyak opsi sering kali mengarah pada beban pilihan. Skenario serupa terjadi saat ada beberapa cara menulis kode untuk mencapai tujuan yang sama. Anda memang lebih fleksibel dalam cara menulis kode, tetapi kini Anda harus mempelajari semua kemungkinan cara kode itu bisa ditulis agar bisa membacanya: pekerjaan ekstra untuk mempelajari semua skenario tidak perlu. 

#14 Meskipun cara itu mungkin tidak langsung jelas kecuali Anda orang Belanda

Aforisme ini menunjukkan selera humor Tim Peters: Guido van Rossum, pencipta bahasa pemrograman Python dan Benevolent Dictator For Life (BDFL) untuk Python, adalah orang Belanda. Ini adalah lelucon untuk mengingatkan kita bahwa mampu memahami dan mengingat aturan bahasa Python itu sulit bagi semua orang kecuali penciptanya. 

#15 Sekarang lebih baik daripada tidak pernah

Aforisme ini memberi tahu kita bahwa kode yang terjebak dalam loop tak berujung atau hang lebih buruk daripada kode yang tidak demikian. 

#16 Meskipun tidak pernah sering kali lebih baik daripada saat ini juga

Melanjutkan dari pelajaran keenam belas: lebih baik menunggu program Anda selesai dieksekusi daripada menghentikannya terlalu dini dan mendapatkan hasil yang salah. 

#17 Jika implementasinya sulit dijelaskan, itu ide yang buruk

Memahami implementasi Anda sendiri saja tidak cukup—“Saya tahu maksud saya” tidak memadai. Pemrograman adalah aktivitas tim, dan jika Anda tidak mampu menjelaskan implementasi kepada rekan setim, sangat mungkin Anda membuat solusinya terlalu rumit. 

#18 Jika implementasinya mudah dijelaskan, itu mungkin ide yang baik

Namun, kode yang mudah dijelaskan tidak serta-merta berarti itu bukan kode buruk—itu hanya berarti mudah dijelaskan. Anda mungkin masih memiliki kode yang buruk, tetapi fakta bahwa mudah dijelaskan menunjukkan Anda berada di jalur yang benar. 

#19 Namespace adalah ide yang luar biasa—mari kita buat lebih banyak lagi!

Namespace adalah abstraksi yang digunakan dalam Python untuk mengorganisasi nama yang ditetapkan ke objek dalam sebuah program. Ketika dihadapkan pada namespace dan cakupan tertentu, Python dapat menentukan objek apa yang Anda maksud saat memanggil nama simbolik. Intinya, aforisme ini mengatakan bahwa cara Python mengatur nama simbolik di balik layar itu sungguh keren. 

Kesimpulan 

Dalam artikel ini, kami menyajikan interpretasi kami tentang Zen of Python, pedoman yang diciptakan untuk mendorong pemrogram Python menulis kode yang bersih dan mudah dibaca. Sementara sebagian orang memandang Zen of Python sebagai cetak biru utama untuk menulis kode tanpa cela, sebagian lainnya tidak terlalu serius menanggapinya.  Kami menyarankan Anda mencoba menerapkan prinsip-prinsip ini pada kode Anda sendiri untuk melihat langsung bagaimana prinsip tersebut dapat meningkatkan pekerjaan Anda.  Jika Anda ingin mempelajari lebih lanjut tentang menulis kode yang teroptimasi, lihat Writing Efficient Python Code dari DataCamp.