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

2D Shadows pake XNA

Dari blognya Catalin Zima…

Ada calon tutorial yang nampaknya menarik, tentang 2D shadow menggunakan XNA. :D
Screenshotnya:

Kita tunggu saja tutorialnya :D Cheers…

FAIL : wrong indices creates pasupati

Terrain triangle strip indices goes wrong… -.-

Kinda nice though… :D

Ebook ShaderX gratis

Saya lupa udah pernah ngasih link ini ato belum…
isinya ada dua buku pertama seri ShaderX dalam bentuk pdf, dan gratis! :D

Trus ada satu lagi, D3DBook, buku online gratis tentang vertex, geometry, dan pixel shader.

Lumayan buat yang mau belajar shader, mengurangi ketinggalan dari orang luar :p

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

FPS tidak relevan terhadap performance

Dari sini.

Cara untuk mengetahui performa adalah dengan mengukurnya, tapi sayang banyak paper yang mengukur dengan buruk. Contoh paling umum adalah mengukur dengan satuan FPS / Frame Per Second seperti pada paper ini.

FPS is useless.
Gamer mungkin senang dengan FPS, dan benchmark komputer umumnya menampilkan FPS, tapi game developer berbicara dalam milisecond. Kenapa? Karena secara definisi, frame per second itu mencakup semua hal yang terjadi dalam frame, bahkan hal-hal yang bukan bagian utama dari teknik rendering.
Pada contoh paper diatas, SSDO adalah teknik post processing, dan setiap GPU butuh buffer clear dan main scene rendering adalah tidak relevan. Dan karena terjadi pada satu frame yang sama, sehingga tidak bisa diketahui berapa FPS biaya proses-proses tersebut.
Contohnya mereka bilang bahwa ada overhead 2,4% pada SSDO vs SSAO, padahal SSDO bisa saja dua kali lebih lambat dari SSAO, tapi proses lain menutupi fakta tersebut.
Misalnya main scene rendering perlu 12ms, SSAO 0,5ms, sehingga total 12,5ms dengan FPS 80. Jika SSDO ternyata 1ms, total jadi 13ms, 77 FPS. Penurunan  framerate hanya 4% walau sebenarnya cost SSDO dua kali lipat SSAO.

FPS tidak bisa menunjukkan apa yang mahal dan tidak.
Jika kita menjalankan game dengan 20 FPS dan menambah proses 1ms, framerate menjadi 19,4 FPS, penurunan yang terlihat tidak signifikan. Namun jika kita menjalankan game 100 FPS dan menambahkan tepat 1ms yang sama, framerate turun menjadi 90,9 FPS, sebuah penurunan yang lebih besar baik dari angka FPS atau dengan persentase.

FPS tidak valid untuk dirata-ratakan.
Jika kita merender tiga frame dalam 4ms, 4ms, dan 100ms, kita dapat rata-rata FPS :
(1000/4 + 1000/4 + 1000 / 100) / 3 = 170 FPS.
Sedangkan jika merender dalam 10ms, 10ms, dan 10ms kita akan mendapat rata-rata FPS :
(1000/10 + 1000/10 + 1000/10) / 3 = 100 FPS.
Proses render kedua, selain selesai dalam 30ms (dibanding 108ms), namun juga lebih stabil, namun mendapat rata-rata FPS jauh lebih rendah.

Verdict : STOP USING FPS as performance measurement. Use miliseconds instead. D:

*SSDO = Screen Space Directional Occlusion
*SSAO = Screen Space Ambient Occlusion

New Features of CryEngine 3 and Unreal Engine 3

Untuk berita pertama (sumbernya dari sini), baru-baru ini Crytek merilis presentasi detail tentang CryEngine3 dan fitur-fitur barunya (dari Triangle Game Conference) :

1. 32/64 bit, WinXP/Vista, DX9/10, Multi CPU/GPU
2. WYSIWYP (what you see is what you play)
3. Resource Compiler (source asset -> platform spesific)
4. Direct light (shadow mapping)
5. Indirect light : SSAO (screen space ambient occlusion)
6. No precomputed lighting
7. Übershader

Jangan tanya detailnya, saya baca presentasinya aja ga ngerti… T_T (banyak istilah asing, kayak GBuffer,, apaan tuh…). Kalau tertarik, bisa baca-baca paper dari Crytek yang lain di situs mereka.

Berita kedua tentang fitur-fitur baru Unreal Engine yang dirilis di GDC 2009 yang lalu. Intinya UE3 menyediakan fitur-fitur untuk mempermudah membuat game, termasuk game online. Beberapa fiturnya adalah sebagai berikut :

1. Unreal Lightmass : global illumination solver
2. Unreal Content Browser : viewer dan manager asset untuk game
3. Unreal Master Control Program : service-oriented architecture untuk membangun fasilitas online dalam game

Sekian dulu. Ada yang tertarik membuat engine seperti dua yang diatas? :P

Cheers… :D