Haruskah tim saya menggunakan beberapa standar pengkodean yang dianggap baik sebagai dasar untuk dirinya sendiri?

Tim R&D yang saya tangani telah memutuskan untuk mengadopsi standar pengkodean. Kami baru saja terbentuk, dan memiliki terlalu sedikit kode dan waktu pengkodean sendiri untuk mendasarkan dokumen standar / konvensi kami pada apa yang telah dikembangkan secara organik dalam tim kami, dan pada contoh yang baik dari kode kami sendiri dll.

Sekarang, kita masing-masing memiliki pengalaman dari tempat kerja masa lalu - meskipun tidak ada dari kita yang mengatakan "mari kita mengadopsi dokumen yang komprehensif di sini yang saya temukan cocok untuk jenis pekerjaan yang kita lakukan di sini" (*). Plus, sebagian dari kita (termasuk saya) hanya memiliki pengalaman dari tempat-tempat tanpa standar pengkodean resmi, atau menulis dalam bahasa yang berbeda di lingkungan yang berbeda (lingkungan produksi rilis mingguan tekanan tinggi sebagai lawan dari pekerjaan pengembangan yang lebih berorientasi pada penelitian)

Jadi, salah satu opsi yang saya pikirkan adalah mengambil dokumen yang relatif terkenal dan terkenal, memotong apa yang tidak kita pedulikan / pedulikan, dan membuat beberapa modifikasi berdasarkan preferensi kita.

Apakah ini praktik umum? Apakah Anda yakin ini ide yang bagus? Jika demikian, apa yang akan menjadi standar pengkodean 'baseline' yang masuk akal (jangan beri tahu saya mana yang terbaik, saya tidak ingin memulai konflik agama di sini; cukup tunjukkan apa yang akan komprehensif atau 'netral' yang cukup untuk membangun di atas .)

Catatan:

• Kami berharap dapat bekerja dengan C, C ++, OpenCL, CUDA, Python.
• Kami adalah tim yang terdiri dari 4 orang + manajer, diperkirakan akan tumbuh sekitar 5-6 dalam satu tahun atau lebih.
• Di perusahaan kami, tim hampir sepenuhnya otonom dan biasanya tidak berinteraksi sama sekali (bahkan tidak dengan menggunakan kode masing-masing - pekerjaan ada di proyek yang sama sekali berbeda); jadi - tidak ada pertimbangan di seluruh perusahaan untuk dibuat.
• Mengenai alat, saat ini yang kita tahu adalah kita akan menggunakan Eclipse , jadi pemformat kodenya akan menjadi salah satu alat setidaknya. Ctrl + Shift + F telah lama menjadi teman saya
• Ketika saya menulis Java, saya telah mengadopsi praktik menempel seketat mungkin ke Java Efektif Bloch . Sekarang, itu bukan standar pengkodean, tetapi Anda bisa memanggil beberapa batu bata, semen dan mortar untuk standar pengkodean. Saya berpikir untuk memasukkan sesuatu seperti itu sebagai bagian dari 'campuran' (mengingat bahwa kita tidak menggunakan Java).
• Maksud saya standar pengkodean dalam arti kata yang lebih luas, misalnya mengadopsi saran yang dibuat dalam jawaban untuk pertanyaan P.SE ini .
• Saya telah menemukan daftar besar dokumen standar pengkodean C ++ ; mungkin saya harus menambang bahwa baseline kami.
• (*) Itu tidak sepenuhnya benar, tetapi saya tidak ingin mempersulit pertanyaan ini dengan terlalu banyak spesifik.

Dengan kata lain, Anda bertanya apakah Anda harus memulai standar pengkodean tim Anda dengan meminjam standar eksternal yang Anda temukan. Itu tidak terdengar seperti orang di tim memiliki pendapat yang sangat kuat (belum) tentang standar apa yang seharusnya.

Jelas, jawabannya adalah ya.

Standar bersumber eksternal lebih unggul daripada tidak sama sekali. Lihatlah jawaban di " https://softwareengineering.stackexchange.com/q/84203/53019 " untuk melihat beberapa keuntungan memiliki standar. Konsistensi dan memiliki dasar untuk berubah dari sangat penting dari sudut pandang Anda.

Lihat juga " Menangani Standar Pengodean di Tempat Kerja (Saya bukan bos) " saat membahas beberapa dinamika tim yang perlu dipertimbangkan tim Anda ketika memilih standar apa yang seharusnya. Tim perlu memiliki standar pengkodean mereka sehingga semua orang dengan sukarela mematuhi batasan yang diberikannya pada cara setiap orang mengkode.

Anda ditautkan dengan pertanyaan ini, tetapi ada baiknya menunjukkan jawaban teratas dan fokusnya pada memahami mengapa persyaratan ada. Jika Anda menggunakan standar eksternal, akan sulit bagi tim Anda untuk memahami dasar di balik semua persyaratan itu. Tetapi jika Anda menerima bahwa mereka ada hanya karena tim Anda memerlukan sesuatu untuk memulai, maka mudah untuk beralih ke mengubah standar eksternal menjadi sesuatu yang bekerja lebih baik untuk tim Anda.

Memiliki standar apa pun memungkinkan Anda mengisi aturan pemformatan yang akan Anda gunakan dengan IDE Anda (Eclipse dalam kasus Anda). " Keuntungan dan Kerugian Reformat Kode Paksa " memberikan manfaat bagi semua orang di tim karena memiliki konsistensi dengan kode yang sedang mereka kerjakan, dan memberi Anda kemampuan untuk memformat ulang cuplikan yang dapat Anda pinjam dari proyek lain. Bonus tambahan menggunakan standar eksternal adalah bahwa ia mungkin sudah diisi sebelumnya di bagian pemformatan kode IDE Anda.

Seseorang di tim kemungkinan akan mengeluh tentang bagian tertentu dari standar dan akan menyalahkan itu pada kenyataan bahwa Anda menggunakan standar eksternal sebagai pangkalan. Mintalah mereka membaca:
- Saya benci salah satu standar pengkodean kami dan itu membuat saya gila, bagaimana memprosesnya?
- Bagaimana Anda mengatasi bias coding Anda sendiri ketika menyerahkan kode lawas?
dan kemudian menyadari bahwa mereka kemungkinan akan mengeluh tentang sesuatu di dalam standar tidak peduli dari mana asalnya. Di seluruh jumlah tim yang telah saya garap, saya belum melihat standar yang disukai semua orang a) dan b) setuju dengan setiap porsi standar. Referensi kembali ke beberapa tautan awal untuk melihat bagaimana menangani masalah tersebut.

Tambahan, Anda bertanya tentang "mana" yang harus Anda gunakan. Saya secara khusus tidak akan menjawab bahwa karena ada jawaban yang berpotensi ditimbulkan oleh perang api yang dipicu oleh opini. Namun, Anda dapat melihat IDE Anda (Eclipse) dan melihat opsi apa yang disediakannya sebagai konfigurasi standar. Saya juga akan mencari sedikit dan melihat apakah ada proyek yang plugin untuk IDE Anda dan memberikan opsi standar tambahan untuk dipilih. Benar atau salah, standar-standar itu sudah dihuni untuk Anda dan dapat menyimpan tim Anda sedikit pekerjaan dalam mengonfigurasinya untuk semua orang.

Saya akan mulai dengan python. Python memiliki pedoman pengkodean yang hampir setiap programmer python tunggal di luar sana mengikuti. Mereka adalah bagian dari dokumentasi resmi yang disebut PEP8 .

C / C ++ adalah kekacauan besar karena alasan historis, tetapi karena python tidak, saya sarankan Anda mengikuti konvensi penamaan python di C / C ++ juga demi konsistensi.

Sekarang untuk C ++ sebenarnya lebih penting untuk menyepakati idiom umum dan memastikan bahwa semua orang memahami gaya C ++ modern yang masuk akal daripada perang pada konvensi penamaan. Anda harus mulai dengan C ++ Standar Pengkodean dan dari sumber daya online pastikan untuk membaca FAQ C ++ .

Anda bahkan tidak dapat mendiskusikan topik ini tanpa membuat perbedaan antara standar pengkodean dan standar gaya pengkodean .

Standar pengkodean adalah seperangkat aturan yang mendefinisikan mekanisme bahasa mana yang diizinkan untuk Anda gunakan, mana yang tidak diizinkan untuk Anda gunakan, dan cara menggunakannya. Dengan kata lain, Anda mendefinisikan subset dari bahasa yang digunakan, dan / atau superset, jika standar pengkodean membahas ekstensi non-standar tertentu.

Standar gaya pengkodean hanya berkaitan dengan masalah kosmetik: di mana menempatkan kawat gigi dan spasi, cara menyebutkan nama pengidentifikasi, cara menempatkan komentar, dll.

Dua hal yang berbeda ini mungkin terletak di dokumen yang sama. Namun, yang paling serius dari standar pengkodean tidak berkaitan dengan gaya - yang saya sarankan di bawah ini tidak. Kemungkinan besar karena gaya pengkodean sangat subyektif dan karenanya menyebabkan banyak gesekan ketika pendapat bertabrakan.

Untuk C / C ++, standar pengkodean dengan reputasi terbaik adalah MISRA . Mereka dirancang utama untuk aplikasi keselamatan / misi-kritis, tetapi karena kunci untuk membuat program lebih aman adalah untuk menghapus dan menghindari bug, standar MISRA berlaku untuk cabang pemrograman mana pun bug yang tidak diinginkan.

Standar dari CERT juga cukup terkenal dan lebih condong ke pemrograman desktop dan keamanan perangkat lunak (daripada keamanan). CERT memiliki standar untuk C, C ++, Java dan Perl, dan standarnya gratis.

Saya akan mulai dengan melihat MISRA dan CERT, daripada beberapa standar garasi acak yang ditemukan di web.

Menggunakan standar yang ada sebagai dasar untuk Anda sendiri memiliki beberapa keunggulan. Kode Anda mungkin akan lebih mirip dengan kode eksternal, membuatnya lebih mudah untuk membaca / mengintegrasikan kode. Selanjutnya, jika Anda memilih standar yang baik, itu akan diperiksa oleh para ahli yang memiliki alasan bagus untuk memutuskan aturan khusus mereka. Selama tidak ada seorang pun di tim Anda yang terikat dengan standar, ada sedikit alasan untuk tidak menggunakan standar yang ada sebagai dasar untuk standar Anda sendiri.

Jika Anda tidak yakin standar pengkodean mana yang akan digunakan, ada beberapa pilihan pertama yang jelas dan ideal. Tanpa urutan tertentu:
1. Standar apa pun yang sudah didukung oleh IDE Anda. Ini mungkin dapat dikonfigurasi.
2. Apapun standar yang digunakan / direkomendasikan oleh penulis kompiler Anda.
3. Apapun standar yang digunakan / direkomendasikan oleh penulis kerangka kerja utama Anda (jika ada).
4. Standar apa pun yang digunakan / direkomendasikan oleh penulis / perancang bahasa pemrograman Anda.
5. Apapun standar yang digunakan / direkomendasikan oleh perusahaan yang sangat besar.

Saya merekomendasikan seseorang dengan keahlian teknis membaca standar apa pun yang Anda gunakan sebagai dasar untuk standar Anda sendiri. Standar yang baik akan sering memiliki pembenaran untuk setiap aturan, yang akan membantu Anda dalam memodifikasi standar yang paling sesuai dengan kebutuhan Anda.

Standar biasanya membantu komunikasi dan pemeliharaan. Menurut pendapat saya, itu harus tunduk pada beberapa memberi dan menerima, terutama dalam tim kecil, dan harus berkembang. Memanggil mereka pedoman dapat membantu :-)

Lihatlah pedoman Google untuk inspirasi.

TIDAK, saya tidak akan repot - saya pikir satu-satunya keuntungan adalah jika tim Anda pindah ke tempat di mana standar itu digunakan juga, yang bukan yang Anda inginkan terjadi :)

Standar hanya ada di sana untuk mendorong kolaborasi yang lebih mudah, jadi jika Anda tahu bahwa #define makro selalu dalam huruf besar, maka ketika Anda melihat pengenal huruf besar dalam kode, Anda akan memiliki ide yang adil sebagai makro. Demikian pula, konvensi penamaan atau konvensi gaya lainnya akan mengingatkan Anda apa yang Anda hadapi.

Saya menemukan standar seperti lokasi dan nama file lebih bermanfaat1 daripada yang kode (setelah semua, kode datang dalam semua bentuk dan ukuran, dan Anda masih harus membacanya) sedangkan tidak mengetahui readme.txt ada di / bin / doc / debug / release / dokumen adalah rasa sakit yang nyata (seperti jalan yang jelek, tapi itu cerita lain).

Saya akan merekomendasikan Anda membuat standar Anda sendiri seiring berjalannya waktu. Dengan begitu, Anda tidak hanya mendapatkan yang Anda sukai, tetapi Anda mendapatkan yang pasti cocok untuk Anda, tim Anda, dan pekerjaan yang Anda lakukan. Jika Anda memutuskan bahwa Anda tidak benar-benar peduli seperti apa perulangan sementara, atau bahwa pernyataan kasus harus di-indentasi dengan cara tertentu, maka Anda baik. Jika Anda memutuskan bahwa operator ++ dilarang, bagus juga. Semua pilihanmu sendiri.

Anda harus membuatnya mudah untuk menemukan dan memperbaruinya, mungkin wiki atau halaman web yang dibuat secara otomatis dari deskripsi teks, tetapi sebaliknya - lakukan saja. Standar memiliki sikap mistis dari beberapa orang yang lebih tertarik mengikuti standar dengan fanatik daripada menulis kode yang baik, jangan seperti mereka - buat standar sendiri yang membantu Anda di mana pun Anda membutuhkannya.