Mengapa Paman Bob menyarankan agar standar pengkodean tidak dituliskan jika Anda dapat menghindarinya?

Ketika saya membaca pertanyaan ini , jawaban yang paling banyak dikutip mengutip Paman Bob tentang standar pengkodean , tetapi saya bingung dengan tip ini:

3. Jangan menuliskannya jika Anda bisa menghindarinya. Alih-alih, biarkan kode menjadi cara standar ditangkap.

Ini memantul di otak saya, tetapi saya tidak dapat menemukan tempat untuk menempel. Jika orang baru bergabung dengan tim, atau mengubah standar pengkodean, tidak bisakah ada kebingungan informasi?

Mengapa saya tidak menulis standar pengkodean?

Ada beberapa alasan.

1. Tidak ada yang membaca dokumentasi.
2. Tidak ada yang mengikuti dokumentasi bahkan jika mereka membacanya.
3. Tidak ada yang memperbarui dokumentasi bahkan jika mereka membacanya dan mengikutinya.
4. Menulis daftar praktik jauh lebih efektif daripada menciptakan budaya.

Standar pengkodean bukan tentang apa yang harus dilakukan orang, tetapi tentang apa yang sebenarnya mereka lakukan. Ketika orang menyimpang dari standar, ini harus diambil dan diubah melalui proses peninjauan kode dan / atau alat otomatis.

Ingat, inti dari standar pengkodean adalah untuk membuat hidup kita lebih mudah. Mereka adalah jalan pintas untuk otak kita sehingga kita dapat menyaring hal-hal yang diperlukan dari hal-hal penting. Jauh lebih baik untuk menciptakan budaya peninjauan untuk menegakkan ini daripada memformalkannya dalam sebuah dokumen.

Ada interpretasi lain. Saya tidak percaya itu yang dimaksud Paman Bob, tetapi patut dipertimbangkan.

Jangan menangkap standar pengkodean dalam dokumen. Tangkap dalam kode, dengan memiliki proses otomatis yang memverifikasi standar terpenuhi .

Jangan mengandalkan orang yang mereferensikan dokumen, tetapi pada saat yang sama, jangan bergantung pada orang yang menafsirkan kode yang sudah ada dan mengidentifikasi konvensi apa dan kebetulan apa.

Masukkan sesuatu seperti Checkstyle ke dalam komit Anda. Ini dapat menegakkan aturan dasar seperti memformat dan menamai standar, dan bukannya mengeluarkan upaya mental dalam mempertimbangkan gaya, yang semuanya bisa diturunkan ke proses bodoh yang setidaknya dijamin menyeluruh.

Jika itu penting, maka tentukan dengan tegas apa yang Anda inginkan, dan gagal jika itu salah.

Orang-orang mengabaikan tujuan sebenarnya dari suatu dokumen standar pengkodean, yaitu untuk menyelesaikan perselisihan .

Sebagian besar keputusan dalam standar pengkodean hanya akan memiliki efek yang sangat kecil pada keterbacaan dan produktivitas. Terutama jika Anda mengadopsi gaya 'normal' untuk bahasa tersebut, dan perancang bahasa mulai menyadari bahwa ini harus menjadi bagian dari spesifikasi (misalnya Go).

Karena mereka sangat sepele, argumen dapat menjadi sangat panas dan berjalan tanpa henti, benar-benar merusak produktivitas dan kohesi tim. Atau dapat mengaburkan riwayat perubahan Anda dengan memformat ulang tanpa akhir antara dua atau lebih gaya yang disukai orang.

Memiliki standar tertulis mengakhiri argumen. Manajer dapat mengarahkannya dan membelokkan ketidakpuasan terhadap dokumen. Anda bisa berdebat dengan selembar kertas tetapi itu tidak akan mendengarkan Anda.

(Lihat juga The Tyranny of Structurelessness )

Karena komentar adalah dusta .

Standar pengkodean adalah komentar besar yang bagus tentang apa yang harus kode. Kode itu sendiri adalah sumber utama kebenaran. Kebenaran dalam hal ini bukan perilaku kode, itu gaya yang diungkapkan. Jika standar Anda belum tercermin dalam kode Anda, Anda memiliki banyak pekerjaan di depan Anda.

Paman Bob melihat komentar sebagai kegagalan pribadi programmer, karena itu membuktikan bahwa ia tidak berhasil mengekspresikan tujuan fragmen kode dengan bahasa pemrograman itu sendiri. Demikian pula, dokumen standar adalah kegagalan untuk mengekspresikan gaya yang koheren dalam basis kode.

Pemrogram baru harus menghabiskan waktu melihat kode, tidak menghabiskan berhari-hari membaca dokumen standar multi-bab (saya harus melakukan ini, huh).

Sebuah dokumen standar bukanlah ide yang buruk, tapi saya pernah berada di toko pemrograman tempat mempertahankan dokumen standar adalah pekerjaan penuh waktu seseorang. Tolong, jika Anda harus menyimpan dokumen standar, simpan ke halaman. Tetapi jika Anda sudah memiliki kode, tidak adakah yang bisa mengumpulkan dokumen yang sama dalam waktu kurang dari sehari?

Memiliki standar kode adalah penting. Memiliki dokumen yang menentukan apa yang bukan.

Mengapa Paman Bob menyarankan agar standar pengkodean tidak dituliskan jika Anda dapat menghindarinya?

Jika Anda menanyakan alasan di balik pendapatnya, maka Anda mungkin memiliki jawaban hanya jika dia akan mengirim jawaban di sini ( pendapat kami tidak relevan), namun ...

Mengapa saya tidak menulis Standar Pengkodean?

Jika Anda bertanya apakah dia benar tentang hal itu: biarkan saya menjadi satu-satunya yang tidak populer (sejauh ini) untuk mengatakan bahwa Anda tidak punya alasan untuk menghindarinya.

MENULISKANNYA . Namun saya akan mencoba menjelaskan alasan saya ...

David menyarankan dalam komentar bahwa poin utama dari jawaban Stephen bukanlah mengapa Anda tidak harus menulis dokumen tetapi dalam bentuk apa mereka. Jika pedoman diformalkan dalam alat (bukan hanya tinjauan kode manual) maka saya dapat setuju (ketika hukum tidak mensyaratkan hal lain). Harap perhatikan bahwa sayangnya alat tidak dapat memeriksa semuanya (teori perhitungan bukan teman kami) sering karena mereka terbatas pada unit terjemahan atau paket tertentu atau apa pun bahasa favorit Anda yang disebut batas .

Namun kata-kata Paman Bob tidak membuat saya berpikir dia berbicara tentang itu.

Bisakah saya tidak setuju dengan pakar senior seperti itu? Saya lakukan, untuk hampir setiap poin dalam posting yang dikutip (lihat juga bagian kedua dari jawaban ini untuk perincian). Mari kita coba memahami mengapa (dengan asumsi Anda sudah tahu bahwa pedoman pengkodean bukan hanya tentang masalah format kecil ).

• Dalam beberapa keadaan, standar pengkodean tertulis diwajibkan oleh hukum.
• Saya membaca dokumentasi dan saya yakin saya tidak sendirian. Anggota tim dapat berubah seiring waktu, pengetahuan tidak dapat berada dalam basis kode 5-10 tahun atau dalam pikiran anggota tim. Organisasi harus memecat orang yang tidak mengikuti pedoman internal.
• Standar pengkodean, setelah disetujui , tidak akan sering berubah dan jika mereka ingin Anda mengetahuinya. Jika standar berubah maka dokumentasi Anda (dalam kode) kedaluwarsa karena semua kode Anda tidak mengikuti standar baru. Pemformatan ulang / refactoring mungkin lambat tetapi Anda selalu memiliki pedoman otoritatif tertulis untuk diikuti.
• Lebih baik membaca dokumen 5 halaman daripada memeriksa 10 / 20K LOC untuk memperkirakan aturan (yang mungkin Anda salah pahami, BTW), tidak diragukan lagi.
• Sungguh ironis bahwa seseorang yang menulis banyak buku tentang prinsip-prinsip desain dan gaya pengkodean menyarankan agar Anda tidak menulis pedoman Anda sendiri, bukankah lebih baik jika ia mencampakkan kita dengan beberapa contoh kode? Tidak, karena pedoman tertulis tidak hanya memberi tahu Anda apa yang harus dilakukan tetapi juga dua hal lain yang tidak memiliki kode: apa yang tidak boleh dilakukan dan alasan untuk melakukannya atau tidak.

"Free self-organizing programming" baik untuk seorang ninja berusia 16 tahun tetapi organisasi memiliki persyaratan lain :

• Kualitas kode harus diberikan (dan ditentukan) di tingkat perusahaan - itu bukan sesuatu yang bisa diputuskan oleh satu tim. Mereka bahkan mungkin tidak memiliki keterampilan untuk memutuskan mana yang lebih baik (berapa banyak pengembang, misalnya, memiliki semua keterampilan yang diperlukan untuk meninjau MISRA atau bahkan hanya memahami setiap aturan?)
• Anggota dapat dipindahkan di tim yang berbeda: jika semua orang mengikuti standar pengkodean yang sama maka integrasi menjadi lancar dan lebih sedikit rawan kesalahan.
• Jika sebuah tim mengorganisir diri sendiri maka standar akan berkembang seiring waktu ketika anggota tim berubah - Anda kemudian akan memiliki basis kode besar yang tidak mengikuti standar yang berlaku saat ini .

Jika Anda memikirkan orang sebelum proses maka saya hanya bisa menyarankan membaca tentang TPS: manusia adalah bagian utama Lean tetapi prosedurnya sangat formal.

Tentu saja organisasi kecil dengan hanya satu tim dapat membiarkan tim memutuskan standar untuk diadopsi tetapi kemudian harus ditulis. Di sini, di Programmers.SE Anda dapat membaca posting oleh Eric Lippert: Saya kira kita semua setuju dia adalah pengembang yang berpengalaman, ketika dia bekerja untuk Microsoft dia harus mematuhi pedoman tertulis mereka (bahkan jika beberapa aturan mungkin salah , tidak berlaku atau tidak berguna padanya.) Bagaimana dengan Jon Skeet? Pedoman Google sangat ketat (dan banyak orang tidak setuju dengan mereka) tetapi dia harus mematuhi pedoman tersebut. Apakah itu tidak sopan kepada mereka? Tidak, mereka mungkin bekerja untuk mendefinisikan dan meningkatkan pedoman tersebut, sebuah perusahaan tidak dibuat oleh satu anggota (atau satu tim) dan masing-masing tim bukan pulau .

Contohnya

• Anda memutuskan untuk tidak menggunakan beberapa kelas warisan dan bersarang di C ++ karena Anda anggota tim yang sebenarnya tidak memahaminya dengan baik . Kemudian seseorang yang ingin menggunakan multiple inheritence harus menelusuri seluruh 1M LOC untuk melihat apakah ia pernah digunakan. Itu buruk karena jika keputusan desain tidak didokumentasikan Anda harus mempelajari basis kode keseluruhan untuk memahaminya. Dan bahkan kemudian, jika belum digunakan, apakah itu karena itu melanggar standar pengkodean, atau apakah itu diizinkan, tetapi tidak ada situasi sebelumnya di mana banyak pewarisan cocok?
• Di C # Anda memiliki metode kelebihan untuk memberikan parameter default karena basis kode Anda dimulai ketika parameter opsional tidak tersedia di C #. Kemudian Anda berubah dan Anda mulai menggunakannya (refactoring kode lama untuk menggunakannya setiap kali Anda harus memodifikasi fungsi tersebut). Bahkan kemudian Anda memutuskan bahwa parameter opsional buruk dan Anda mulai menghindari menggunakannya. Apa aturan kode Anda memberi tahu Anda? Itu buruk karena standar berevolusi tetapi basis kode lebih lambat untuk berkembang dan jika itu dokumentasi Anda maka Anda dalam kesulitan.
• Jon pindah dari tim A ke tim B. Jon harus belajar standar baru; sambil belajar dia mungkin akan memperkenalkan bug yang lebih halus (atau, jika beruntung, hanya perlu waktu lama untuk memahami kode yang ada dan membuat ulasan kode lebih lama).
• Tim A pindah ke basis kode yang sebelumnya dimiliki oleh tim B. Ini memiliki standar pengkodean yang sama sekali berbeda. Menulis kembali? Menyesuaikan? Campuran? Semuanya sama-sama buruk.

Paman Bob

Biarkan mereka berkembang selama beberapa iterasi pertama.

Benar, sampai Anda tidak memiliki standar dan organisasi Anda memberi Anda tugas untuk membangunnya .

Biarkan mereka menjadi tim spesifik, bukan khusus perusahaan.

Tidak, untuk semua alasan yang dijelaskan di atas. Bahkan jika Anda berpikir untuk memformalkan pemformatan kode saja (hal yang paling tidak berguna yang mungkin ingin Anda formalkan), saya masih memiliki memori perang tanpa akhir (dan tidak berguna) tentang pemformatan. Saya tidak ingin menghidupkannya lagi dan lagi, atur sekali untuk semua.

Jangan menuliskannya jika Anda bisa menghindarinya. Alih-alih, biarkan kode menjadi cara standar ditangkap.

Tidak, untuk semua alasan yang dijelaskan di atas (tentu saja kecuali jika Anda akan memperbaiki semua kode Anda dalam sekali pakai ketika pedoman berubah). Apakah Anda ingin membiarkan kode apa adanya? Bagaimana Anda memeriksa basis kode untuk memahami pedoman saat ini ? Mencari berdasarkan usia file dan mengadaptasi gaya pengkodean Anda ke sumber usia file?

Jangan membuat undang-undang desain yang bagus. (mis. jangan bilang orang tidak menggunakan goto)

Benar, pedoman harus singkat atau tidak ada yang akan membacanya. Jangan ulangi yang sudah jelas.

Pastikan semua orang tahu bahwa standarnya adalah tentang komunikasi, dan tidak ada yang lain.

Tidak hanya, standar yang baik adalah tentang kualitas kecuali jika Anda ingin memiliki standar hanya tentang detail kecil .

Setelah beberapa iterasi pertama, buat tim bersama untuk memutuskan.

Lihat poin pertama dan jangan lupa bahwa standar pengkodean biasanya merupakan proses yang membutuhkan waktu bertahun-tahun untuk dikembangkan dan disempurnakan: beberapa iterasi, mungkin dengan pengembang junior? Benarkah? Apakah Anda ingin mengandalkan memori satu anggota senior (jika ada)?

Tiga catatan:

• Menurut pendapat saya kekurangan lebih serius dengan beberapa bahasa daripada yang lain, misalnya dalam C ++ standar tingkat perusahaan bahkan lebih dibutuhkan daripada di Jawa.
• Alasan ini mungkin tidak berlaku sepenuhnya (dan alasan Paman Bob mungkin tidak terlalu ekstrem ) jika Anda bekerja di perusahaan yang sangat kecil di mana Anda hanya memiliki satu tim kecil.
• Anda dipekerjakan (sebagai tim) dan Anda akan bekerja sendiri dengan satu proyek baru maka Anda akan melupakannya dan melanjutkan. Dalam hal ini Anda mungkin tidak peduli (tetapi majikan Anda harus ...)

1. Agar berguna, standar pengkodean tidak boleh berbicara tentang masalah substansi; hanya masalah gaya. Seharusnya hanya menentukan hal-hal yang sewenang-wenang dan ambigu. mis. Penempatan brace, kedalaman lekukan, spasi vs tab, konvensi penamaan, dll.
2. Masalah gaya adalah lokal, bukan global. Setiap tim harus mengadopsi gaya khas mereka sendiri, disesuaikan dengan tugas mereka, dan kepribadian mereka. Ini menjaga standar sederhana dan ringan. Standar perusahaan menjadi terbebani dengan semua pertimbangan, konfigurasi, dan pengecualian yang dimungkinkan.
3. Dalam sebuah tim, satu-satunya alasan untuk menulis dokumen gaya pengkodean terpisah adalah jika kode yang dihasilkan oleh tim tidak memenuhi standar. Dalam hal ini Anda tidak memiliki standar. Agar efektif, standar harus dinyatakan oleh kode itu sendiri. Dan jika demikian, tidak perlu dokumen terpisah.
4. Dalam sistem lama tim dan gaya berubah seiring waktu. Tidak ada yang salah dengan itu. Kode lama akan memiliki gaya yang lebih lama. Kode yang lebih baru akan memiliki gaya yang lebih baru. Tim harus mengetahui gaya dan usia mereka. Setiap kali kode baru ditulis, itu harus dalam gaya baru, di mana pun dalam kode itu berada.

Mengapa saya tidak menulis Standar Pengkodean?

Ada banyak alasan untuk ini. Berikut beberapa pertimbangan:

1. Berapa banyak waktu orang menghabiskan "belajar" standar kode hanya untuk memiliki banyak waktu masuk ke seluruh tim meninjau, berdiskusi, mendokumentasikan, merevisi ... dll. Standar kode. Ini seperti terus-menerus mendiskusikan "Buku Pegangan Karyawan" Anda - seberapa sering hal itu masuk dalam agenda rapat tim?

2. Ketika sebuah proyek mengalami kerusakan / disimpan / dll. maka beberapa orang yang tetap biasanya tidak dapat terus mematuhi (atau mungkin bahkan belum membaca) standar. Hal berikutnya yang Anda tahu, semua upaya untuk "menjaga kode tetap bersih" ternyata terbuang sia-sia.

3. Jika proyek terhenti atau pimpinan baru dimasukkan, sangat mungkin orang tersebut akan mengabaikan aturan sebelumnya dan ingin melakukannya dengan cara yang baru. Sekali lagi, apa yang diperoleh dengan mengkodifikasi standar ??

Anda harus yakin membaca # 6:

Setelah beberapa iterasi pertama, buat tim bersama untuk memutuskan.

Dengan kata lain, ketika saatnya untuk memulai suatu proyek, ikuti saja alirannya untuk sementara waktu. Kemudian diskusikan aturan umum standar pengkodean yang digunakan oleh tim saat ini - dan pada dasarnya ikuti mereka. Dengan begitu, Anda memaksimalkan upaya yang dilakukan untuk meningkatkan produk sambil meminimalkan upaya yang diperlukan untuk menulis, meninjau dan mendokumentasikan "gula sintaksis" yang digunakan untuk mendapatkan kode yang dapat dieksekusi.

Sangat sedikit tim yang memperoleh manfaat besar dari standar pengkodean. Biasanya, "keterbacaan" terlalu kabur - dan sebagian besar pengembang tidak mendapatkan banyak manfaat dari aturan yang tepat tentang penspasian, baris baru, dll. Tetapi Anda dapat menghindari pengembang yang terus-menerus mengganggu dengan memiliki setidaknya beberapa aturan.

Jawaban lain yang menurut saya tidak cukup jelas dinyatakan, adalah itu juga berarti bahwa orang tidak mengikuti aturan secara membabi buta. Ini berarti bahwa orang harus datang dengan pembenaran aktual untuk keputusan desain dan konvensi pengkodean mereka, daripada hanya bergantung pada fakta bahwa itu telah ditulis untuk membenarkannya.

Pertama, sejauh yang saya tahu, Paman Bob adalah orang Jawa, ini sangat penting untuk memahami apa yang dikatakannya.

Ketika bekerja di tim Java atau C #, jika kode saat ini telah ditulis oleh pengembang yang berpengalaman, mudah bagi saya untuk mengambil gaya pengkodean dan mengikuti perkembangannya. Jika saya tidak mau melakukannya, mungkin saya bukan orang yang tepat untuk pekerjaan itu ... Jika tidak ada peninjauan kode atau pemrograman pasangan untuk menjemput saya ketika saya tidak mengikuti gaya, maka perusahaan memiliki masalah yang lebih besar dari cara saya memberi nama bidang anggota!

Baik Java dan C #, bersama dengan sebagian besar bahasa modern, telah didefinisikan sehingga ada beberapa perangkap "sederhana" bagi seorang programmer.

Namun ketika saya mulai pemrograman saya menggunakan C (dan kemudian C ++). Di C Anda dapat menulis kode seperti

if (a = 3);
{
   /* spend a long time debugging this */
}

Kompiler tidak akan memberikan kesalahan, dan itu sulit dikenali ketika membaca banyak kode. Namun, jika Anda menulis:

if (3 = a)
{
   /* looks odd, but makes sense */
}

Kompiler memberikan kesalahan, dan saya mudah untuk mengubah kode 3 == a. Demikian juga, jika standar pengkodean tidak memungkinkan =untuk digunakan dalam ifkondisi atau " ifpernyataan kosong ", maka pemeriksa kode dapat digunakan sebagai bagian dari sistem build untuk melacak kesalahan ini.

Pandangan saya tentang standar pengkodean berubah sangat ketika saya pindah dari C / C ++: Saya dulu suka standar pengkodean yang ditegakkan secara ketat, dan banyak halaman panjangnya. Saya sekarang berpikir Anda hanya perlu membuat daftar alat yang digunakan, dan mendapatkan persetujuan informal antara anggota tim asli pada beberapa konvensi penamaan. Kami tidak lagi tinggal di dunia tim yang terdiri lebih dari 30 pengembang yang menulis aplikasi dalam C / C ++ ...

Ada alasan saya tidak pernah menyukai JScript, dan menganggap TypeScript adalah hal terbaik yang terjadi pada pengembangan web selama bertahun-tahun. Saya berharap bahwa pengembang Web UI masih membutuhkan standar pengkodean karena cacat dalam desain HTML / CSS / JScript dll.

Memiliki sumber menjadi standar pengkodean self-documenting menyiratkan dua hal.

1. Orang-orang harus berkonsultasi dengan basis kode dan meninjaunya untuk menjadi kontributor yang mahir. Ini sangat penting. Membaca pedoman pengkodean adalah buang-buang waktu dibandingkan dengan menyelam ke dalam basis kode.
2. Ini mengakui bahwa perbedaan kecil tidak penting. Sangat penting untuk menyetujui dan memahami prinsip-prinsip dasar. Mempertahankan gaya yang konsisten tidak diupayakan karena l'art pour l'art. Itu tidak memungkinkan nitpickers yang tidak kreatif mengganggu dan mengalihkan perhatian orang lain. Ini adalah tentang memfasilitasi komunikasi melalui kode dalam sebuah tim.

Dokumen standar kode yang sering diperbarui dan ditulis dengan baik bisa sangat berguna, tetapi biasanya tidak demikian. Dokumen standar tidak mencerminkan standar pengkodean aktual yang digunakan oleh perusahaan karena sangat sulit untuk membuat dokumen standar yang baik dan bahkan lebih sulit untuk tetap memperbaruinya.

Daripada memiliki dokumen standar pengkodean yang buruk dan menyesatkan, lebih baik tidak memilikinya dan membiarkan kode itu sendiri mewakili standar tersebut. Apa pun bagian terpenting adalah menerapkan standar dalam kode, dan ini membutuhkan lebih dari sekadar dokumen. Motivasi, proses, pelatihan, alat dll jauh lebih penting.

Satu hal yang sangat penting yang belum dinyatakan dengan cukup jelas adalah bahwa standar pengkodean seperti bahasa: mereka berkembang. Standar pengkodean tertulis menghalangi hal ini, dan jika tidak, standarnya terus-menerus usang dan tidak berguna.

Tidak memiliki standar coding dipaku tidak terlalu buruk. Jika Anda melakukan peer review pada saat check-in, setiap kali sesuatu yang tidak sesuai dengan standar pengkodean memasuki repositori yang berarti 2 orang memikirkannya * dan memutuskan manfaat variasi ini lebih besar daripada ketidakkonsistenan dengan sisa kode.

Tidak memiliki standar tertulis juga menghilangkan birokrasi yang akan mencegah tim perusahaan untuk mencoba variasi baru dari standar pengkodean untuk proyek baru, baik karena mereka ingin mencoba sesuatu, atau mungkin karena standar yang berbeda memiliki aplikasi praktis pada beberapa alat otomatis yang mereka gunakan.

Menulis standar memiliki kecenderungan untuk menghapus lebih banyak fleksibilitas daripada yang semula dimaksudkan, sementara juga mengambil cukup banyak waktu yang dapat dihabiskan untuk melakukan hal-hal lain. Saya tidak mengatakan Anda seharusnya tidak pernah menuliskan standar pengkodean, standar tertulis tentu memiliki manfaatnya, terutama jika tim yang bekerja di lokasi yang berbeda bekerja pada basis kode yang sama.

Sangat terkait: Evolusi dalam standar pengkodean, bagaimana Anda menghadapinya?

* Jika orang tidak berpikir sambil mengintip kode peninjauan saat check-in, masalah Anda jauh lebih besar dari sekadar standar pengkodean.

Mengubah mereka menjadi rintangan utama, dan orang akan mematuhi surat hukum dengan aman daripada melibatkan otak dan melakukan hal yang benar.

Akan datang suatu hari ketika bagian dari standar tidak membantu, dan membuat kode lebih buruk. Beberapa orang akan mematuhi standar, karena itu ditulis dan mereka aman, dan karena ada aturan yang harus diikuti. Orang yang ingin menulis kode yang baik daripada kode yang sesuai standar akan frustrasi dan marah. Akan ada argumen dan perbedaan pendapat, sedangkan jika standar tidak ditulis, akan ada eksplorasi dan diskusi.

Saya pikir banyak posting di sini membingungkan standar pengkodean dengan panduan gaya .

Memastikan bahwa modul yang dikembangkan oleh tim yang berbeda memiliki opsi kompiler yang sama dan ABI adalah hal yang berbeda dari berapa banyak ruang yang diindentasi.

Hal-hal seperti cara yang tepat untuk membuat struktur #include file dan tidak mencemari namespace global dalam file header harus didokumentasikan sehingga mereka dapat digunakan sebagai daftar periksa selama pengkodean awal dan ulasan kode.

Khususnya "jangan gunakan XXX karena menyebabkan masalah kompatibilitas dengan YYY" bukanlah sesuatu yang akan Anda lihat dengan contoh dalam mengikuti kode lain, karena itu tidak ada. Jadi biarkan kode menjadi cara standar ditangkap mungkin tidak jelas atau benar-benar hilang untuk beberapa jenis standar, dan dengan demikian ini tidak dapat menjadi rencana universal.

Sesuatu yang serius meresap dan penting seperti tidak menggunakan pengecualian atau tidak menggunakan newdalam sistem embedded tertentu tidak bisa begitu saja dibiarkan menjadi pengetahuan budaya umum, karena "informasi itu budaya (saja)" bertentangan dengan prinsip-prinsip dasar standar manufaktur seperti ISO-9000, bahwa pengembang sistem embedded ini menggunakan (misalnya untuk aplikasi otomotif). Hal-hal penting ini harus didokumentasikan, ditandatangani, dan disimpan secara formal.

Tapi itu berlaku untuk coding , bukan style .

Para penemu C dan C ++ menunjukkan, dengan contoh, penggunaan nama huruf kecil dan bukan CaMelCaSe. Jadi mengapa banyak pengembang tidak mengikuti contoh implisit dari sumber? Bukankah seharusnya gaya perpustakaan standar dan bahan ajar kanonik menjadi gaya implisit untuk diikuti?

Sementara itu, orang-orang melakukan mencontoh header perpustakaan standar untuk hal-hal yang tidak boleh disalin, seperti penggunaan __Uglynama untuk parameter makro dan menyertakan file pola non-repeat.

Jadi memiliki barang sering tidak dipandang sebagai gaya yang penting, atau sebaliknya memiliki contoh mungkin tidak jelas mengenai apa yang tidak boleh diikuti dalam kode proyek. Keduanya merupakan contoh berlawanan dengan tesis bahwa "gaya" (atau aturan pengkodean) sebaiknya dibiarkan tersirat.