Bagaimana Menulis Kode yang Bagus

Selama saya berkarir sebagai developer Flash dari taun 2004-an, sudah ribuan baris kode dari puluhan aplikasi Flash yang saya baca. Banyak yang bagus dan gampang dipahami, banyak juga yang njelimet & ruwet mirip pangsit mie. Banyak kasus saya temui waktu saya menginterview pelamar di Trippertlabs dimana pelamar yang portfolionya luar biasa bagus, ternyata kalo nulis kode luar biasa jelek ( kebetulan posisi saya adalah Senior Developer jadi saya selalu kebagian giliran pertama untuk “menyiksa” pelamar 🙂 ).

Untuk keperluan internal Trippertlabs, saya pernah mempublikasikan tulisan berjudul Coding Guidelines for Flash & Flex Developers. Saya pikir ada baiknya kalo artikel itu saya tulis lagi di sini.

Mulai dari yang paling dasar yaitu indentasi.

Indentasi

Indentasi berperan penting dalam presentasi kode. Ada beberapa style yang digunakan yaitu:

  1. K & R Brace Style
    
    function doSomething():void{
        var max:int = 10;
        for(var i:int = 0;i<max;i++){
            ...
        }
    }
    
  2. Extended Brace Style
    
    function doSomething():void
    {
    	var max:int = 10;
    	for (var i:int = 0; i < max; i++)
    	{
    		...
    	}
    }
    
  3. Indented Brace/Whitesmith Style
    
    function doSomething():void
               {
                    var max:int = 10;
                    for (var i:int = 0; i < max; i++)
                        {
                          ...
                        }
               }
    
  4. Other Brace Style
    
    function giveNightmare():void
    {
    	
    var max:int = 10;
    for (var i:int = 0; i < max; i++) 
        {
            ...
        }
    }
    

Anda bisa pilih (a) atau (b) biarpun (b) lebih baik karena sesuai dengan konvensi umum di kalangan developer flash/flex & digunakan oleh Adobe. (c) dan (d) sebaiknya dijauhi kecuali kalo Anda ingin nulis kode yang bisa bikin orang begadang & sakit kepala.

Style manapun yang Anda pilih, (a) atau (b), Anda harus konsisten. Jangan ganti-ganti gaya. Kalo Anda bekerja dalam satu tim, ikuti konvensi yang disepakati bersama & semua anggota tim harus menggunakan style yang sama.

Penamaan

Penamaan yang amburadul biasanya dilakukan oleh koder baru yang masih cupu. Ini bisa dipahami karena pengalaman mereka masih sedikit atau mungkin nggak punya sama sekali. Dalam buku Code Craft : The Practice of Writing Excellent Code disebutkan aturan-aturan dalam penamaan, dua di antaranya yaitu :

Write your code to be read by humans. Easily. The compiler will be able to cope.

Favor clarity over brevity.

Variabel & Function

Waktu membuat variabel & function, pilih nama yang deskriptif. Sering saya lihat nama yang nggak jelas maksudnya apa kecuali kita baca comment & dalam beberapa kasus, lebih mirip password.

Contohnya gini:


//current index
var i:int;
//text before
var txt0:String;
//final text
var txt:String;

function fib():void{
    ...
}


Kode di atas lebih baik kalo ditulis dengan lebih jelas, misalnya :


//current index
var curIdx:int;
//initial text
var initTxt:String;
//final text
var finalTxt:String;

function fibonacci():void{ 
    ... 
}

Khusus untuk nama variabel yang hanya terdiri dari satu huruf, Anda boleh menggunakannya untuk variabel yang bersifat lokal. Contohnya :


function multiplyByFive(a:Number):Number{ 
    return a * 5;  
}

Jangan menggunakannya untuk instance variable. Contoh :


var a:Number = 3;

function multiplyByFive():Number{ 
    return a * 5;  
}

Kapitalisasi

Ada 4 macam skema penamaan variabel, function, dan class yang umum digunakan yaitu:

  1. Camel Case, contoh : someVar, bookTitle
  2. Proper Case, contoh : ApplicationModel, MainView
  3. Uppercase, contoh : ENTER_FRAME, CLICK
  4. Underscore, contoh : book_title, button_mc

Konvensi umum AS3 adalah menggunakan (a) untuk nama variabel dan function, (b) untuk nama class, dan (c) untuk konstanta. (d) banyak digunakan oleh developer yang menulis kode AS2, tapi praktek ini lebih banyak disebabkan oleh script editor bodoh bawaan Flash IDE yang nggak bisa menampilkan code hinting kecuali kalo nama variabel ditambah dengan singkatan tipe data tertentu, misalnya : myClip_mc. Praktek semacam ini udah ditinggalkan oleh developer AS3, apalagi sekarang sudah banyak code/text editor yang jauh lebih pintar daripada editor punya Flash IDE, misalnya FlashDevelop.

Komentar

Komentar adalah bagian kode yang sering diabaikan. Banyak developer yang sama sekali nggak nulis komentar biarpun kodenya rumit, ada yang nulis komentar terlalu panjang, ada juga yang nulis komentar sedikit tapi di bagian yang sebenarnya nggak butuh komentar. Contoh komentar yang nggak perlu :


//increment i
i++

//assign a to temp
temp = a

//call fibonacci
fibonacci()

Self-documenting Code

Untuk menulis komentar yang pas, nggak terlalu banyak/panjang, juga nggak terlalu sedikit ada baiknya kalo kita mulai dari menulis kode yang bisa menjelaskan dirinya sendiri tanpa kita perlu memberi komentar. Di buku Code Craft, teknik ini disebut self-documenting code, caranya adalah, kembali ke penamaan, menggunakan nama yang deskriptif. Contoh :


function onClickUploadButton(e:MouseEvent):void{ ... }

function loadVideoXML():void{ ... }

function onEnterFrame(e:Event):void { .. }

function loaderCompleteListener(e:Event):void{...}

function handleFault(e:FaultEvent):void{ ... }

function loadImage(e:Event = null):void { .. }

Baris terakhir dari contoh di atas adalah kasus spesial dimana sebuah function yang berperan sebagai event handler, bisa juga dieksekusi secara manual jadi kalo kita tambahkan "on" atau "Listener" malah membingungkan. Tiga baris di atasnya adalah skema penamaan event handler yang umum dipakai oleh developer Flash/Flex.

Setelah kita menulis self-documenting code selanjutnya kita cari function mana saja yang perlu kita masukkan ke dalam dokumentasi dan kita tambahkan komentar di sana.

Pencabangan

Pencabangan juga termasuk salah satu bagian kode yang sering bermasalah. Sebenarnya nggak ada aturan baku tentang pencabangan, tapi di sini saya sarankan jika Anda menggunakan if-else berkurung ( nested ) batasi kedalamanya sampai maksimal 3 level. Kalo lebih dari itu, pikirkan cara lain misalnya mengganti if-else dengan switch-case. Saya sendiri nggak begitu suka if-else yang lebih dari 2 level. Memang kelihatannya sepele, tapi kalo kode yang kita buat cukup rumit, kemungkinan besar kita bakal mumet kalo kita kembali utak atik kode lama setelah proyek selesai.

Class Jagoan

Developer yang baru menemukan jalan yang benar setelah tersesat di dunia prosedural ( timeline ) cenderung membuat kelas yang kadang disebut "Super Class" ( nggak ada hubungannya dengan super class di dalam hirarki OOP ). Super Class di sini adalah class yang bisa melakukan semua tugas, mulai inisialisasi, menangani user input, akses database, upload data, dan lain-lain. Class serba bisa. Di sini si developer sebetulnya tetap menulis kode secara prosedural biarpun bentuknya class. Baunya sih OOP, tapi rasanya tetap prosedural.

Untuk proyek kecil, sah-sah saja, nggak masalah. Tapi untuk proyek yang kompleks, praktek ini sebaiknya dihindari dan lebih baik kita buat class yang sesuai dengan konteks permasalahan yang dihadapi. Misalnya, untuk upload data, buat class yang berfungsi untuk upload data saja, nggak perlu menangani user input. Kalo upload dilakukan berdasar user input, buat dua class, satu untuk menghandel user input dan urusan upload, delegasikan ke class lain. Separation of concerns is a good thing.

Oke, sekian tulisan saya. Mudah-mudahan bermanfaat.

Referensi

Also in this category ...


One Comment

  1. thanks ya mas, cukup membantu. saya tunggu yang lebih kompleks lagi (^_^). walaupun bisa baca di as3 documentation. tapi kalo baca yang bahasa indonesia lebih berbeda aja. (^_^)

Comments are closed.