Komentar pada kode adalah tanda kelemahan

Berkebalikan dengan post saya minggu lalu yang menyatakan bahwa komentar dalam source code itu penting, pada post ini saya akan mencoba menjelaskan kenapa kita tidak perlu memberi komentar pada kode kita.

Tepat di hari saya menulis post tentang tips mengomentari kode, saya menemukan post tentang menghilangkan komentar sebagai jalan menuju kejelasan. Kinda random but thanks Google Reader! :D
Quote dari post tersebut:

“The proper use of comments is to compensate for our failure to express
yourself in code. Note that I used the word failure. I meant it.
Comments are always failures.”

Contoh kasus penggunaan komentar dan tidak:

int n=item.count; //number of items
if(n<=5){
     for(int i=0;i<n;i++){
         //check if all items are exist
         if(storage.contain(item[i]){
             print(“item” + i + “valid”);
         }
         else
             return 2;  //error code for item not in storage
     }
}
else
     return 1; // error code for item more than 5

bandingkan dengan kode berikut:

int numberOfItems = item.count;
if(numberOfItems <= MAX_ITEM_NUMBER){
     if(IsAllItemOwned())
         SuccessStoringItems();
     else
         ErrorItemNotExist();
}
else
    ErrorItemExeedLimit();

Tanpa menggunakan komentar, kode pada bagian kedua tetap mudah dimengerti. The code is self-documenting. Nama variabel dan nama fungsi sudah cukup merepresentasikan isi atau tujuan dari potongan kode tersebut. “If you have something important to say, put it in the code.“

Berikut adalah beberapa kelemahan komentar:

1. Komentar tidak berubah seiring perubahan kode. Dengan menggunakan refactoring tools pun komentar tidak dapat diperbaiki secara semantik, kalaupun ada hanya sebatas perbaikan secara syntax.
2. Komentar yang salah lebih parah dari kode sangat kompleks yang tidak memiliki komentar, karena dapat membuat orang bekerja ke arah yang salah.
3. Komentar menjelaskan sesuatu yang absolut, sedangkan variabel yang memilki nama yang baik menjelaskan dengan abstraksi konsep. Ambil contoh nilai 5 pada kode pertama di atas, dan MAX_ITEM_NUMBER, keduanya memiliki maksud yang sama, namun penamaan yang baik memberi abstraksi yang lebih tinggi.l
4. Komentar tidak muncul di stack trace atau fitur debugging lainnya. Ambil contoh jika fungsi Error di atas gagal, kita perlu memeriksa kembali pemanggilan Error mana yang membuat kesalahan dan lain-lain.
5. Membaca komentar itu opsional, membaca kode itu wajib. Kita tidak bisa menjamin semua orang akan membaca komentar kita dengan baik, apalagi kalau komentarnya cukup panjang dan detail.
6. Tambahan dari saya pribadi, komentar menambah jumlah baris kode cukup banyak :D

Hampir setengah minggu saya gunakan untuk mencoba teknik ini, dan cukup membuat kode saya lebih rapi dan lebih mudah dibaca. Rencananya di akhir bulan ini saya akan coba evaluasi teknik mana yang lebih cocok untuk kondisi saya sekarang.

Bagaimana menurut Anda? Pentingkah memberi komentar pada kode Anda? :D

Tips Dalam Mengomentari Source Code Anda

Beberapa minggu terakhir ini saya mengerjakan game dalam tim yang terdiri dari dua programmer, dan beberapa hari yang lalu saya diminta untuk menggantikan tugas seorang programmer di tim yang lebih besar lagi. Hal pertama yang terpikir oleh saya jika membicarakan tim dengan banyak programmer adalah ‘kodenya harus rapi dan well commented‘. Selain agar mudah dibaca jika sewaktu-waktu programmer lain dalam tim butuh untuk menambahkan kode di bagian saya, game yang besar berpeluang untuk berjalan dalam waktu yang cukup lama, sehingga pasti akan banyak penambahan fitur atau setidaknya maintenance.

Hal pertama yang saya lakukan adalah memanfaatkan fitur yang ada pada IDE yang saya gunakaan saat itu (FlashDevelop), yaitu fitur code snippetnya. Komentar saya dibuat sedemikian rupa sehingga tidak memakan banyak baris, namun tetap muncul di pop-up pada IDE (misalnya pada penjelasan fungsi atau parameternya). Sempat juga mencoba documentation generator seperti Ortelius, yang bisa terintegrasi dengan FlashDevelop untuk membuat dokumentasi, namun dibatalkan karena ada ketidakcocokan dengan format komentar yang saya gunakan.

Ada beberapa tips dalam membuat komentar pada source code, yang saya rangkum sebagai berikut:

1. Tulis komentar dengan rapi dan konsisten. Gunakan indentasi yang benar dan seragam, beri komentar untuk setiap properti dan fungsi yang dibuat.
2. Tulis komentar dengan jelas dan mudah dimengerti. Namun jangan menggangap remeh calon pembaca komentar Anda dengan menjelaskan “if(a==5)” dengan “//jika a sama dengan 5″. Asumsikan calon pembaca adalah sesama programmer atau diri Anda sendiri di masa depan.
3. Gunakan tag khusus jika perlu. Tag yang umum digunakan misalnya “//TODO:” atau “//FIXME:”
4. Tulis komentar selagi Anda membuat kode atau mengupdate kode. Karena percayalah, membuat komentar untuk kode yang sudah selesai sama merepotkannya dengan menulis ulang kode-kode itu.
5. Tambahan dari saya, “Tell what do you do, not how do you do“. Artinya beritahu apa pekerjaan Anda, bukan kabar Anda tulis tujuan dari sebuah bagian kode, bukan bagaimana kode tersebut bekerja. Misalnya “hitung c yang merupakan selisih b dan a”, tapi lebih baik “c adalah vektor AB”.

Sekian beberapa tips yang saya tahu, semoga bisa berguna untuk yang membutuhkan.

Cheers… :D

10 Tips untuk Programmer di Industri Game

Dari sini.

10 tips untuk programmer di bidang game development :

1. Learn to be an effective communicator. Sebagian besar programmer di game dev tidak bekerja sendiri, namun dengan tim. Kemungkinan besar programmer harus bekerja dengan programmer lain, orang dari bagian art, atau bahkan dengan pekerja outsource. Komunikasi yang dimaksud bukan hanya jelas dalam mengeluarkan pendapat, namun juga dapat memahami dan melihat dari sudut pandang lawan bicara.
2. Master the basics. Jangan menyepelekan matematika dan logika, karena hal-hal itu akan terus digunakan dalam pekerjaan ini. Tingkatkan kemampuan debugging dengan banyak berlatih. Jika tidak dapat menentukan struktur data yang cocok untuk suatu masalah, kemungkinan kode yang dihasilkan juga tidak akan baik.
3. Code defensively. Selalu membuat kode secara defensif, periksa setiap input untuk fungsi yang dibuat, buat assertion, kembalikan pesan error yang jelas dan berarti, dan beri komentar pada kode yang dibuat.
4. Have passion for games. Bidang ini adalah bidang yang menyenangkan namun sangat berat. Banyak lembur, bug list, feature creep, dan lain-lain. Jangan sampai beban di pekerjaan membuat semangat hilang.
5. Maintain healthy work/life balance. Crunch adalah hal yang biasa ditemui di game development. Seimbangkan hidup di luar pekerjaan dan jaga kesehatan untuk menikmatinya.
6. Ask for help. Jangan malu bertanya atau meminta bantuan pada orang lain. Know what you dont know.
7. Learn multiple languages. C++ itu wajib :D Lalu sebaiknya pelajari bahasa pemrograman lain. Karena dapat memberi pola pikir baru dalam memecahkan sebuah masalah. Disarankan mempelajari suatu bahasa baru setiap tahunnya.
8. Don’t lose sight of the big picture. Dalam sebuah game akan banyak sekali kebutuhan, namun tidak semuanya dapat dipenuhi. Namun tujuannya tetap membuat game terbaik yang bisa dibuat.
9. Learn the code base. Sebagian programmer mengerjakan suatu bagian kecil dari game, AI, UI, Rendering, Physics, atau tools. Sebaiknya programmer dapat memahami secara garis besar bagaimana game secara keseluruhan bekerja, karena setiap bagian yang dibuat akan berinteraksi.
10. Stay current. Pendidikan tidak berhenti saat mulai bekerja. Terus pelajari hal-hal baru, berlatihlah dengan membuat proyek pribadi, ikuti perkembangan industri dengan membaca berita atau mengikuti konferensi seperti GDC.

*diambil dari Game Career Guide 2009.

Cheers :D

Buku gratis : Game Career Guide 2009

Dari sini.
Game Developer Magazine kembali mengeluarkan majalah Game Career Guide, sekarang edisi 2009. Bisa dibaca online di sini, bisa juga didownload di tempat yang sama. GRATIS. :D

Banyak sekali hal penting tentang pekerjaan di bidang Game Development :

1. Tips mencari pekerjaan tanpa pengalaman bekerja
2. Tools-tools yang biasa digunakan dalam game dev
3. 10 tips untuk designer, producer, artist, dan sound
4. Tempat-tempat kuliah game dev
5. Postmortem project mahasiswa game dev
6. 10 Indie games paling berpengaruh
7. Entry level salary report untuk programmer, artist, dan posisi-posisi lain di game dev
8. dan masih banyak lagi :D

Sama sekali ga ada ruginya baca majalah ini.

Cheers… :D

Slide-slide Presentasi GDC 2009

Game Developers Conference 2009 sudah berakhir beberapa minggu yang lalu, tapi baru sekarang saya post tentang GDC 09.
Well, better late than never…

Berikut ini beberapa link tempat download slide-slide presentasi GDC 2009 :

NVIDIA : http://developer.nvidia.com/object/gdc-2009.html
>APEX, D3D11, dan lain-lain. Ada video juga.

ATI : http://developer.amd.com/documentation/presentations/Pages/default.aspx#gdc
>DX10, D3D11, shader, AMD GPU, dan lain-lain.

Intel : http://software.intel.com/en-us/articles/intel-at-gdc/
>berbagai teknologi Intel, dari threading, multicore, larabee, dan lain-lain

Khronos : http://www.khronos.org/library/detail/game-developers-conference-2009-press-kit/
>COLLADA, OPENGL, OPENGL ES, OPENCL, dan produk Khronos lainnya

GDC Vault : http://mygdc.gdconf.com/vault/1337
>isinya banyak sekali, slide bisa didownload gratis tapi untuk nonton video harus punya GDC pass -o-

GDC Tutorials : http://www.gdconf.com/conference/tutorials.html
>ada beberapa tutorial bagus seperti math dan physics

Cheers and enjoy, everyone! :D

Poligon : kurangi atau perbanyak?

Less is more… Or is it?

Pada awal-awal saya tertarik pada computer graphic dan mulai  lihat-lihat gambar baca-baca di artikel sana sini (walau ga ngerti) ada satu hal yang menurut saya kontradiksi.

Di satu pihak, ada golongan orang (kita sebut saja golongan pesimis) yang berusaha mengurangi jumlah poligon pada aplikasi mereka, di lain pihak, ada golongan (kita sebut saja golongan optimis) yang justru ingin memperbanyak jumlah poligon pada aplikasi mereka.

Sebagai contoh, aplikasi terrain rendering (topik tugas akhir saya), algoritma ini dan ini bertujuan mengurangi jumlah poligon pada terrain, sedangkan movie ini, menunjukkan terrain dengan poligon yang sudah dilipatgandakan jumlahnya.

Lalu, kenapa hal ini bisa terjadi? Apakah kedua hal tersebut memang bertolak belakang?