Saya tahu bahwa sudah terbukti bahwa standar pengkodean sangat membantu. Namun, ada banyak alat dan IDE berbeda yang akan memformat dengan standar apa pun yang lebih disukai programmer. Selama kode itu rapi / dikomentari (dan bukan kekacauan spageti), saya tidak melihat perlunya standar pengkodean.

Apakah ada argumen untuk pengembangan standar pengkodean (kami tidak memilikinya, tapi saya ingin membuatnya)?

Namun, ada banyak alat dan IDE berbeda yang akan memformat dengan standar apa pun yang lebih disukai programmer.

Semoga beruntung dengan itu. Pengalaman saya, ada sejumlah kecil alat (nol!) Yang dapat memformat ulang kode dengan benar dari format X ke format Y. Ada terlalu banyak hal yang menghalangi. Tab vs spasi, pernyataan multi-baris, dll. Lihat saja implementasi GNU dari file pustaka standar C ++. Yang dapat Anda lakukan adalah membuat IDE Anda lakukan adalah selalu menggunakan spasi alih-alih tab dan jangan repot-repot memformat ulang kode asing. Sekarang kode Anda terlihat seperti yang Anda suka, dan kode asing terlihat seperti cara penulis asli menulisnya.

Gaya lekukan tertentu adalah hal terakhir yang harus ditentukan oleh standar pengkodean. Itu hampir memulai pemrograman perang agama. IMO, standar pengkodean harus menentukan rangkaian gaya indentasi yang dapat diterima, tetapi menyerahkan spesifikasinya kepada pembuat paket. Gaya lekukan adalah, atau seharusnya, bagian kecil dari standar pengkodean. Aturan nol angka standar pengkodean: Jangan memusingkan hal-hal kecil. Gaya lekukan adalah hal kecil.

Hal yang lebih besar:

• Bagaimana saya memberi nama berbagai hal?
• Apakah bagian-bagian tertentu dari bahasa terlarang?
• Apakah kode perlu dikompilasi bersih, dan dengan pengaturan kompiler apa?
• Apakah kode harus lulus metrik tertentu?
• Tes seperti apa yang dibutuhkan?
• Dokumentasi apa yang dibutuhkan, baik dalam kode (komentar) dan di tempat lain?
• Yang paling penting, bagaimana cara mendapatkan pengabaian terhadap standar?

Adendum
Mungkin yang lebih penting adalah apa yang tidak dimasukkan ke dalam standar pengkodean. Topik seperti cara menulis persyaratan tidak termasuk dalam standar pengkodean. Detail tentang pengujian juga tidak termasuk. Suatu proyek tidak boleh menggunakan standar pengkodean sebagai stand-in untuk rencana manajemen proyek, rencana manajemen pengujian, rencana verifikasi dan validasi, dll. Tujuan dari standar pengkodean adalah untuk meningkatkan keamanan kode, kualitas, kemampuan memahami, pemeliharaan, dan "ilities" lainnya. Ada banyak cara untuk memastikan bahwa ini tidak akan terjadi. Hanya sedikit: Menjadikan standar sebuah buku serumit undang-undang pajak beberapa negara, menghasut program perang agama, memiliki konvensi penamaan yang buruk.

Standar pengkodean dapat memiliki konsekuensi yang tidak diinginkan. Contoh: Beberapa orang bodoh dari seorang insinyur proyek akan menafsirkan "tidak ada aturan angka ajaib" yang berarti if (index == 0) {...}dan for (ii = 0; ii < 3; ++ii) {...}harus diubah menjadi if (ZERO == index) {}dan for (ii = ZERO; ii < NUMBER_OF_DIMENSIONS_IN_THE_UNIVERSE; ++ii) {...}Jangan tertawa. Saya sudah melihatnya terjadi. Saat ini ketika saya menulis standar pengkodean, itu adalah "pedoman angka ajaib" dan bukan aturan untuk menangkal kebodohan semacam ini.

Standar pengkodean bukanlah pertahanan nomor satu terhadap gaya pemrograman yang buruk / praktik pengkodean yang berbahaya. Ulasan kode. Meskipun telah bertahun-tahun diotomatisasi, masih ada yang lebih baik daripada memiliki mata manusia yang agak subyektif melihat dan memberikan penilaian pada sepotong kode.

Standar pengkodean tidak hanya tentang parameter yang disukai indent- mereka juga mencakup konvensi penamaan, konvensi komentar, dan sejumlah besar rekomendasi yang mungkin untuk idiom, penggunaan fitur bahasa, dll.

Lebih penting lagi, Anda masih perlu mendokumentasikan semua ini di suatu tempat. Dan akhirnya, tidak semua orang ingin menggunakan IDE yang memformat ulang kode seperti itu ...

Jika Anda menggunakan gaya yang konsisten dalam suatu tim, kode Anda menjadi lebih mudah dibaca. Ketika kode Anda menjadi lebih mudah dibaca maka tim Anda akan lebih produktif. Mereka akan lebih produktif karena mereka tidak perlu menguraikan kode secara mental, dan dapat fokus pada logika daripada sintaks ketika meninjau dan memelihara kode.

Jika setiap orang membiarkan IDE memformat ulang kode sesuai pilihan mereka, Anda memiliki satu dari dua masalah: Anda harus memastikan bahwa Anda selalu mengubahnya kembali ke format asli saat menyimpan, atau menderita kenyataan bahwa diff Anda akan menunjukkan banyak suara, membuatnya lebih sulit untuk melihat apa yang telah berubah dalam logika kode.

Jawaban Singkat: Ya, itu mencerminkan kualitas .

Apa itu dan mengapa kita membutuhkannya?

Standar pengkodean adalah bagian yang sangat penting dari perangkat lunak berkualitas tinggi. Mereka memang meningkatkan produktivitas dalam proses pengembangan, membuat kode lebih mudah dipelihara, dan menjaga agar kode tidak terikat pada satu orang atau tim. Konsistensi dalam standar pengkodean juga membedakan kode yang dibuat secara prematur dari seni yang dibuat dengan baik.

OK, setiap pengembang tahu bahwa konvensi pengkodean itu baik. Tetapi dari mana seharusnya standar berasal?

Sebagian besar ditentukan oleh vendor yang memiliki produk. Setiap pengembang dapat memilih dari banyak standar pengkodean industri. Beberapa perusahaan Microsoft, Oracle dan Sun Microsystems menawarkan pedoman.

Apakah ada argumen untuk pengembangan standar pengkodean (kami tidak memilikinya, tapi saya ingin membuatnya)?

Ya, ada standar industri yang direkomendasikan untuk digunakan. Namun, setiap standar pengkodean khusus untuk platform pengembangan. Dengan demikian, standar pengkodean sebagian besar spesifik bahasa. Misalnya, Java memiliki standar yang berbeda dari .NET. Sebagai contoh C # .NET menggunakan standar itu dalam referensi ini .

Standar umum

Standar umum tidak memiliki ketergantungan pada bahasa pemrograman apa pun. Selain standar yang ditawarkan vendor, alias standar pengkodean industri yang disebutkan, ada berbagai notasi pemrograman seperti Notasi Hongaria atau CamelCase . Saya pikir Microsoft. NET pengkodean standar awalnya didasarkan pada notasi CamelCase.

Standar dan pedoman pengkodean tim

Dalam pemikiran, setiap tim pengembang harus menyetujui standar pengkodean segera setelah proyek dimulai. Pedoman pengkodean biasanya dibuat oleh Ketua Tim atau kepala Arsitek perusahaan. Biasanya dokumen terbuka harus diikuti dan diperbaiki jika diperlukan. Misalnya, di perusahaan kami, kami memiliki halaman Wiki tempat dokumen ini diunggah dan tersedia untuk pengembang perusahaan.

Saya akan mengambil pendapat kontroversial dan mengatakan tidak, Anda tidak perlu standar pengkodean . Entah aturan tersebut, seperti yang Anda katakan, pedoman yang dapat ditegakkan IDE, praktik umum terbaik yang harus diikuti oleh setiap orang di setiap perusahaan, atau mereka adalah panggilan kasus per kasus tim per kasus yang harus dilakukan oleh lebih dari satu orang di tim yang cakap melalui pemrograman pasangan atau ulasan kode.

Hal-hal seperti Bagaimana kita memberi nama variabel ini? Fitur bahasa apa yang harus kita gunakan? Haruskah kita menghindari? Pengujian apa yang terbaik? Ini sebaiknya tidak dijawab sampai kita menemukan masalah yang didefinisikan sempit yang sedang kita kerjakan sekarang .

Dikristalisasi dari keputusan kecil ini, standar / pola informal dalam tim dapat muncul, berdasarkan persimpangan dengan domain masalah saat ini dan teknologi yang digunakan. Mengkodifikasi ini berarti kami berpikir bahwa hal-hal seperti standar penamaan, bagian bahasa yang sesuai, dll digunakan pada proyek-proyek ini, berdasarkan ratusan keputusan mikro, dan diadopsi secara informal oleh tim-tim ini harus memandu setiap proyek bergerak maju.

Pada prinsipnya itu terdengar seperti hal yang hebat, tetapi dalam kenyataannya itu hanya menjadi magnet bagi politik. Alat apa yang bisa kita paksa semua orang gunakan? Apa yang ingin saya paksa orang lain hindari? Jika semua orang menyetujui pertanyaan-pertanyaan ini, kami tidak memerlukan standar. Kami baru saja melakukannya. Dalam pengalaman saya standar keluar dari keinginan untuk satu subset dari pengembang untuk melakukan kontrol atas subset lain. Biasanya jenis politik ini dan kebijakan teknologi yang mengikutinya hanya menghambat inovasi daripada memberikan panduan.

Jika Anda menginginkan panduan nyata , alih-alih membaca standar dengan banyak aturan yang tidak membantu, temui anggota tim Anda yang cakap dan tanyakan apa yang mereka pikirkan. Apa yang telah mereka bakar? Bagaimana mereka menyarankan Anda menulis kode? Anda akan mendapatkan beragam jawaban berguna dengan banyak pengalaman berharga untuk mendukungnya. Anda akan melihat banyak persimpangan berdasarkan pengalaman umum. Alih-alih monokultur yang dipaksakan oleh standar, Anda juga akan melihat banyak keanekaragaman yang hanya dapat membantu Anda melihat banyak cara yang valid untuk menyelesaikan masalah.

Dan ketika seseorang mengatakan kepada Anda untuk tidak melakukan sesuatu karena aturan dalam "standar" tetapi tidak memiliki pengalaman atau cadangan yang masuk akal untuk klaim mereka, abaikan saja. Di sini standar belum melayani siapa pun atau menjadikan siapa pun pengembang yang lebih baik.

Sekarang pesawat komersial terbang dengan kawat, Anda akan berharap program menerbangkan pesawat berdasarkan karya input pilot. Ketika programmer menulis kode seperti itu, Anda berharap mereka mengikuti serangkaian aturan ketat untuk menghindari kesalahan pemrograman yang biasanya dihindari. Salah satu cara untuk melakukan ini adalah dengan standar pengkodean.

Lihat: Usulan Administrasi Penerbangan Federal C dan C ++ Standar Pengkodean

Perlu saya katakan lebih.

Catatan: Saya tidak dapat menemukan standar aktual dari FAA online, tetapi saya telah melihatnya.

Bagi saya ini masalah disiplin dan disiplin selalu membantu, ini mencerminkan kualitas pekerjaan yang Anda hasilkan.

Karena itu, saya akan membuat standar pengkodean tetap melihat IDE dan / atau alat yang digunakan. Lebih jauh, IDE harus dikonfigurasikan secara identik (misalnya setiap IDE pengembang harus menggunakan semua tab atau semua ruang putih untuk lekukan dan IDE semua orang harus memiliki panjang tab yang sama) untuk setiap pengembang sehingga setiap orang dapat mengikuti standar dengan mudah ...

Selain itu, skrip check-in dapat dikembangkan dan digunakan yang dapat membantu dalam mematuhi standar pengkodean sampai batas tertentu, misalnya skrip dapat memperbaiki lekukan sebelum benar-benar memasukkan file yang diperiksa ke dalam sistem kontrol versi.

Standar pengkodean TIDAK bisa lebih penting lagi! Saya pengguna CakePHP yang rajin dan saya ingin meninjau perubahan dari versi ke versi dan para pengembang tidak mengikuti standar di sana.

Bahkan, saya sangat kesal dengan perbedaan gaya sehingga saya harus menulis Kata-kata Singkat Tentang Konvensi Pengkodean . Dibutuhkan banyak waktu dan uang untuk membawa pengembang baru ke tim yang sudah ada - bayangkan saja membawa pengembang baru tanpa standar ... mempelajari kode akan menjadi terlalu mustahil berikutnya.