Standar pengkodean .NET / C # yang disarankan? [Tutup]

Standar pengkodean apa yang menurut Anda penting untuk proyek .NET / C #? Ini bisa apa saja dari berurusan dengan kurung kurawal dan jarak dan kesedihan seperti itu. Atau itu bisa menjadi pertanyaan yang lebih mendasar seperti ruang nama apa dalam .NET Framework yang harus dihindari, praktik terbaik dengan file konfigurasi, dll.

Cobalah untuk menghindari membuat posting yang merupakan akibat wajar dari yang lain. Sebagai contoh, akan baik-baik saja untuk memiliki satu pos yang berfokus pada kurung kurawal. Kami tidak perlu dua untuk mendukung satu gaya vs yang lain. Idenya bukan untuk memilih standar hewan peliharaan Anda, tetapi untuk menyempurnakan apa yang harus dipikirkan saat membuat standar.

Berikut adalah Panduan Microsoft resmi tentang standar pengkodean untuk .NET framework Versi 4.0.

Jika Anda ingin versi yang lebih lama untuk 1.1, coba di sini .

Saya tidak perlu mengikuti ini ke 'T', seperti kata mereka. Namun, ketika ragu, ini adalah tempat terbaik untuk mulai konsisten dengan kerangka .NET saat ini, yang membuatnya lebih mudah untuk semua orang, tidak peduli apakah mereka baru ke proyek khusus Anda atau tidak.

Mungkin ingin melihat StyleCop . Anda bahkan dapat memasukkannya ke beberapa sistem build sehingga kesalahan style akan merusak build. Pengaturan default sebagian besar kongruen dengan apa yang disarankan MS untuk pedoman (seperti yang diposting oleh orang lain).

Anda juga dapat mengubah aturan yang ada pada pengaturan default.

Pedoman dari Microsoft:

• .NET - http://msdn.microsoft.com/en-us/library/czefa0ke.aspx
• C # - http://blogs.msdn.com/brada/articles/361363.aspx

Kami mengadopsi ini di kantor kami. Ini ditulis oleh Lance Hunt, dan itu cukup komprehensif:

http://weblogs.asp.net/lhunt/pages/CSharp-Coding-Standards-document.aspx

Mulai dengan FxCop . Ini akan memberi tahu Anda tentang pelanggaran praktik terbaik dalam kode yang ada.

Saya mencoba memilih serangkaian gaya umum dari berbagai sumber. Beberapa yang tidak disebutkan sebelumnya:

• dokumentasi dari C # Coding Guidelines - pembaruan terakhir pada 2010
• IDesign C # Standar Pengkodean - pembaruan terakhir pada 2008
• Philips Healthcare - C # Coding Standard - pembaruan terakhir pada tahun 2009
• Encodo C # Handbook - pembaruan terakhir pada tahun 2009

Saya harus merekomendasikan standar yang disediakan oleh SSW (perusahaan Konsultasi Australia).

Bukan hanya coding, tetapi Manajemen Proyek dll ... Sumber daya yang sangat berharga.

http://www.ssw.com.au/ssw/standards/default.aspx

Metode harus pendek

Sebagian besar metode harus menggunakan sebagian besar bidang dalam sebuah kelas.

Pilih nama Anda dengan baik.

Misalnya membaca buku Kode Bersih

Saya menggunakan aplikasi berikut untuk mempertahankan standar pengkodean selain aturan camelback, nama metode, dll.

GhostDoc - Menambahkan komentar yang dihasilkan secara otomatis di atas setiap metode. Aplikasi ini menyediakan ringkasan metode yang baik. (Gratis)

http://submain.com/products/ghostdoc.aspx

Resharper - analisis kode dan refactoring http://www.jetbrains.com/resharper/

StyleCop - Sebagai pembersihan terakhir sebelum saya check-in ke TFS. (Gratis)

http://code.msdn.microsoft.com/sourceanalysis

Saya benci standar pengkodean yang sudah ada, mereka semua peduli dengan memberi tahu Anda untuk tidak membuat beberapa kesalahan konyol, atau memberi tahu Anda cara memformat kode Anda dengan cara apa pun. Semuanya adalah hal-hal sepele.

Maksud saya, mereka akan memberi tahu Anda berapa banyak ruang untuk ditempatkan di antara operator, cara membuat variabel Anda, apa awalan 'gaya hungaria' untuk digunakan (misalnya _ untuk anggota), saran yang bertentangan (misalnya Anda tidak dapat memanggil kelas Cxyz tetapi Anda harus panggil antarmuka Ixyz), cara tata letak kode Anda (letakkan variabel Anda di bagian atas kelas atau di bagian bawah)

Semua tidak berguna dalam gambaran besar.

Apa yang penting untuk menulis kode yang efektif, dapat dipelihara dan dapat dibaca tidak pernah disebutkan dalam standar ini.

Misalnya: apakah Anda meletakkan variabel Anda di bagian atas atau bawah kelas Anda? Nah, siapa yang peduli - yang penting adalah jika Anda mengelompokkan variabel Anda berdasarkan area fungsional. Itu penting (Anda akan tahu ini jika Anda pernah melihat 20 variabel bertebaran di tempat itu).

Mereka memberitahu Anda untuk menempatkan kurung keriting Anda di tempat-tempat tertentu. Masalah besar! Saya dapat membaca kode dalam bracketing gaya K&R dan ANSI, tidak masalah. Yang penting adalah jika semua kelas Window dibedakan entah bagaimana (seperti diberi sufiks dengan Form atau Dlg atau apa pun) sehingga Anda dapat melihat file mana yang berisi kode jendela dan mana yang merupakan objek biasa.

Hal-hal seperti ini jauh lebih penting daripada poin minor yang biasanya dimiliki oleh standar. Saya tidak tahu mengapa mereka berkembang seperti ini, tetapi seringkali mereka hanya satu ton aturan yang menghalangi pengkodean yang efektif dan produktif.

Standar saya mencoba untuk lebih fokus pada pengaturan kode dan file. Kami memiliki standar tertentu yang merujuk ke tempat file akan ditemukan. Misalnya, untuk orang-orang non-dev dapat melihat salah satu proyek kami dan segera mengambil file dokumentasi yang mereka butuhkan. Demikian pula, kami mencoba untuk menata kode proyek dengan cara yang mirip dengan proyek lain sebagai praktis (catatan: praktis, tidak dengan cara yang dilarang keras yang mungkin tidak sesuai sepanjang waktu) dan pada dasarnya kami mencoba membuat pedoman standar yang dapat dimodifikasi sesuai kebutuhan.

Singkatnya - mereka berada di sana untuk membantu kita bekerja sama, bukan sebagai seperangkat aturan ketat yang selalu harus harus diikuti.

Peringatan: Pragmatisme di bawah ini - Pertanyaan ini sepertinya diucapkan untuk mendatangkan perdebatan tentang gaya kurung kurawal yang "tepat", dll. Saya tidak mau membuang-buang waktu untuk omong kosong itu.

1. Instal ReSharper , biarkan default, lakukan apa yang dikatakannya.

2. Keuntungan - Semua orang di tim Anda akan memiliki gaya yang sama yang akan sangat dekat dengan pedoman Microsoft, hanya menyimpang pada beberapa poin di mana standar Resharper mencerminkan apa yang sebenarnya lebih banyak digunakan dalam industri dan merupakan perbaikan (yang bisa dibilang).

Semakin sedikit waktu yang dihabiskan tim Anda untuk membuat dan mereferensikan beberapa dokumen atau buku besar, atau mengoceh tentang curly bracesananities lainnya, semakin banyak pengkodean yang akan mereka lakukan. ReSharper akan memberlakukan penamaan dan gaya saat mereka mengetik. Selesai Akhir dari perdebatan. Tidak ada yang tersisa untuk diperdebatkan. Bergerak.

Yang mengatakan, membaca Kode Lengkap klasik , akan membantu mereka memahami alasan di balik standar pengkodean, dan menawarkan banyak petunjuk bagus untuk secara efektif menyampaikan makna melalui kode - sesuatu yang tidak dapat dilakukan oleh dokumen standar atau program inspeksi.

Jika Anda ingin meningkatkan apa yang dapat dilakukan resharper untuk Anda, tambahkan StyleCop dengan StyleCop untuk plug-in ReSharper. Seperti disebutkan akan ada beberapa konflik kecil antara pedoman MS dan standar ReSharper. Saya hanya akan pergi dengan ReSharper pada mereka. Tapi sisi mana pun yang Anda ambil, simpan saja hasilnya ke file konfigurasi ReSharper, bagikan di seluruh tim Anda dan selesai.

(Tidak, saya bukan pemudi bayaran untuk ReSharper, hanya pelanggan yang bahagia. Selain banyak fitur lainnya, ia menangani masalah gaya dasar dengan biaya lebih efektif daripada dokumen standar atau sistem peninjauan kode - meninggalkan kekuatan otak untuk hal-hal yang penting .)