Pertanyaan Elemen paling penting dalam standar pengkodean C ++ ringan [tertutup]


Saya telah terlibat dalam mengembangkan standar pengkodean yang cukup rumit. Pengalaman saya sendiri adalah bahwa sulit untuk menegakkan jika Anda tidak memiliki proses yang tepat untuk mempertahankannya dan strategi untuk menjunjungnya.

Sekarang saya bekerja, dan memimpin, suatu lingkungan yang bahkan lebih kecil kemungkinannya untuk memiliki proses dan strategi tindak lanjut dalam waktu yang cukup lama. Masih saya ingin menegakkan beberapa tingkat kode terhormat minimum. Jadi saya pikir saya akan mendapatkan saran yang bagus di sini, dan kami mungkin bersama-sama menghasilkan bagian ringan yang wajar dari praktik standar pengkodean yang paling penting bagi orang lain untuk digunakan sebagai referensi.

Jadi, untuk menekankan esensi di sini:

  Elemen apa dari standar pengkodean C ++ yang paling penting untuk dijunjung?

  • Aturan menjawab / voting

    • 1 kandidat per jawaban, sebaiknya dengan a singkat motivasi.

    • Menolak kandidat yang berfokus pada pedoman pemformatan gaya dan subjektif. Ini bukan untuk menunjukkan mereka sebagai tidak penting, hanya saja mereka kurang relevan dalam konteks ini.

    • Menolak kandidat yang berfokus pada cara memberi komentar / kode dokumen. Ini adalah subjek yang lebih besar yang bahkan mungkin layak mendapatkan posnya sendiri.

    • Beri suara kandidat yang jelas memfasilitasi kode yang lebih aman, yang meminimalkan risiko bug misterius, yang meningkatkan pemeliharaan, dll.

    • Jangan berikan suara Anda ke arah mana pun pada kandidat yang tidak Anda ketahui. Bahkan jika mereka terdengar masuk akal dan cerdas, atau sebaliknya "sesuatu yang pasti tidak akan digunakan siapa pun", suara Anda harus didasarkan pada pemahaman dan pengalaman yang jelas.


31


asal


Jawaban:


Lebih suka RAII.

Auto STL (dan bersama dalam meningkatkan & C + + 0x) pointer dapat membantu.


68



Menggunakan const pengidentifikasi secara default. Mereka memberikan jaminan bagi pembaca / pengelola, dan jauh lebih mudah untuk membangun daripada menyisipkan sesudahnya.

Baik variabel dan metode anggota akan dinyatakan const, serta argumen fungsi. const member member memberlakukan penggunaan yang tepat dari daftar initializer.

Efek samping dari aturan ini: hindari metode dengan efek samping.


58



Gunakan gips C ++ sebagai ganti C cast

menggunakan:

  • static_cast
  • const_cast
  • reinterpret_cast
  • dynamic_cast

tetapi tidak pernah menggunakan cast C-style.

Cara ini dengan jelas memfasilitasi kode yang lebih aman, yang meminimalkan risiko bug yang membingungkan, yang meningkatkan pemeliharaan, dll.

Setiap pemain memiliki kekuatan terbatas. Misalnya, jika Anda ingin menghapus konst (karena alasan apa pun), const_cast tidak akan mengubah jenis pada saat yang sama (yang bisa menjadi bug sulit ditemukan).

Juga, ini memungkinkan pengkaji untuk mencari mereka dan kemudian, pembuat kode untuk membenarkan mereka jika diperlukan.


48



Gunakan referensi sebagai ganti pointer jika memungkinkan. Ini mencegah pemeriksaan NULL defensif konstan.


40



Pastikan bahwa tingkat peringatan kompiler Anda disetel cukup tinggi (/ Wall sebaiknya) sehingga akan menangkap kesalahan konyol seperti:

if (p = 0)

ketika kamu benar-benar bermaksud

if (p == 0)

sehingga Anda tidak perlu menggunakan trik yang lebih suram seperti:

if (0 == p)

yang menurunkan keterbacaan kode Anda.


36



Gunakan vektor dan string, bukan array C-style dan char *

Menggunakan std :: vector kapan pun Anda perlu membuat buffer data, meskipun ukurannya sudah ditetapkan.

Menggunakan std :: string kapan pun Anda perlu memiliki string.

Bagaimana ini jelas memfasilitasi kode yang lebih aman, yang meminimalkan risiko bug misterius, yang meningkatkan pemeliharaan, dll?

std :: vector: Pengguna dari sebuah vektor selalu dapat menemukan ukurannya, dan vektor dapat diubah ukurannya jika diperlukan. Ia bahkan dapat diberikan (melalui notasi (& (myVector [0])) ke C API. Tentu saja, vektor akan bersih setelahnya.

std :: string: Hampir alasan yang sama di atas. Dan fakta itu akan selalu diinisialisasi dengan benar, bahwa itu tidak dapat dibanjiri, bahwa ia akan menangani modifikasi dengan anggun, seperti penggabungan, penugasan, dll, dan dengan cara alami (menggunakan operator bukannya fungsi)


34



Pertahankan fungsi ke ukuran yang wajar. Secara pribadi, saya suka menyimpan fungsi di bawah 25 baris. Keterbacaan ditingkatkan ketika Anda dapat mengambil fungsi sebagai unit daripada harus memindai ke atas dan ke bawah mencoba untuk mencari tahu cara kerjanya. Jika Anda harus menggulir untuk membacanya, itu membuat masalah menjadi lebih buruk.


32



menegaskan semua asumsi, termasuk asumsi sementara, seperti perilaku yang tidak dilaksanakan. menegaskan fungsi masuk dan keluar kondisi jika tidak trivial. menegaskan semua negara perantara trivial. program Anda tidak boleh macet tanpa penegasan yang gagal terlebih dahulu. Anda dapat menyesuaikan mekanisme menegaskan Anda untuk mengabaikan kejadian di masa depan.

Gunakan kode penanganan kesalahan untuk kondisi yang Anda harapkan terjadi; gunakan pernyataan untuk kondisi yang seharusnya tidak pernah terjadi. Penanganan kesalahan biasanya memeriksa data input yang buruk; pernyataan memeriksa bug dalam kode.

Jika kode penanganan kesalahan digunakan untuk mengatasi kondisi anomali, penanganan kesalahan akan memungkinkan program untuk menanggapi kesalahan dengan anggun. Jika pernyataan dipicu karena kondisi anomali, tindakan korektif tidak hanya menangani kesalahan dengan anggun — tindakan korektif adalah mengubah kode sumber program, mengkompilasi ulang, dan merilis versi baru perangkat lunak. Cara yang baik untuk berpikir tentang pernyataan adalah sebagai dokumentasi yang dapat dieksekusi — Anda tidak dapat mengandalkannya untuk membuat kode berfungsi, tetapi mereka dapat mendokumentasikan asumsi lebih aktif daripada komentar bahasa pemrograman dapat [1].

  1. McConnell, Steve. Kode Lengkap, Edisi Kedua. Microsoft Press 2004. Bab 8 - Pemrograman Defensif

31