Gaya Penulisan Program

6 Gaya Penulisan Program

Jika Anda telah mengikuti pendekatan yang saya jabarkan diatas, hal ini masih mudah untuk menulis koding yang tidak dapat dibaca dan tidak mudah di-debug dalam C++ seperti dalam C, dan mungkin lebih mudah, mengingat fitur yang lebih hebat yang bahasa C++ sediakan. Untuk projek Nachos, dan secara umum, kita menyarankan Anda disini untuk mengikuti Jika Anda telah mengikuti pendekatan yang saya jabarkan diatas, hal ini masih mudah untuk menulis koding yang tidak dapat dibaca dan tidak mudah di-debug dalam C++ seperti dalam C, dan mungkin lebih mudah, mengingat fitur yang lebih hebat yang bahasa C++ sediakan. Untuk projek Nachos, dan secara umum, kita menyarankan Anda disini untuk mengikuti

1. Kata-kata dalam sebuah nama dipisahkan, seperti SmallTalk-gaya, (yaitu, huruf besar pada permulaan setiap kata baru). Semua nama class dan nama member function dimulai dengan sebuah huruf besar, ke- cuali untuk member function berbentuk getSomething() dan setSome- thing(), dimana Something adalah sebuah data elemen dari suatu class (yaitu, fungsi accessor). Perhatikan bahwa Anda akan menggunakan fungsi tersebut hanya jika data tersebut dibuat terlihat dari luar, tetapi Anda ingin mengharuskan semua akses menuju ke satu fungsi. Hal ini terkadang merupakan ide yang baik, karena Anda dapat pada waktu berikutnya, menentukan untuk mengolah data tersebut daripada hanya menyimpannya saja.

2. Semua fungsi global seharusnya dibuat huruf-besar, kecuali untuk main dan fungsi librari, yang dibuat huruf-kecil karena alasan kebiasaan pem- rograman terdahulu.

3. Meminimalisasi penggunaan variabel global. Jika Anda menyadari penggunaan dari mereka cukup banyak, maka coba kelompokkan kedalam sebuah class atau lemparkan mereka sebagai arguments ke fungsi yang membutuhkan mereka jika Anda dapat melakukannya.

4. Meminimalisasi penggunaan fungsi global (kebalikan dari member func- tions). Jika Anda menulis sebuah fungsi yang beroperasi pada beber- apa objek, pikirkan kemungkinan membuat-nya sebagai sebuah mem- ber function dari objek tersebut.

5. Untuk setiap class atau satu set dari classes yang berhubungan, buatlah file .h dan .cc yang terpisah. File .h berfungsi sebagai antarmuka untuk class tersebut, sedangkan file .cc berfungsi sebagai implementasi (den- gan syarat file .cc menyertakan file .h dalam inclue). Jika penggunaan suatu file .h tertentu membutuhkan file .h yang lain (sebagai contoh., synch.h membutuhkan definisi class dari thread.h), maka Anda seharus- nya menyertakan hal ketergantungan-nya didalam file .h, sehingga user dari class Anda tidak perlu mencari-tahu sendiri dependensi-nya. Un- tuk menjaga dari penyertaan-berulang, lingkupi setiap file .h dengan preprocessor semacam ini:

#ifndef STACK_H #define STACK_H #ifndef STACK_H #define STACK_H

Terkadang, hal ini tidaklah cukup, dan Anda dapat memiliki sebuah depedensi-lingkar. Sebagai contoh, Anda dapat memiliki sebuah file .h yang menggunakan sebuah definisi dari sebuah file .h, tetapi yang juga mendefinisikan sesuatu yang dibutuhkan oleh file .h pertama. Dalam hal ini, Anda perlu melakukan sesuatu sebelumnya. Satu hal yang perlu disadari adalah Anda tidak harus selalu mendefinisikan sebuah class secara menyeluruh sebelum ia digunakan. Jika Anda hanya meng- gunakan sebuah pointer ke class Stack dan tidak mengakses member fuctions atau data dari class tersebut, Adna dapat menulis, sebagai pengganti dari menyertakan stack.h:

class Stack; Ini akan memberi-tahu kompiler tersebut, semua yang ia perlu ketahui

untuk berkomunikasi dengan pointer tersebut. Dalam hal-hal tertentu, kondisi ini tidak dapat dilakukan, dan Anda harus memindahkan be- berapa hal kesana-kemari atau mengubah definisi Anda.

6. Gunakan perintah ASSERT sebebasnya untuk mencek bahwa program Anda telah sesuai berkerja. Sebuah assertion adalah sebuah kondisi yang menyatakan bahwa, jika FALSE maka terdapat bug di program; ASSERT men-test sebuah ekspresi dan membatalkannya jika kondisi tersebut salah. Kita menggunakan ASSERT diatas dalam Stack::Push() untuk mencek apakah stack-nya sudah penuh. Ide-nya adalah menangkap error sesegera mungkin, ketika mereka mudah untuk dideteksi, dari- pada menunggu hingga terdapat gejala yang terlihat oleh user, karena error tersebut (seperti, segmentation fault, setelah memori terbuang oleh sebuah pointer tak-terkendali).

Assertions juga berguna pada permulaan dan akhir dari suatu prose- dur, untuk mencek apakah prosedur tersebut dipanggil dengan argu- ment yang benar dan bahwa prosedur tersebut melakukan apa yang ia seharusnya lakukan. Sebagai contoh, pada permulaan dari List::Insert, Anda dapat memastikan (assert) bahwa item yang di-sisipkan tersebut belumlah berada pada list tersebut, dan pada akhir prosedur, Anda da- pat memastikan bahwa item tersebut sekarang telah berada pada list tersebut.

Jika kecepatan adalah faktor utama, ASSERTs dapat didefinisikan un- tuk melakukan cek dalam versi debug pada program Anda, dan di- buang pada versi produksi. Namum banyak orang tetap mengaktifkan ASSERT meskipun dalam program versi produksi.

7. Tulislah sebuah tes-modul untuk setiap modul didalam program Anda. Banyak pemrogram menganggap bahwa mengetes koding berarti men- jalankan program tersebut secara keseluruhan berdasarkan pada be- berapa contoh masukkan; jika ia tidak keluar mendadak (crash), maka artinya program tersebut berjalan dengan baik, benar? Salah. Anda tidak dapat mengetahui secara pasti berapa banyak koding yang di- jalankan untuk tes tersebut. Mari saya ingatkan Anda untuk menjadi lebih metodologikal tentang testing. Sebelum Anda menaruh sebuah modul baru ke dalam sistem yang lebih besar, pastikan bahwa modul tersebut bekerja sesuai dengan yang diinginkan, dengan cara men-tes- nya sendirian. Jika Anda melakukan ini untuk setiap modul, maka ketika Anda menggabungkan modul-modul tersebut, harapan bahwa semuanya akan berjalan baik tidaklah perlu, karena Anda akan menge- tahui bahwa memang program tersebut akan berjalan baik.

Mungkin yang lebih penting adalah, modul tes menyediakan sebuah ke- sempatan untuk mencari bug sebanyak mungkin dengan mengalokasi konteks dalam lingkup yang lebih kecil. Mana yang lebih mudah: mencari sebuah bug dalam 100 baris program, atau dalam 1000 baris program?