Sınıflardaki öğelerin sırası: Alanlar, Özellikler, Yapıcılar, Yöntemler

Sınıf yapısı bakımından öğelerin sıralaması için resmi bir C # kılavuzu var mı?

Gidiyor mu:

• Genel Alanlar
• Özel Alanlar
• Özellikleri
• Kurucular
• Yöntemler
  ?

Öğelerin sırası hakkında zor ve hızlı bir kural olup olmadığını merak ediyorum? Ben her yerdeyim. Her yerde yapabilmek için belirli bir standarda bağlı kalmak istiyorum.

Asıl sorun, daha karmaşık özelliklerimin çok benzer yöntemlere benzemesi ve kurucudan önce en üstte yersiz hissetmeleri.

Herhangi bir ipucu / öneriniz var mı?

StyleCop Kuralları Belgelerine Göre sipariş olarak takip olduğunu.

Bir sınıf, yapı veya arayüz içinde: (SA1201 ve SA1203)

• Sabit Alanlar
• Alanlar
• Kurucular
• Finalizörler (Yıkıcılar)
• Delegeler
• Etkinlikler
• Sıralamalar
• Arayüzler ( arayüz uygulamaları )
• Özellikleri
• Dizinleyiciler
• Yöntemler
• yapılar
• Sınıflar

Bu grupların her birinde erişime göre sipariş verin: (SA1202)

• halka açık
• iç
• iç korumalı
• korumalı
• özel

Erişim gruplarının her birinde statik, ardından statik olmayanlara göre sıralayın: (SA1204)

• statik
• statik olmayan

Statik / statik olmayan alan gruplarının her birinde, önce okunur, sonra salt okunur olarak sipariş verin: (SA1214 ve SA1215)

• Sadece oku
• olmayan salt okunur

Kaydedilmemiş bir liste 130 satır uzunluğunda, bu yüzden burada açmayacağım. Unrolled yöntemleri parçası:

• halka açık statik yöntemler
• halka açık yöntemler
• iç statik yöntemler
• dahili yöntemler
• korumalı dahili statik yöntemler
• korumalı dahili yöntemler
• korumalı statik yöntemler
• korunan yöntemler
• özel statik yöntemler
• özel yöntemler

Belgeler, öngörülen sipariş uygun değilse (örneğin, birden çok arabirimin uygulandığını ve arabirim yöntemlerinin ve özelliklerinin birlikte gruplandırılması gerektiğini), ilgili yöntemleri ve özellikleri birlikte gruplandırmak için kısmi bir sınıf kullandığını not eder.

Görünürlük veya öğe türüne (alan, özellik, yöntem vb.) Göre gruplamak yerine işlevselliğe göre gruplamaya ne dersiniz?

Bu eski ama yine de çok alakalı bir soru, bu yüzden şunu ekleyeceğim: Daha önce okuduğunuz veya okumadığınız bir sınıf dosyasını açtığınızda aradığınız ilk şey nedir? Alanlar? Özellikleri? Deneyimden, neredeyse her zaman kurucuları avlamaya başladığımı fark ettim, çünkü anlayacak en temel şey bu nesnenin nasıl inşa edildiği.

Bu nedenle, yapıcıları sınıf dosyalarında ilk sıraya koymaya başladım ve sonuç psikolojik olarak çok olumlu oldu. Yapıcıları bir sürü başka şeyden sonra koymanın standart önerisi uyumsuz hissediyor.

C # 6'daki yaklaşan birincil kurucu özelliği, bir kurucu için doğal yerin bir sınıfın en üstünde olduğuna dair kanıt sağlar - aslında birincil kurucular açık ayraçtan önce bile belirtilir.

Böyle bir siparişin ne kadar fark yarattığı komik. İlk usingönce Sistem ad alanlarıyla birlikte, ifadelerin nasıl sipariş edildiğini hatırlatıyor . Visual Studio'nun "Düzenlemeleri Kullan" komutu bu sırayı kullandı. Şimdi usings sadece alfabetik olarak sıralanmıştır, Sistem ad alanlarına özel bir işlem yapılmaz. Sonuç daha basit ve daha temizdir.

Bir dil veya endüstri standardı hakkında bir bilgim yok, ancak her bölümde bir #region ile sarılmış olan şeyleri bu sıraya koyma eğilimindeyim:

İfadeler kullanma

Ad alanı

Sınıf

Özel üyeler

Genel mülkler

Kurucular

Genel yöntemler

Özel yöntemler

IDesign'dan veya Brad Abram'ın web sitesinde listelenenlerden kodlama standartlarını kullanmanızı tavsiye ederim . Bunlar bulduğum en iyi ikisi.

Brad der ki ...

Sınıf üyesi alfabetik olmalı ve bölümler halinde gruplandırılmalıdır (Alanlar, Yapıcılar, Özellikler, Olaylar, Yöntemler, Özel arayüz uygulamaları, Yuvalanmış türler)

Daha önce de belirtildiği gibi, C # dilinde düzeni belirleyen hiçbir şey yok, ben şahsen bölgeleri kullanıyorum ve ortalama bir sınıf için böyle bir şey yapıyorum.

public class myClass
{
#region Private Members

#endregion
#region Public Properties

#endregion

#region Constructors

#endregion
#region Public Methods

#endregion
}

Zaten bana mantıklı geliyor

StyleCop'tan

özel alanlar, ortak alanlar, kurucular, özellikler, genel yöntemler, özel yöntemler

StyleCop, MS derleme sürecinin bir parçası olduğundan, bunu fiili bir standart olarak görebilirsiniz

Genellikle bir sonraki kalıbı takip etmeye çalışırım:

• statik üyeler (genellikle başka bir bağlamı vardır, iş parçacığı açısından güvenli olmalıdır vb.)
• yönetim ortamı üyeleri

Her bölüm (statik ve örnek) aşağıdaki üye türlerinden oluşur:

• operatörler (daima statiktir)
• alanlar (kuruculardan önce başlatıldı)
• kurucular
• yıkıcı ( yapıcıları takip etme geleneğidir) )
• özellikleri
• yöntemleri
• Etkinlikler

Ardından üyeler görünebilirliğe göre sıralanır (daha azdan daha görünüre):

• özel
• iç
• dahili korumalı
• korumalı
• halka açık

Sıra bir dogma değildir: basit sınıfların okunması daha kolaydır, ancak daha karmaşık sınıfların bağlama özgü gruplandırmaya ihtiyacı vardır.

Benim tercihim, türüne göre sipariş vermek ve daha sonra görünürlüğü azaltmaktır.

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

Bunun Style Cop'ı ihlal ettiğini biliyorum ve eğer birisi bana bir türün uygulama ayrıntılarını arayüzünden önce yerleştirmem için iyi bir neden verebilirse değiştirmek istiyorum. Şu anda, özel üyeleri son tutmaya yönelik güçlü bir tercihim var.

Not: Herkese açık veya korunan alanları kullanmıyorum.

Bulabileceğiniz en yakın şey Brad Abrams tarafından "Tasarım Yönergeleri, Yönetilen kod ve .NET Framework" dür ( http://blogs.msdn.com/brada/articles/361363.aspx ).

Burada birçok standart belirtilmiştir. İlgili bölüm 2.8 sanırım.

bunun için önerdiğim tek kodlama yönergeleri alanları sınıf tanımının en üstüne koymaktır.

sonra inşaatçılar koymak eğilimindedir.

genel yorumum, dosya başına bir sınıfa bağlı kalmanız ve sınıfın yöntemlere karşı özelliklerin organizasyonu büyük bir endişe olacak kadar büyükse, sınıfın büyüklüğü nedir ve yine de yeniden düzenlemelisiniz? birden fazla endişeyi temsil ediyor mu?

Özel alanları yapıcılarla birlikte en üste koymayı, sonra genel arabirim bitlerini, sonra özel arabirim bitlerini koymayı tercih ederim.

Ayrıca, sınıf tanımınız, öğelerin siparişinin çok önemli olması için yeterince uzunsa, muhtemelen sınıfınızın çok hantal ve karmaşık olduğunu gösteren bir kod kokusudur ve refactor olmalısınız.

Mümkün olduğunca basit tutuyorum (en azından benim için)

Numaralandırma
Bildirimleri
Oluşturucular
Geçersiz Kılma
Yöntemleri
Özellikler
Olay İşleyici

Dilde kesinlikle onu hiçbir şekilde uygulayan hiçbir şey yoktur. Nesneleri görünürlüğe göre gruplama eğilimindeyim (herkese açık, sonra korunan, sonra özel) ve bir özelliği, yöntemi veya herhangi bir şey olup olmadığına bakılmaksızın #regions'ı ilgili şeyleri işlevsel olarak gruplandırmak için kullanıyorum. İnşaat yöntemleri (gerçek ctorlar veya statik fabrika fonksiyonları olsun), müşterilerin en çok bilmesi gereken ilk şey oldukları için genellikle en üstte yer alır.

Bu eski olduğunu biliyorum ama benim sipariş aşağıdaki gibidir:

kamu düzeninde, korunan, özel, iç, soyut

• Sabitler
• Statik Değişkenler
• Alanlar
• Etkinlikler
• Oluşturucu (lar)
• Yöntemler
• Özellikleri
• Delegeler

Ben de (stenografi yaklaşımı yerine) böyle özellikler yazmayı seviyorum

// 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; }
}