.NET/C # projeleri için hangi kodlama standartlarının önemli olduğunu düşünüyorsunuz? Bu, kıvırcık parantezlerle uğraşmak ve bunun gibi boşluk ve bilgiçlikle uğraşmaktan herhangi bir şey olabilir. Veya .NET Framework'te hangi ad alanlarından kaçınılması, yapılandırma dosyalarıyla en iyi uygulamalar vb. Gibi daha temel sorular olabilir.
Bir başkasının sonucu olan bir yazı oluşturmaktan kaçının. Örneğin, bir direk kıvırcık ayraçlara odaklanmak iyi olur. Bir stili diğerine karşı desteklemek için ikiye ihtiyacımız yok. Fikir, evcil hayvanınızın standardına oy vermek değil, standartlar oluştururken nelere dikkat edilmesi gerektiğini belirtmektir.
1.1 için daha eski bir sürüm istiyorsanız here deneyin.
Dedikleri gibi, bunu mutlaka bir 'T'ye takip etmem. Ancak, şüphe duyduğunuzda, bu, mevcut projenizle tutarlı olmaya başlamak için en iyi yerdir, bu da projeniz için yeni olup olmadıklarına bakılmaksızın herkesi kolaylaştırır.
StyleCop adresine bakmak isteyebilirsiniz. Stil hatalarının derlemeyi bozması için bazı derleme sistemlerine bile dahil edebilirsiniz. Varsayılan ayarlar çoğunlukla MS'in yönergeler için önerdiklerine (başkaları tarafından gönderilen şekilde) uygundur.
Varsayılan olarak birlikte gelen kuralları da değiştirebilirsiniz.
Microsoft yönergeleri:
Bunu ofisimizde kabul ettik. Lance Hunt tarafından yazılmıştır ve oldukça kapsamlıdır:
FxCop ile başlayın. Mevcut kodunuzdaki en iyi uygulama ihlallerinden bahsedecektir.
SSW (Avustralya Danışmanlık şirketi) tarafından sunulan standartları önermem gerekiyor.
Sadece kodlama değil, Proje Yönetimi vs ... İnanılmaz derecede değerli bir kaynak.
Yöntemler kısa olmalı
Çoğu yöntem bir sınıftaki çoğu alanı kullanmalıdır.
İsimlerinizi iyi seçin.
Örneğin, Temiz Kod kitabını okuyun
Camelback kuralları, yöntem adı vb.'nin yanı sıra bir kodlama standardını korumak için aşağıdaki uygulamaları kullanıyorum.
GhostDoc - Her yöntemin üzerine otomatik olarak oluşturulan bir yorum ekler. Uygulama yöntemin iyi bir inital özeti sağlar. (Bedava)
Yeniden Paylaşıcı - kod analizi ve yeniden düzenleme http://www.jetbrains.com/resharper/
StyleCop - TFS'ye giriş yapmadan önce son temizlik olarak. (Bedava)
Çeşitli kaynaklardan ortak bir stil kümesi seçmeye çalışıyorum. Daha önce bahsedilmeyen bazıları:
Belirlenmiş kodlama standartlarından nefret ediyorum, hepsi ya birkaç aptalca hata yapmamanızı ya da kodunuzu bir şekilde nasıl biçimlendireceğinizi anlatmakla ilgileniyor. Hepsi önemsiz şeyler.
Yani, operatörler arasında kaç boşluk bırakılacağını, değişkenlerinizi nasıl ele alacağınızı, hangi 'macarca tarzı' önekleri kullanacağınızı (örneğin üyeler için _), çelişkili tavsiyeleri (örneğin, bir sınıf Cxyz diyemezsiniz, ancak = must bir arayüz Ixyz çağırın), kodunuzu nasıl düzenleyeceğinizi (değişkeninizi sınıfın üstüne veya altına koyun)
Büyük resimde hepsi işe yaramaz.
Etkili, sürdürülebilir ve okunabilir kod yazmak için önemli olan bu standartlarda asla belirtilmez.
Örneğin: değişkenlerinizi sınıfınızın üstüne mi altına mı koyarsınız? Kimin umurunda - önemli olan, değişkenlerinizi fonksiyonel alana göre gruplandırmanızdır. Bu önemli (yer hakkında dağınık 20 değişken gördüyseniz bunu bileceksiniz).
Kıvırcık parantezlerinizi belirli yerlere koymanızı söylüyorlar. Önemli! K & R ve ANSI tarzı basamaklamada kodu okuyabilirim, önemli değil. Önemli olan, tüm Window sınıflarının bir şekilde farklılaştırılmasıdır (Form veya Dlg veya herhangi bir şekilde sonek gibi), böylece hangi dosyaların pencere kodu içerdiğini ve hangilerinin sıradan nesneler olduğunu görebilirsiniz.
Bunun gibi şeyler, standartların genellikle içerdiği küçük noktalardan çok daha önemlidir. Neden böyle geliştiklerini bilmiyorum, ancak genellikle etkili ve üretken kodlamaya engel olan bir ton kural.
Standartlarım daha çok kod ve dosyaların organizasyonuna odaklanmaya çalışıyor. Dosyaların nerede bulunacağına ilişkin belirli standartlarımız var. Örneğin, geliştirici olmayan çocuklar projelerimizden birine bakabilir ve hemen ihtiyaç duydukları belge dosyalarını alabilirler. Benzer şekilde, proje kodunu pratik olarak diğer projelere benzer şekilde düzenlemeye çalışırız (not: pratik olarak, her zaman uygun olmayabilecek ağır yasaklanmış bir şekilde değil) ve temel olarak gerektiğinde değiştirilebilir.
Kısacası - her zaman have takip edilmesi gereken bir dizi kısıtlayıcı kural olarak değil, birlikte çalışmamıza yardımcı olmak için oradalar.
Uyarı: Aşağıdaki Pragmatizm - Soru, "uygun" kıvırcık küme ayracı stili, vb. Hakkındaki tartışmayı ortaya çıkarmak gibi görünüyor. bu saçmalıkta zaman kaybetmek.
ReSharper yükleyin, varsayılanları bırakın, ne derse yapın.
Kâr - Ekibinizdeki herkes, Microsoft kurallarına çok yakın olacak aynı stile sahip olacak, yalnızca Resharper standartlarının endüstride daha yaygın olarak kullanılanları yansıttığı ve (tartışmalı olarak) iyileştirmeler yaptığı birkaç noktadan sapacaktır.
Ekibiniz, bazı komik belgeleri veya kitapları oluşturup referans göstererek veya
curly braces ve diğer inançlar, onlar daha fazla kodlama yapılır. ReSharper, yazarken adlandırma ve stili zorlar. Bitti. End-of-tartışma. Tartışacak bir şey kalmadı. Hareketli.
Bununla birlikte, klasik bir okuma Kod Tamamlandı , kodlama standartlarının arkasındaki mantığı anlamalarına yardımcı olacak ve anlamı kod aracılığıyla etkili bir şekilde iletmek için birçok büyük işaret sunacaktır - standart bir belge veya denetim programının yapamayacağı bir şey .
Yeniden paylaşıcının sizin için yapabileceklerini artırmak istiyorsanız, ReSharper için StyleCop eklentisine StyleCop ekleyin. Belirtildiği gibi, MS yönergeleri ile ReSharper varsayılanları arasında birkaç küçük çakışma olacaktır. Bunlara ReSharper ile giderdim. Ancak hangi tarafı alırsanız alın, sonuçları ReSharper yapılandırma dosyasına kaydedin, ekibiniz arasında paylaşın ve işinizi tamamlayın.
(Hayır, ReSharper için ücretli bir şilte değilim, sadece mutlu bir müşteri. Diğer birçok özelliğinin yanı sıra, kolları temel stil sorunları herhangi bir standart belge veya kod inceleme sisteminden daha maliyet etkin - beyin gücü önemli şeyler için bırakarak.)