Catatan Pribadi Mengenai Penulisan Kode yang Maintainable

Prajna Prasetya
3 min readApr 7, 2022

--

Hello, world!

https://memegenerator.net/img/instances/64922622/what-if-i-told-you-i-forgot-how-my-code-works-after-lunch.jpg

Pernahkah kita mengalami kejadian setelah selesai menulis kode, kemudian kita tidak sentuh setelah beberapa lama, kemudian kita sudah lupa cara kerja kode tersebut? Ditambah lagi kode yang kita buat sangat tidak rapi dan nama variabel dan fungsi sangat aneh, sehingga kita malas membaca dan lebih memilih untuk membuat kode yang baru saja dibandingkan memperbaiki kode yang sudah kita tulis sebelumnya? Atau kejadian lainnya, ketika kita ingin mengubah satu baris kode kita, tapi ternyata dengan perubahan satu baris tersebut, mengharuskan kita mengubah banyak baris kode lainnya?

Mungkin, itu adalah tanda kode kita kurang maintainable. Oleh karena itu, kita perlu belajar melakukan clean code.

Definisi

Secara gamblang, clean code artinya kode yang bersih. Sebersih apa sebuah kode? Tidak ada yang pasti dalam mendefinisikannya. Namun, tentunya ada standar berdasarkan konvensi yang kita sepakati bersama sebagai aturan clean code.

Dari mata kuliah pemrograman lanjut (mata kuliah yang saya ambil sekitar satu tahun lalu), hal yang menarik adalah software development yang dapat dikembangkan secara berkelanjutan mirip dengan craftmanship. Hal yang penting dalam pengembangan bukan tentang hal baru, tapi bagaimana profesionalisme dan etika untuk berkolaborasi dapat dituangkan dalam penulisan kode, sehingga kode tersebut dapat dikembangkan oleh orang lain, dan juga mudah untuk dipahami.

Clean Code

Apakah kita perlu membersihkan kode kita agar dapat disebut clean? Perlu diingat bahwa setiap orang memiliki sudut pandang yang berbeda, bahkan dalam memandang kerapihan dari sebuah kode. Oleh karena itu, menurut saya agar kode tersebut dapat dibilang “bersih”, harus ada konvensi yang kita pegang bersama.

Setidaknya, untuk membuat kode yang dapat dipahami oleh orang lain, dan dapat dipahami di kemudian hari, ada beberapa hal yang bisa kita pegang:

  • Penulisan nama variabel dan fungsi yang bermakna

Jika kita menulis variabel, mungkin kita sering hanya menggunakan satu huruf, kemudian kita beri komentar seperti berikut:

int n; // banyak mata kuliah

Akan tetapi, alangkah baiknya apabila kita dapat memperjelasnya, mulai dari nama variabelnya!

int banyakMataKuliah;

Meskipun lebih panjang, akan tetapi orang yang membaca kodenya tidak perlu dua kali untuk mengetahui definisi variabel n. Hal yang sama berlaku dalam penulisan nama fungsi, bahkan terdapat konvensi yang menganjurkan bahwa fungsi harus dimulai dengan kata kerja, sebagai contoh: getMataKuliah, updateMaterial, dan lain sebagainya.

  • Buat fungsi yang hanya melakukan satu hal

Fungsi yang lebih kecil menurut saya akan lebih mudah untuk dibaca. Terutama dengan membuat fungsi yang hanya melakukan satu hal, hasil dari fungsi lebih terlihat deterministik dibandingkan dengan fungsi yang panjang dan banyak melakukan tugas. Saya ingat salah satu hal yang menurut saya cukup ekstrim dari dosen saya waktu itu, mungkin saja ketika banyak suatu fungsi sudah melebihi satu layar, maka fungsi tersebut perlu dipecah. Pesan moral yang didapat tentunya adalah sangat disarankan untuk melakukan fungsi yang hanya melakukan satu hal.

  • “Don’t comment bad code — rewrite it” (Brian W. Kernighan and P. J. Plaugher”

Dulu saya pernah bertemu dengan kode yang saya bilang memiliki excessive comment, dengan harapan komentar tersebut dapat membantu menjelaskan kode. Namun, saya sebagai pembaca dari kode tersebut merasa sebetulnya komentar tersebut tidak perlu. Dengan kode yang bagus, kita mungkin saja tidak memerlukan komentar. Nama yang intuitif yang dapat menjelaskan intensi dari programmer sangat lebih baik dibandingkan banyak komentar untuk menjelaskan kode yang rumit.

  • Beri pesan yang jelas jika terjadi error

Ketika terjadi error, kita perlu memberi pesan yang jelas mengapa error tersebut terjadi. Banyak bahasa pemrograman memiliki fungsi untuk menangani error dengan exception. Hal ini dapat dilakukan, dan bisa disepakati bersama dengan tim.

Contoh kode yang ada di proyek PPL kami. Terlihat bahwa nama fungsi dan variabel cukup verbose dan memiliki makna tertentu dibandingkan komentar.

Penutup

Menurut saya, pada akhirnya ini hanya sebagian kecil dari banyak konvensi lain di luar sana. Dengan pengalaman dan jam terbang, akan timbul kebiasaan tersendiri untuk mengetahui apakah kode yang kita buat dapat di-maintain atau tidak oleh orang lain. Karena pada dunia nyata, people come and go dari perusahaan, dan kode yang mereka buat mungkin saja diperlukan untuk dikembangkan lebih lanjut. Oleh karena itu, membuat kode yang clean sangat penting agar dapat dikembangkan oleh orang lain.

Sekian yang dapat saya sampaikan, terima kasih sudah membaca, semoga bermanfaat 😺.

Referensi

--

--