Bir C # kodlama standartları / en iyi uygulamalar belgesi geliştirmek için herhangi bir öneriniz var mı? [kapalı]

Ben mütevazı bir operasyon için çalışan yakın zamanda AI mezunuyum (yaklaşık 2 yıl). Temel bir (yararlı okumak?) C # kodlama standartları belgesi oluşturmak bana (öncelikle bölümdeki ilk 'benimseyen' olduğum gibi) düştü.

Sanırım muhtemelen en genç yazılım mühendisi olduğumu açıklamalıyım, ama umarım bu görevi yarı yarıya kullanılabilir bir şey üretebileceğim için sabırsızlıkla bekliyorum. İnternette oldukça kapsamlı bir arama yaptım ve bir kodlama standartları belgesinin ne içermesi / içermemesi gerektiğiyle ilgili makaleleri okudum. Bu bazı öneriler için sormak için herhangi bir yer olarak iyi gibi görünüyor.

Potansiyel olarak 'bir şeyler yapmanın en iyi yolu' ile ilgili tüm anlaşmazlık dünyasına kapı açtığımı fark ettim. Her programcının her bir görevi çözmek için tercih edilen bir yöntemi olduğu yadsınamaz gerçeği hem anlıyorum hem de saygı duyuyorum, sonuç olarak kişisel yetenekleri bastırmak için o kadar acımasız bir şey yazmak istemiyorum, ancak genel bir metodoloji ve anlaşmaya varmak için bireylerin daha okunabilir hale getirilmesine yardımcı olmak için standartlar (örneğin adlandırma kuralları).

Yani işte .... herhangi bir öneriniz var mı? Hiç?

İle başlıyoruz

• Microsoft'un .NET yönergeleri: http://msdn.microsoft.com/en-us/library/ms229042.aspx (.NET 4.5 için bağlantı güncellendi)
• Microsoft'un C # yönergeleri: http://blogs.msdn.com/brada/articles/361363.aspx .

ve ardından bu taban çizgisinden farkları ve bu taban çizgisine yapılan eklemeleri belgeleyin.

IDesign , yaygın olarak kullanılan bir C # kodlama standartları belgesine sahiptir. Ayrıca bkz. Çerçeve Tasarım Yönergeleri 2. Baskı .

İronik olarak, gerçek standartları belirlemek kolay bir parça olabilir.

İlk önerim, diğer mühendislerden nelerin kapsanması gerektiğini ve hangi yönergelerin önemli olduğunu düşündükleri konusunda öneriler almak olacaktır. Her türlü yönergeyi uygulamak, insanlardan bir dereceye kadar satın almayı gerektirir. Aniden üzerlerine kod yazmayı belirten bir belge bırakırsanız, en küçük ya da yaşlı bir adam olsanız da dirençle karşılaşırsınız.

Bir dizi teklifiniz olduğunda, geri bildirim ve inceleme için bunları ekibe gönderin. Yine, insanların hepsini satın almasını sağlayın.

Kabul edilmiş olan gayri resmi kodlama uygulamaları olabilir (örn. Üye değişkenleri, deve işlevi isimlerinin önekleri). Bu mevcutsa ve çoğu kod buna uygunsa, kullanımını resmileştirmek için ödeme yapar. Aksine bir standardı benimsemek, genellikle önerilen bir şey olsa bile, değerinden daha fazla keder yaratacaktır.

Ayrıca, yeni kodlama standartlarını karşılamak için mevcut kodu yeniden düzenlemeyi düşünmeye değer. Bu zaman kaybı gibi görünebilir, ancak standartları karşılamayan bir koda sahip olmak, farklı tarzlarda bir püre haline getireceğiniz için karşı üretken olabilir. Ayrıca, belirli bir modüldeki kodun yeni standarda uygun olması veya mevcut kod stilini izlemesi gerekip gerekmediğini ikilemde bırakır.

Hep Juval Lowy'nin kullandık pdf içten kodlama standartları / en iyi uygulamaları yaparken referans olarak. Standardın takip edildiğinden emin olmak için başka bir paha biçilmez araç olan FxCop / Source Analysis'e çok yakındır . Bu araçlar ve referanslar arasında, tüm geliştiricilerin takip etmeyi düşünmeyecekleri ve uygulayabilecekleri güzel bir standart geliştirebilmelisiniz.

Diğer posterler sizi başlangıçta işaret etti, ekleyeceğim tek şey belgenizi kısa, tatlı yapmak ve noktaya, "zorunlulukları" ayırmak için ağır bir Strunk ve Beyaz dozunu kullanmaktır. ".

Standart belgelerin kodlanmasındaki sorun, kimsenin onları olması gerektiği gibi okumaması ve okudukları zaman onları takip etmemesidir. Böyle bir belgenin okunması ve takip edilmesi olasılığı uzunluğuna göre değişir.

FxCop'un iyi bir araç olduğunu kabul ediyorum, ancak çok fazla programlamadan tüm eğlenceyi alabilir, bu yüzden dikkatli olun.

Kendi kodlama standartlarınızı asla MS standartlarını (ya da Sun standartlarını ya da ... dilinize uygun olarak) kullanmayın. İpucu standart kelimedir, eğer her kuruluş kendi adını yazmaya karar vermemiş olsaydı, dünya kodlamak için çok daha kolay bir yer olurdu. Ekipleri / projeleri / rolleri her değiştirdiğinizde yeni bir 'standartlar' seti öğrenmeyi gerçekten düşünen, kimsenin zamanını iyi bir şekilde kullanır. Yapmanız gereken en önemli şey kritik noktaları özetlemektir, ancak bunu yapmamanızı tavsiye ederim çünkü kritik olan şey kişiden kişiye değişir. Kodlama standartlarına değinmek istediğim diğer iki nokta

1. Kapat yeterince iyi - Kodun harf kodlama standartlarına uyması için kodun değiştirilmesi, kod yeterince yakın olduğu sürece zaman kaybıdır.
2. Kodu değiştiriyorsanız, 'yerel kodlama standartlarını' takip etmeyin, yani yeni kodunuzu çevreleyen kod gibi görünmesini sağlayın.

Bu iki nokta, herkesin aynı görünen kodu yazması dileğimin gerçeğidir.

Aşağıdaki belgeleri çok yararlı ve özlü buldum. İdesign.net sitesinden geliyor ve Juval Lowy tarafından yazılıyor.

C # Kodlama Standardı

Dikkat: Yukarıdaki bağlantı artık öldü. Eğer (gerçekten ... ama onlar pazarlama için kullanmak olmaz) onlara e-posta adresinizi vermek gerekir .zip dosyasını almak için deneyin burada

Kodlama standartlarının üye değişkenler için m_, parametreler için p_ ve dizeler için 'str' gibi türlerin öneklerinin kullanılmasını zorunlu kıldığı bir yerde başladım. Yani, bir yöntemin gövdesinde böyle bir şey olabilir:

m_strName = p_strName;

Korkunç. Gerçekten korkunç.

Listeye Code Complete 2'yi eklerdim (Jeff'in burada bir hayran olduğunu biliyorum) ... Eğer küçük bir geliştiriciyseniz, kitap aklınızı en iyi şekilde ayarlayacak şekilde ayarlamak için kullanışlı olur kod yazma uygulamaları ve yazılım oluşturma vardır.

Kariyerime biraz geç geldiğimi söylemeliyim, ancak profesyonel yaşamımda kodlama ve çerçeve geliştirme hakkında düşündüğüm birçok kuralı yönetiyor.

Kontrol etmeye değer;)

Microsoft'un kendi kuralları mükemmel bir başlangıç ​​noktasıdır. Onları FxCop ile uygulayabilirsiniz.

Microsoft'un StyleCop'unu standart olarak uygulamak cazip olurdu. İnşa sırasında uygulanabilir. ancak eski kodunuz varsa, yeni kodda StyleCop kullanmayı zorunlu kılın.

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

Sonunda kodu temizlemek için bir refactor seçeneği olacaktır.

http://blogs.msdn.com/sourceanalysis/

Şahsen IDesign'ın bir araya getirdiği hoşuma gitti . Ama bu yüzden gönderiyorum ...

Şirketimdeki zor bit tüm farklı dilleri hesaba katıyordu. Ve biliyorum ki şirketim bu konuda yalnız değil. C #, C, montaj (cihaz üretiyoruz), SQL, XAML vb. Kullanıyoruz. Standartlarda bazı benzerlikler olsa da, her biri genellikle farklı şekilde ele alınır.

Ayrıca, daha yüksek seviye standartların nihai ürünün kalitesi üzerinde daha büyük bir etkiye sahip olduğuna inanıyorum. Örneğin: yorumları nasıl ve ne zaman kullanacağınız, istisnalar zorunlu olduğunda (örn. Kullanıcı tarafından başlatılan olaylar), istisnaların döndürülmesine karşı değerlerinin kullanılıp kullanılmayacağı (veya ne zaman kullanılacağı), denetleyici koduna karşı sunum kodunun ne olması gerektiğini belirlemenin nesnel yolu nedir, Beni yanlış anlamayın, düşük seviyeli standartlar da gereklidir (biçimlendirme okunabilirlik açısından önemlidir!) Sadece genel yapıya karşı bir önyargım var.

Akılda tutulması gereken bir başka parça da katılım ve uygulamadır. Kodlama standartları mükemmeldir. Ama kimse onlarla aynı fikirde değilse ve (muhtemelen daha da önemlisi) kimse onları zorlamazsa, hepsi boşa çıkar.

Hem Philips Medical Systems için yayınlanan hem de http://csharpguidelines.codeplex.com adresinde yazdığım gibi biraz önyargılı olabilirim, ancak kodlama standartlarının yazımı, bakımı ve tanıtımı konusunda 10 yıldan fazla zamanım var. Düşüncelerindeki farklılıklar göz önünde bulundurularak bir CodePlex'i yazmaya çalıştım ve girişinizin çoğunu kendi kuruluşunuzda bununla nasıl başa çıkacağınıza harcadım. Oku ve bana geri bildirimde bulunun .....

SSW Kuralları

Bazı C # standartları + çok daha fazlasını içerir .... öncelikle Microsoft geliştiricilerine odaklanmış

Büyük olasılıkla başarısızlığa ayarlanmışsınızdır. Sektöre hoş geldiniz.

Kabul etmiyorum - belgeyi oluşturduğu sürece, olabilecek en kötü şey herkes tarafından unutulmasıdır.

Diğer kişilerin içerikle ilgili sorunları varsa, onlardan tercih ettiklerini göstermek için güncellemelerini isteyebilirsiniz. Bu şekilde tabağınızdan çıkar ve diğerleri değişikliklerini haklı çıkarma sorumluluğuna sahiptir.

Kısa süre önce diğer birçok kaynaktan (IDesign, Philips, MSDN) fikirler içeren Encodo C # El Kitabı'nı buldum .

Başka bir kaynak Profesyonel C # / VB .NET Kodlama Yönergeleri olabilir .

Francesco Balena " VB ve C # Geliştiricileri için Pratik Yönergeler ve En İyi Uygulamalar " kitabının büyük bir hayranıyım .

Çok detaylı ve tüm önemli konuları kapsar, Sadece kuralı vermez, aynı zamanda kuralın arkasındaki nedeni açıklar ve hatta iki karşıt en iyi uygulamanın olabileceği bir anti-kural sağlar. Tek dezavantajı, .NET 1.1 geliştiricileri için yazılmış olmasıdır.

Tüm kodlama standardımız kabaca "StyleCop Kullan" ı okur.

Bkz . Http://www.noesispedia.com/post/2008/11/28/C-Coding-Guidelines-and-Best-Practices.aspx .

Ben önermek zorunda dotnetspider.com belgesini.
Her yerde yararlı olan harika ve ayrıntılı bir belgedir.

Daha önce Juval'ın kullandım ve aşırıya kaçmazsa, ama tembelim ve şimdi sadece Resharper'ın iradesine uyuyorum .

Bunu kontrol edebilirsiniz, C # /. NET Geliştiricileri için En İyi 7 Kodlama Standartları ve Kılavuz Belgeler http://www.amazedsaint.com/2010/11/top-6-coding-standards-guideline.html bunun umarım

Ben zaten bağlı MS kılavuzları mükemmel bir başlangıç ​​noktası olduğunu burada diğer yorumları yankı düşünüyorum. Kodumu büyük ölçüde bunlara göre şekillendiriyorum.

Bu ilginç çünkü yöneticim geçmişte bana çok hevesli olmadığını söyledi: D

Önünüzde eğlenceli bir görev var arkadaşım. İyi şanslar ve daha fazlasına ihtiyacınız olup olmadığını sorun :)

Philips Medical Systems standardı iyi yazılmıştır ve çoğunlukla Microsoft yönergelerini takip eder: www.tiobe.com/content/paperinfo/gemrcsharpcs.pdf

Standartlarımda birkaç değişiklik ve .NET 2.0 için bazı güncellemeler temel alınmıştır (Philips standardı .NET 1.x için yazılmıştır, bu yüzden biraz tarihli).

Resharper'ı da takip ediyorum. Ayrıca scott guthrie blogunda belirtilen kılavuz satırı http://weblogs.asp.net/scottgu/archive/2007/10/08/october-8th-links-asp-net-asp-net-ajax-silverlight-and-net .aspx Ve http://csharpguidelines.codeplex.com/releases/view/46280.

Yazdığım kodda genellikle halka açık API'lar için .NET Framework Tasarım Yönergeleri ve özel üye muhafazası ve girintileri için Mono Kodlama Yönergeleri'ni uygularım . Mono, .NET'in açık kaynaklı bir uygulamasıdır ve bence bu adamlar işlerini biliyorlar.

Microsoft kodunun nasıl yer kapladığından nefret ediyorum:

try
{
    if (condition)
    {
        Something(new delegate
        {
            SomeCall(a, b);
        });
    }
    else
    {
        SomethingElse();
        Foobar(foo, bar);
    }
}
catch (Exception ex)
{
    Console.WriteLine("Okay, you got me");
}

Mono yönergelerinde garip bulabileceğiniz şey, 8 boşluklu sekmeler kullanmalarıdır. Ancak, bazı uygulamalardan sonra, aslında bir tür girinti sınırı uygulayarak daha az karışık kod yazmama yardımcı olduğunu buldum.

Ayrıca parantez açmadan önce nasıl boşluk bıraktıklarını da seviyorum.

try {
        if (condition) {
                Something (new delegate {
                        SomeCall (a, b);
                });
        } else {
                SomethingElse ();
                Foobar (foo, bar);
        }
} catch (Exception ex) {
        Console.WriteLine ("Okay, you got me");
}

Ama lütfen, iş arkadaşlarınız hoşlanmıyorsa (Mono ;-) 'a katkıda bulunmak istemiyorsanız) böyle bir şey uygulamayın.