10 Cara untuk Mengelakkan Bugs dalam C ++ - dummies

Fakta yang malang bahawa anda akan menghabiskan lebih banyak masa mencari dan mengeluarkan bug daripada yang anda akan menghabiskan sebenarnya menulis program C ++ anda di tempat pertama. Cadangan di sini boleh membantu anda meminimumkan bilangan kesilapan yang anda masukkan ke dalam program anda untuk membuat pengaturcaraan pengalaman yang lebih menyeronokkan.

Dayakan semua amaran dan mesej ralat

Sintaks C ++ membolehkan banyak pemeriksaan ralat. Apabila pengkompil menemui membina bahawa ia tidak dapat mentafsirkan, ia tidak mempunyai pilihan tetapi untuk mengeluarkan mesej. Ia cuba menyegerakkan semula dengan kod sumber (kadangkala kurang daripada berjaya), tetapi ia tidak akan menghasilkan laksana. Ini memaksa pengaturcara untuk membetulkan semua mesej ralat.

Walau bagaimanapun, apabila C ++ menyeberangi struktur yang dapat difikirkan tetapi strukturnya berbau curang pula, C ++ menghasilkan mesej amaran. Kerana C ++ cukup yakin bahawa ia memahami apa yang anda inginkan, ia berjalan ke depan dan membuat fail boleh laku supaya anda boleh mengabaikan amaran jika anda suka. Malah, jika anda benar-benar tidak mahu diganggu, anda boleh mematikan amaran.

Melumpuhkan atau mengabaikan amaran adalah idea yang luar biasa. Ia agak seperti mencabut cahaya "enjin cek" pada papan pemuka anda kerana ia mengganggu anda. Mengabaikan masalah itu tidak membuatnya hilang.

Mengamalkan gaya pengekodan yang jelas dan konsisten

Menulis kod C ++ anda dalam gaya yang jelas dan konsisten bukan sahaja meningkatkan kebolehbacaan program anda, tetapi juga menyebabkan kesilapan pengekodan yang kurang. Ini keadaan yang agak mengejutkan akibat dari fakta bahawa otak kita hanya mempunyai jumlah kuasa pengkomputeran terhad.

Apabila anda membaca kod yang bersih dan kemas dan mengikut gaya yang anda kenal, anda menghabiskan sedikit kuasa otak yang menghuraikan sintaks pernyataan C ++. Ini meninggalkan kuasa CPU otak yang lebih banyak untuk memecahkan apa program yang cuba dilakukan dan bukan bagaimana ia melakukannya.

Gaya pengkodan yang baik membolehkan anda melakukan perkara berikut dengan mudah:

• Membezakan antara nama kelas, nama objek, dan nama fungsi

• Memahami apa kelas, fungsi, atau objek yang digunakan untuk, berdasarkan namanya

• Membezakan simbol preprocessor dari simbol C ++ (iaitu objek #define harus menonjol)

• Mengenalpasti blok kod C ++ pada tahap yang sama (ini adalah hasil indentasi yang konsisten)

Di samping itu, anda perlu menetapkan format standard untuk tajuk modul anda yang memberikan maklumat mengenai fungsi atau kelas dalam setiap modul, pengarang, tarikh, versi, dan sesuatu tentang sejarah pengubahsuaian.

Semua pengaturcara yang terlibat dalam projek tunggal perlu menggunakan gaya pengekodan yang sama. Satu program yang ditulis dalam susunan gaya pengkodan berbeza mengelirukan dan kelihatan tidak profesional.

Komen kod semasa anda menulis

Anda boleh mengelakkan ralat jika anda mengulas kod anda semasa anda menulisnya, bukannya menunggu sehingga semuanya berfungsi dan kemudian kembali dan menambah komen.

Merumuskan komen memaksa anda mengambil stok apa yang anda cuba lakukan. Komen-komen ringkas adalah mencerahkan, baik apabila anda membacanya kemudian dan semasa anda menulisnya. Tulis komen seolah-olah anda bercakap dengan seorang lagi, programmer yang berpengetahuan.

Single-langkah setiap laluan dalam debugger sekurang-kurangnya sekali

Sebagai seorang pengaturcara, anda perlu memahami apa program anda lakukan. Tidak cukup bahawa program menghasilkan nilai yang dijangkakan. Anda perlu memahami semua yang dilakukan oleh program anda. Tidak ada apa-apa yang memberi anda rasa yang lebih baik untuk apa yang berlaku di bawah tudung daripada program melangkah tunggal , melaksanakannya selangkah dengan debugger yang baik (seperti yang disertakan dengan Kod:: Blok).

Selain itu, semasa anda membuat debug program, anda memerlukan bahan mentah untuk mengetahui beberapa tingkah laku yang aneh yang mungkin timbul ketika program berjalan. Tiada apa-apa yang memberikan anda bahan yang lebih baik daripada melangkah tunggal melalui setiap fungsi kerana ia datang ke perkhidmatan.

Akhir sekali, apabila fungsi selesai dan bersedia untuk ditambah ke program, setiap laluan logik perlu dilalui sekurang-kurangnya sekali. Bugs lebih mudah dicari apabila anda mengkaji fungsi dengan sendirinya dan bukannya selepas ia dilemparkan ke dalam periuk dengan seluruh fungsi - pada masa itu, perhatian anda telah beralih kepada cabaran pengaturcaraan yang baru.

Hadkan keterlihatan

Mengehadkan keterlihatan internals kelas ke dunia luar adalah asas kepada pengaturcaraan berorientasikan objek. Kelas harus bertanggungjawab untuk keadaan dalamannya - jika sesuatu mendapat kacau di dalam kelas, maka itu adalah kesalahan programmer kelas. Programmer aplikasi perlu bimbang tentang menyelesaikan masalah di tangan.

Khususnya, keterlihatan yang terhad bermakna ahli data tidak boleh diakses di luar kelas - iaitu, mereka harus ditanda sebagai dilindungi. Di samping itu, fungsi ahli bahawa perisian aplikasi tidak perlu tahu tentang juga harus ditandakan dilindungi. Jangan mendedahkan apa-apa lagi daripada kelas kelas daripada yang diperlukan untuk mendapatkan pekerjaan yang dilakukan.

Menjejaki memori timbunan

Kehilangan trek memori timbunan adalah sumber kesalahan yang paling biasa dalam program yang telah dilepaskan ke medan - dan, pada masa yang sama, masalah paling sukar untuk dikesan dan dialih keluar. (Oleh kerana kelas kesilapan ini sangat sukar untuk dicari dan dialih keluar, ia lazim dalam program yang anda beli.) Anda mungkin perlu menjalankan program selama berjam-jam sebelum masalah mula muncul (bergantung pada seberapa besar kebocoran memori).

Sebagai peraturan umum, pengaturcara sentiasa perlu memperuntukkan dan melepaskan memori tumpukan pada tahap yang sama. "Jika ahli berfungsi MyClass:: create () mengalihkan blok memori tumpukan dan mengembalikannya kepada pemanggil, maka harus ada anggota MyClass:: release () yang mengembalikannya ke timbunan.Khususnya, MyClass:: create () tidak memerlukan fungsi induk untuk melepaskan memori.

Sekiranya mungkin, MyClass perlu mengesan petunjuk memori tersebut sendiri dan memadamkannya dalam pemusnah.

Sifar sifar selepas memadamkan apa yang mereka maksudkan

Pastikan anda menghala keluar petunjuk selepas mereka tidak lagi sah; anda berbuat demikian dengan memberi mereka nilai nullptr. Alasan untuk tindakan ini menjadi jelas dengan pengalaman: Anda boleh terus menggunakan blok ingatan yang telah dikembalikan ke timbunan dan tidak mengetahuinya. Program mungkin berjalan dengan baik 99 peratus masa, menjadikannya sangat sukar untuk mencari 1 persen kes di mana blok mendapat reallocated dan program tidak berfungsi.

Jika anda membatalkan petunjuk yang tidak lagi sah dan anda cuba menggunakannya untuk menyimpan nilai (anda tidak boleh menyimpan apa-apa di atau berhampiran lokasi kosong), program anda akan terganggu dengan serta-merta. Crashing bunyi buruk, tetapi tidak jika ia mendedahkan masalah. Masalahnya ada; ia hanya satu persoalan sama ada anda mendapati atau tidak sebelum memasukkannya ke dalam pengeluaran.

Gunakan pengecualian untuk mengendalikan ralat

Mekanisme pengecualian dalam C ++ direka untuk menangani ralat dengan mudah dan cekap. Secara umum, anda harus membuang penunjuk ralat dan bukan mengembalikan bendera ralat. Kod yang dihasilkan lebih mudah untuk menulis, membaca, dan mengekalkan. Selain itu, pengaturcara lain telah mengharapkannya, dan anda tidak mahu mengecewakan mereka, adakah anda?

Hadkan penggunaan pengecualian anda kepada ralat sebenar. Ia tidak perlu untuk membuang pengecualian dari fungsi yang mengembalikan penunjuk "tidak berfungsi" jika ini adalah sebahagian daripada kehidupan seharian untuk fungsi itu.

Perisytiharkan pemusnah maya

Jangan lupa untuk membuat destructor untuk kelas anda jika pembina memperuntukkan sumber seperti memori heap yang perlu dikembalikan apabila objek mencapai kematian muktamadnya. Setelah mencipta pemusnah, jangan lupa untuk menyatakannya maya.

"Tetapi," kata kamu, "kelas saya tidak mewarisi apa-apa, dan ia tidak subclassed oleh kelas lain. "Ya, tetapi boleh menjadi kelas asas pada masa akan datang. Kecuali anda mempunyai alasan yang baik untuk tidak mengisytiharkan maya destruktor, maka berbuat demikian apabila anda mula-mula membuat kelas.

Sediakan pembekal salinan dan operator tugasan yang dibebankan

Jika kelas anda memerlukan pemusnah, ia pasti memerlukan pembina salinan dan operator tugasan yang terlalu banyak. Jika pembina anda memperuntukkan sumber seperti memori heap, pembina salinan dan pembekal tugas lalai akan melakukan apa-apa tetapi membuat malapetaka dengan menjana pelbagai petunjuk kepada sumber yang sama.

Apabila pemusnah untuk salah satu daripada objek ini dipanggil, ia akan memulihkan aset. Apabila pemusnah untuk salinan yang lain datang, ia akan menimbulkan masalah.