Dedy Purwanto

Melampaui PEP8

18 Apr 2015

Seorang programmer bercerita kepada temannya tentang kode yang dia tulis selama seminggu lebih, tentang seberapa kompleks dan canggihnya algoritma yang dia buat. Lalu dia membuka laptopnya dan menunjukan isi dari salah satu source file, temannya dengan antusias melirik dan mulai scroll perlahan. Tidak ingin kalah "macho", dia dengan pedenya bilang "Kurang spasi nih antara classnya".

Terasa mirisnya? Kalau masih belum jelas: Bayangkan kamu membuat roket yang akan diikutkan di kompetisi internasional, dan ketika mengharapkan kritik konstruktif dari temanmu, dia malah bilang: "harusnya pintu roketnya warna hijau nih"

Dalam komunitas Python, PEP8 dikenal sebagai sekumpulan "aturan" yang mendikte bagaimana sebaiknya kode Python kita ditulis, mulai dari maksimum jumlah karakter disetiap baris, jumlah spasi antara class, function dan imports, sampai dengan gaya penulisan nama class dan variables. Contoh sebagai berikut:

1
2
3
4
5
p=1 # Jelek
p = 1 # Bagus

cetak_dokumen( file,printer ) # Jelek
cetak_dokumen(file, printer) # Bagus

Selama ini PEP8 sudah cukup bisa mengakomodir serta "mendamaikan" berbagai perseteruan dikomunitas Python, setiap kali ada perbedaan gaya penulisan kode antara programmer satu dan yang lain, kita selalu mengembalikannya ke PEP8. Banyak bahasa pemrograman lainnya yang tidak punya paduan resmi seperti PEP8 ini sehingga tidak ada kejelasan dan selalu ada perbedaan antara setiap programmer dan codebase, seperti:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
function a(){
    alert("hello")
}

function b()
{
    alert("hello")
}

function c(){ alert("hello"); }

function d()
    alert("hello")

function e()
    alert("hello")
    alert("world")

Tebak alert yang mana yang akan muncul duluan? Yang terakhir! Yup, karena function yang tidak punya curly brackets hanya akan mengevaluasi 1 statement setelahnya, make alert("world") akan terhitung sebagai global scope yang akan dieksekusi pertama kali.

Jadi kita sudah mengerti betapa gawatnya dunia persilatan tanpa keberadaan PEP8, tidak hanya perbedaan gaya coding yang bakal tergantung oleh lead programmer atau proyeknya (syukur kalau programmernya waras), tapi penggunakan semantik python yang sangat baku ini juga membuat kita terhindar dari bencana seperti diatas.

So far all is good, PEP8 selalu ada untuk menyelamatkan dunia, tapi semakin hari semakin terasa ada yang nggak beres. PEP8 mulai digunakan sebagai tuntunan hukum terhadap semua kode Python. Ketika kita melihat sebuah kode Python, alih-alih mempelajari alur logika atau konsep-konsep Pythonic yang digunakan, kita malah menghitung jumlah karakter, spasi atau juga hal-hal sepele lainnya.

Kenapa ini menjadi masalah penting? karena sindrom "mabuk PEP8" sudah membawa berbagai efek negatif seperti:

Saya adalah salah satu orang yang sempat mabuk PEP8, hingga beberapa waktu yang lalu saya mulai melihat beberapa tulisan dan topik tentang PEP8 bukanlah segalanya, dan membuat kode kita PEP8 compliant tidak otomatis menjadikannya Pythonic, dan pada titik akhir saya menemukan video dari Raymond Hettinger tentang Beyond PEP8, sungguh membuka pengetahuan saya tentang menulis kode yang tidak hanya PEP8-kompatibel, tapi juga Pythonic.

Fokus utama dari video beliau adalah jangan sampai PEP8 membutakan pandangan kita terhadap "gorilla in the code" atau "masalah yang lebih besar". Beliau membuka percakapan dengan memberikan contoh dari Stroop effect:

Stroop effect

Teorinya, lebih sulit untuk menyebutkan warna disetiap kata yang ada digambar tersebut. Warna disini adalah "gorilla in the code" dan kata yang ada digambar tersebut adalah PEP-nya. Seringkali kita terlalu fokus pada kata sehingga tidak bisa menyebutkan warna dengan benar.

Beliau melanjutkan dengan memberi berbagai contoh dimana audiens seringkali tidak bisa melihat masalah utamanya dan lebih terfokus pada PEP8-nya.

Yang lebih impresifnya lagi, beliau menunjukan sebuah kode python yang kira-kira ada 40-50 baris, kemudian beliau mulai mengubahnya menjadi kode yang pythonic, hingga akhirnya jadi kurang dari 10 baris saja, kode awalnya yang terlihat seperti kode python yang normal, ternyata lebih mirip seperti kode Java, lalu diubah menjadi pythonic.

Sayangnya topik yang beliau bawakan harus diakhiri secara terburu-buru karena waktu yang singkat, namun berikut adalah poin-poin penting yang bisa saya ambil:

Saya secara pribadi juga ingin berbagi beberapa konsep simpel yang sering saya gunakan seperti penggunaan nama variabel pendek ketika konteksnya jelas, atau ada penjelasnya seperti:

1
2
3
4
5
6
7
# Contoh 1
for comment in comments:
    print comment.sender

# Contoh 2
for c in comments:
    print c.sender

Disini saya lebih memilih contoh 2 karena meskipun nama variabelnya hanya c, namun ada "penjelasnya" yaitu comments, sehingga kita bisa langsung mengerti tentang konteks si c. Poin lain adalah throwaway variable, yaitu variable yang biasanya diperlukan untuk unpacking namun tidak punya tujuan khusus selain itu:

1
2
3
4
5
6
7
# Contoh 1
name, birth = ('Dedi', 1988)
print name

# Contoh 2
name, _ = ('Dedi', 1988)
print name

Disini saya memilih contoh 2 karena setelah statement pertama, tahun lahir tidak digunakan dimanapun. Pada intinya adalah PEP8 bukan paduan atau "hukum" utama dalam pemrograman python, masih banyak konsep serta paduan lainnya yang harus dimasukan agar implementasi kita bisa disebuh pythonic.





© Dedy Purwanto | Archives