Urutan item dalam kelas: Bidang, Properti, Konstruktor, Metode

Apakah ada pedoman C # resmi untuk urutan item dalam hal struktur kelas?

Apakah itu pergi:

• Bidang Publik
• Bidang Pribadi
• Properti
• Konstruktor
• Metode
  ?

Saya ingin tahu apakah ada aturan yang keras dan cepat tentang urutan barang? Aku agak di semua tempat. Saya ingin tetap dengan standar tertentu sehingga saya bisa melakukannya di mana saja.

Masalah sebenarnya adalah properti saya yang lebih kompleks akhirnya tampak sangat mirip metode dan mereka merasa tidak pada tempatnya di atas sebelum konstruktor.

Ada tips / saran?

Menurut Dokumentasi Aturan StyleCop pemesanan adalah sebagai berikut.

Di dalam kelas, struct atau antarmuka: (SA1201 dan SA1203)

• Bidang Konstan
• Bidang
• Konstruktor
• Finalizers (Destructors)
• Delegasi
• Acara
• Enum
• Antarmuka ( implementasi antarmuka )
• Properti
• Pengindeks
• Metode
• Structs
• Kelas

Dalam masing-masing kelompok ini pesan melalui akses: (SA1202)

• publik
• intern
• internal terlindungi
• terlindung
• pribadi

Di dalam masing-masing grup akses, pesan dengan statis, kemudian non-statis: (SA1204)

• statis
• tidak statis

Dalam masing-masing grup bidang statis / non-statis, pesan dengan hanya-baca, kemudian tidak-baca: (SA1214 dan SA1215)

• dibaca saja
• tidak dibaca

Daftar yang belum dibuka adalah 130 baris, jadi saya tidak akan membuka gulungannya di sini. Bagian metode yang belum dibuka adalah:

• metode statis publik
• metode publik
• metode statis internal
• metode internal
• metode statis internal yang dilindungi
• metode internal yang dilindungi
• metode statis terlindungi
• metode yang dilindungi
• metode statis pribadi
• metode pribadi

Dokumentasi mencatat bahwa jika urutan yang ditentukan tidak sesuai - katakanlah, banyak antarmuka sedang dilaksanakan, dan metode dan properti antarmuka harus dikelompokkan bersama - kemudian gunakan kelas parsial untuk mengelompokkan metode dan properti terkait bersama-sama.

Daripada mengelompokkan berdasarkan visibilitas atau berdasarkan jenis item (bidang, properti, metode, dll.), Bagaimana dengan pengelompokan berdasarkan fungsionalitas?

Ini adalah pertanyaan lama tetapi masih sangat relevan, jadi saya akan menambahkan ini: Apa hal pertama yang Anda cari ketika Anda membuka file kelas yang mungkin Anda baca atau belum baca? Bidang? Properti? Saya telah menyadari dari pengalaman bahwa hampir selalu saya pergi berburu untuk konstruktor, karena hal yang paling mendasar untuk dipahami adalah bagaimana objek ini dibangun.

Oleh karena itu, saya mulai menempatkan konstruktor sebagai yang pertama di file kelas, dan hasilnya secara psikologis sangat positif. Rekomendasi standar menempatkan konstruktor setelah banyak hal lain terasa disonan.

Fitur konstruktor primer yang akan datang dalam C # 6 memberikan bukti bahwa tempat alami untuk konstruktor berada di bagian paling atas kelas - sebenarnya konstruktor primer ditentukan bahkan sebelum kurung buka.

Sangat lucu betapa banyak perbedaan penataan ulang seperti ini. Ini mengingatkan saya pada bagaimana usingpernyataan yang digunakan dipesan - dengan System namespaces terlebih dahulu. Perintah "Atur Penggunaan" Visual Studio menggunakan pesanan ini. Sekarang usinghanya dipesan secara alfabet, tanpa perlakuan khusus yang diberikan untuk ruang nama Sistem. Hasilnya hanya terasa lebih sederhana dan bersih.

Saya tidak tahu tentang standar bahasa atau industri, tetapi saya cenderung untuk meletakkan berbagai hal dalam urutan ini dengan setiap bagian terbungkus dalam #region:

menggunakan Pernyataan

Namespace

Kelas

Anggota pribadi

Properti publik

Konstruktor

Metode publik

Metode pribadi

Saya akan merekomendasikan menggunakan standar pengkodean dari IDesign atau yang terdaftar di situs web Brad Abram . Itu adalah dua yang terbaik yang saya temukan.

Brad akan mengatakan ...

Anggota kelas harus diurutkan berdasarkan abjad, dan dikelompokkan menjadi beberapa bagian (Bidang, Konstruktor, Properti, Acara, Metode, implementasi antarmuka pribadi, tipe bersarang)

Seperti disebutkan sebelumnya tidak ada dalam bahasa C # yang menentukan tata letak, saya pribadi menggunakan daerah, dan saya melakukan sesuatu seperti ini untuk kelas rata-rata.

public class myClass
{
#region Private Members

#endregion
#region Public Properties

#endregion

#region Constructors

#endregion
#region Public Methods

#endregion
}

Masuk akal bagi saya juga

Dari StyleCop

bidang pribadi, bidang publik, konstruktor, properti, metode publik, metode pribadi

Karena StyleCop adalah bagian dari proses pembuatan MS, Anda dapat melihatnya sebagai standar de facto

Biasanya saya mencoba mengikuti pola berikut:

• anggota statis (biasanya memiliki konteks lain, harus aman thread, dll.)
• anggota contoh

Setiap bagian (statis dan instance) terdiri dari jenis anggota berikut:

• operator (selalu statis)
• bidang (diinisialisasi sebelum konstruktor)
• konstruktor
• destructor ( adalah tradisi untuk mengikuti konstruktor )
• properti
• metode
• acara

Kemudian anggota diurutkan berdasarkan visibilitas (dari kurang ke lebih terlihat):

• pribadi
• intern
• dilindungi internal
• terlindung
• publik

Urutannya bukan dogma: kelas sederhana lebih mudah dibaca, namun, kelas yang lebih kompleks membutuhkan pengelompokan khusus konteks.

Preferensi saya adalah memesan berdasarkan jenis dan kemudian mengurangi visibilitas sebagai berikut

public methods
public events
public properties

protected methods
protected events
protected properties

private methods
private events
private properties
private fields

public delegates
public interfaces
public classes
public structs

protected delegates
protected interfaces
protected classes
protected structs

private delegates
private interfaces
private classes
private structs

Saya tahu ini melanggar Style Cop dan jika seseorang dapat memberi saya alasan yang bagus mengapa saya harus menempatkan detail implementasi jenis sebelum antarmuka, saya bersedia mengubah. Saat ini, saya memiliki preferensi yang kuat untuk menempatkan anggota pribadi yang terakhir.

Catatan: Saya tidak menggunakan bidang publik atau yang dilindungi.

Yang paling mungkin Anda temukan adalah "Pedoman Desain, Kode Terkelola dan .NET Framework" ( http://blogs.msdn.com/brada/articles/361363.aspx ) oleh Brad Abrams

Banyak standar diuraikan di sini. Bagian yang relevan adalah 2,8 saya pikir.

satu-satunya pedoman pengkodean yang saya lihat disarankan untuk ini adalah meletakkan bidang di bagian atas definisi kelas.

saya cenderung menempatkan konstruktor berikutnya.

komentar umum saya adalah bahwa Anda harus tetap berpegang pada satu kelas per file dan jika kelasnya cukup besar sehingga organisasi properti versus metode menjadi perhatian besar, seberapa besar kelasnya dan haruskah Anda refactoring? apakah itu mewakili beberapa masalah?

Saya lebih suka menempatkan bidang pribadi di bagian atas bersama dengan konstruktor, kemudian menempatkan bit antarmuka publik setelah itu, kemudian bit antarmuka pribadi.

Juga, jika definisi kelas Anda cukup lama untuk memesan barang menjadi penting, itu mungkin bau kode yang menunjukkan kelas Anda terlalu besar dan kompleks dan Anda harus refactor.

Saya menyimpannya sesederhana mungkin (setidaknya untuk saya)

Enumerasi
Deklarasi
Konstruktor
Mengesampingkan
Metode
Properties
Event Handler

Tentu saja tidak ada dalam bahasa yang memberlakukannya dengan cara apa pun. Saya cenderung mengelompokkan berbagai hal berdasarkan visibilitas (publik, kemudian dilindungi, kemudian pribadi) dan menggunakan #region untuk mengelompokkan hal-hal terkait secara fungsional, terlepas dari apakah itu properti, metode, atau apa pun. Metode konstruksi (apakah fungsi sebenarnya atau fungsi pabrik statis) biasanya tepat di atas karena mereka adalah hal pertama yang perlu diketahui klien.

Saya tahu ini sudah lama tetapi pesanan saya adalah sebagai berikut:

dalam urutan publik, dilindungi, pribadi, internal, abstrak

• Konstanta
• Variabel statis
• Bidang
• Acara
• Konstruktor
• Metode
• Properti
• Delegasi

Saya juga suka menulis properti seperti ini (bukan pendekatan steno)

// Some where in the fields section
private int someVariable;

// I also refrain from
// declaring variables outside of the constructor

// and some where in the properties section I do
public int SomeVariable
{
    get { return someVariable; }
    set { someVariable = value; }
}