Panduan Gaya Google di C ++. Bagian 1

Bagian 1. Pendahuluan
...
Bagian 8. Penamaan
Bagian 9. Komentar
...


Saat menulis kode, kita semua menggunakan aturan desain kode. Terkadang aturan mereka sendiri ditemukan, dalam kasus lain, panduan gaya yang sudah jadi digunakan. Meskipun semua programmer C ++ membaca dalam bahasa Inggris lebih mudah daripada dalam bahasa asli mereka, itu lebih menyenangkan untuk memiliki manual dalam yang terakhir.
Artikel ini adalah terjemahan dari bagian panduan gaya Google di C ++ ke bahasa Rusia.
Artikel asli (garpu pada github), terjemahan yang diperbarui .
Ini adalah bagian pengantar dari panduan ini, yang membahas pertanyaan umum “Mengapa?”
Selain itu, setelah terjemahan akan ada beberapa jawaban untuk pertanyaan yang mungkin.

Entri

C ++ adalah salah satu bahasa pemrograman utama yang digunakan dalam proyek-proyek Google open-source. Diketahui bahwa C ++ adalah bahasa yang sangat kuat. Namun, ini adalah bahasa yang kompleks dan, jika digunakan secara tidak benar, dapat menjadi sarang bug, membuatnya sulit untuk membaca dan memelihara kode.

Tujuan dari panduan ini adalah untuk mengelola kompleksitas kode dengan menjelaskan secara terperinci berapa nilainya (atau tidak sepadan) untuk menulis kode C ++. Aturan-aturan panduan ini akan menyederhanakan manajemen kode dan meningkatkan kinerja pembuat enkode.

Gaya - konvensi diikuti oleh kode C ++. Gaya lebih dari sekadar memformat file dengan kode.

Sebagian besar proyek sumber terbuka yang dikembangkan oleh Google mengikuti panduan ini.

Catatan: panduan ini bukan tutorial C ++: diasumsikan bahwa Anda terbiasa dengan bahasa tersebut.

Tujuan Panduan Gaya

Mengapa dokumen ini dibutuhkan?

Ada beberapa tujuan utama dari dokumen ini, internal Why , yang mendasari aturan individu. Dengan menggunakan tujuan-tujuan ini, Anda dapat menghindari diskusi panjang: mengapa aturan itu dan mengapa mereka harus diikuti. Jika Anda memahami tujuan setiap aturan, maka lebih mudah bagi Anda untuk menyetujui atau menolaknya, untuk mengevaluasi alternatif saat mengubah aturan untuk diri sendiri.

Tujuan manajemen adalah sebagai berikut:

• Aturan harus sepadan dengan perubahannya.
  
  
  • Manfaat menggunakan gaya tunggal harus melebihi ketidakpuasan para insinyur dalam mengingat dan menggunakan aturan.
  • Keuntungan dievaluasi dibandingkan dengan basis kode tanpa penerapan aturan, jadi jika orang-orang Anda masih tidak akan menerapkan aturan, maka manfaatnya akan sangat kecil.
  • Prinsip ini menjelaskan mengapa beberapa aturan tidak ada: misalnya, goto melanggar banyak prinsip, tetapi secara praktis tidak digunakan, oleh karena itu Panduan ini tidak menjelaskannya.
• Dioptimalkan untuk membaca, bukan untuk menulis
  
  
  • Basis kode kami (dan sebagian besar komponen individu darinya) akan digunakan untuk waktu yang lama. Oleh karena itu, secara signifikan lebih banyak waktu akan dihabiskan untuk membaca kode ini daripada menulis.
  • Kami jelas peduli bahwa teknisi kami memiliki lego untuk membaca, memelihara, kode debug. "Tinggalkan kode debug / logging" adalah salah satu konsekuensinya: ketika sepotong kode bekerja "aneh" (misalnya, ketika mentransfer kepemilikan pointer), keberadaan petunjuk teks bisa sangat berguna ( std :: unique_ptr jelas menunjukkan transfer kepemilikan).
• Tulis kode yang mirip dengan yang sudah ada
  
  Menggunakan satu gaya pada basis kode memungkinkan Anda untuk beralih ke masalah lain yang lebih penting.
  
  Juga, satu gaya mempromosikan otomatisasi. Dan, tentu saja, format otomatis kode (atau pelurusan #include ) berfungsi dengan benar jika memenuhi persyaratan utilitas. Dalam kasus lain, hanya satu (yang paling tepat) digunakan dari seperangkat aturan, dan beberapa fleksibilitas dalam menggunakan aturan memungkinkan orang untuk berdebat lebih sedikit.
• Tulis kode yang mirip dengan yang digunakan dalam komunitas C ++ (jika mungkin)
  
  Konsistensi kode kami dengan kode C ++ organisasi dan komunitas lain sangat berguna. Jika fitur standar C ++ atau idiom bahasa yang diterima membuat program menulis lebih mudah, ini adalah kesempatan untuk menggunakannya. Namun, kadang-kadang standar dan idiom tidak cocok untuk tugas itu. Dalam kasus ini (seperti dijelaskan di bawah) masuk akal untuk membatasi atau melarang penggunaan beberapa fitur standar. Dalam beberapa kasus, solusi Anda dibuat, tetapi kadang-kadang pustaka eksternal digunakan (bukan pustaka C ++ standar) dan menulis ulang dengan standar Anda sendiri terlalu mahal.
• Hindari struktur yang tidak terduga atau berbahaya.
  
  C ++ memiliki pendekatan yang tidak jelas dan bahkan berbahaya. Beberapa gaya pengkodean membatasi penggunaannya, seperti penggunaannya membawa risiko besar untuk kebenaran kode.
• Hindari Konstruksi Yang Rata-Rata Programmer C ++ Mempertimbangkan Untuk Menjadi Musuh dan Sulit Didukung
  
  Di C ++, ada fitur yang umumnya tidak diterima karena kompleksitas kode.
  Namun, dalam kode yang sering digunakan, penggunaan konstruksi licik lebih dibenarkan karena penggunaan berulang, serta bagian baru dari kode akan menjadi lebih jelas.
  
  Jika ragu, berkonsultasilah dengan pemimpin proyek.
  
  Ini sangat penting untuk basis kode kami, karena pemilik kode dan tim dukungan berubah seiring waktu: bahkan jika semua orang memahami kode sekarang, banyak hal dapat berubah dalam beberapa tahun.
• Pertimbangkan skala kodenya
  
  Dengan basis kode lebih dari 100 juta baris dan ribuan insinyur, kesalahan dan penyederhanaan bisa mahal. Sebagai contoh, penting untuk menghindari membuang sampah sembarangan namespace global: tabrakan nama sangat sulit untuk dihindari dalam basis kode besar jika semuanya dideklarasikan dalam namespace global.
• Optimalkan sesuai kebutuhan
  
  Optimasi kinerja terkadang lebih penting daripada mengikuti aturan dalam pengkodean.

Maksud dari dokumen ini adalah untuk memberikan pedoman yang paling dimengerti dengan batasan yang masuk akal. Seperti biasa, tidak ada yang membatalkan akal sehat. Dengan spesifikasi ini, kami ingin membuat konvensi untuk seluruh komunitas Google di C ++, tidak hanya untuk tim individu atau orang. Jadilah skeptis terhadap desain yang licik atau tidak biasa: kurangnya batasan tidak selalu memiliki resolusi. Dan jika Anda tidak dapat memutuskan sendiri, tanyakan kepada bos.

Versi C ++

Sekarang kode harus sesuai dengan C ++ 17, mis. Fitur C ++ 2x tidak diinginkan. Di masa mendatang, manual akan disesuaikan untuk versi C ++ yang lebih baru.

Jangan gunakan ekstensi khusus .

Pertimbangkan kompatibilitas dengan lingkungan lain jika Anda bermaksud menggunakan C ++ 14 dan C ++ 17 di proyek Anda.

Catatan: Tautan dapat mengarah ke bagian-bagian manual yang belum diterjemahkan.

Beberapa jawaban / komentar:

- Mengapa pindah?

Secara pribadi, saya lebih nyaman dengan kepemimpinan Rusia. Lebih baik mendiskusikan perubahan dalam panduan gaya dengan teks Rusia.

- Kenapa google? Apakah ada lebih banyak (atau kurang) yang populer ...?

Perusahaan ini cukup terkenal, kepemimpinannya tidak terlalu besar (dapat diterjemahkan tanpa usaha oleh satu orang), memenuhi fungsi yang diperlukan - panduan ini bergaya

- Tapi manual Google menyatakan penggunaan usang (...), penolakan berguna (...)! Mengapa

Seperti yang saya pahami, dokumen ini adalah proposal. Anda akan menggunakan sesuatu, mengubah sesuatu - ini diizinkan. Kepemimpinan adalah fondasi yang baik.