İyi (okuma: faydalı) bir kodlama standardında neler olmalıdır?
Yanıtlar:
Her gereksinimin bir nedeni. Bu şekilde, standardın izlenmesi bir tür kargo kültü haline gelmez ve insanlar, sebebi artık geçerli değilse, standardı değiştirmenin veya standardın ihlal etmediği durumlarda, standardın ihlal edilmesinin uygun olmadığını bilirler. .
Tablar vs Uzay! Meslektaşlarımdan biri yanlışlıkla depoya geçiş alanlarına birçok sekme gönderdiğinde çılgınca güncellemeler alıyorum
Adlandırma Kuralları
DÜZENLE: Bununla, Kurallara ad vermeyi değil, Kurallara ad vermeyi kastediyorum.
Örneğin, bir Rehber olacaktır All boolean values should begin with Is/Can/Has/etc when possible. Bir kural olurduAll boolean values must start with Is
IsCanUpdateve IsHasChildren. Elbette, yanlış, ama standartta karar verildi. Ve bu benim açımdan: bu şeyleri belirtmeye başladığınızda, tüm temelleri örtbas ettiğinizden veya başkalarının standartların kapsamadığı ya da kötü şekilde örtüştüğü bir şeye girdiğinizden emin olmalısınız ve sonra ya yanlış bir şey yazıyorlar, veya standardı görmezden gelmeye başlarlar. Her iki durumda da takım kaybeder.
Bir grup için bir kodlama standardı, ele alınması gereken uyarılar ve hatalar için derleyici seçeneklerini içermelidir.
Programcılar kendi kodlarıyla ilgili uyarıları arttırmakta özgür olmalı , ancak bir başkasının kodunu okumak ve çalışmakla derleyiciden aldığınız çıktıları karıştırmamak için bir temel olmalı.
Böyle bir standart, programcıların, aksi halde uymayacak istisnai bir kod parçası olması durumunda, bu tür uyarıları duruma göre nasıl etkisizleştirebileceklerini de ele almalıdır.
Sevdiğim bazı standartlar (çoğunu biliyorum, ama tercih ettiğim şey bu):
Kodlama İlkeleri, kodu ilk yazdığınızda biraz yardımcı olur, çok yardımcı olurlar. , siz veya sizin yerine yenisi koymanızın, kodu 2 yıl sonra güncellemesi gerektiğinde .
İdeal standart, koddaki isteğe bağlı herhangi bir sayfaya atlayabileceğiniz koda yol açar ve ilk okuma sırasında ne yaptığını tam olarak anlar, çünkü
Öte yandan, çok fazla keyfi standart yazma kodunun akışını bozabilir. Dolayısıyla, önerilen bir kodlama sözleşmesindeki her maddenin bu 2 kritere göre değerlendirilmesi gerektiğine inanıyorum:
Hiçbiri doğru değilse, öğe sadece isteğe bağlıdır ve muhtemelen gereksizdir
Aşağıdakileri yazdığım bir standarda dahil ederim:
Açıklık için:
Dosya Organizasyonu: Dosyadaki öğeler için sabit bir düzen belirlemek, ekibin diğer dosyalarda kolayca gezinmesini sağlar. #Defines bulmak için avlanmamalı veya tanımları tanımlamalısınız.
Adlandırma kuralları: Tutarlı adlandırma, okunabilirliği kolaylaştırır. Ancak, yazılabilirliği zedeleyen çok fazla kuralın fazla belirtilmesinden kaçının.
Kod Yapısı. Kıvırcık Brace yerleşimi, girinti seviyeleri, boşluklara, sekmelere vb. Takım için en iyi seçeneği bulun ve buna bağlı kalın.
Doğruluk için:
Sorun türünüze özgü En İyi Uygulamalar: Bellek ayırma, eşzamanlılık veya taşınabilirlik ile ilgili kurallar.
"Const Correctnesss", uygun kullanımı staticve volatilevb
Önişlemci makroları ve dilin kolayca kötüye kullanılan diğer özellikleri hakkında kurallar.
İnsanları düşünmelerini durduran olumsuz kısıtlamalardan ziyade insanları düşündüren ilham verici, pragmatik fikirler.
Aksi takdirde, muzdan sonra gitmekten korkan kod maymunları elde edersiniz .
Kodlama standardında ne olmalı? Mümkün olduğunca az. Daha az, daha çok. Ve haklı olarak lütfen.
Proses istemeyen bazı kovboy kodlayıcıları olduğum için değil, ama arkasında mantığı olmayan ağır kodlama özellikleri gördüğüm için (muhtemelen) “Bunu, '95'te bir yerde net olarak buldum”. çalışmak için bürokratik bir kabus.
Bazı insanlar dürüstçe standartlara uyarak, "kalite" kodunda uygun bir artış göreceklerine ve belki de bu önlemle göreceklerine inanıyor gibi görünmektedir. Bu arada mimarlık, performans, sağduyu ve bir dosyadaki satır sayısından daha önemli olan diğer birçok şeyi görmezden gelirler.
Bazı eski iyi sağduyu yanlış gitmez; alakasız noktalarda çalışacak çok sayıda kodlama standardı belgesi var (yazı tipi ve büyüklüğü gibi öğeler gördüğüm en uç noktalardan biriydi).
Bir grup geliştiriciyseniz, yapmanız gereken en iyi şey, birbirinizle konuşmak ve kodunuza bakmak, neyin kabul edilebilir olduğu konusunda bir fikir birliği oluşturmak ve ana noktaları kurallar olarak yazmanız gerekip gerekmediğidir. Sadece bu kurallar. Kılavuzdaki herhangi bir farklılığı haklı gösteremiyorsanız, neden yaptığınızı gerçekten düşünmelisiniz.
Günün sonunda açık ve anlaşılabilir kod, düzen veya tipografideki her türlü katı kuraldan daha önemlidir.
Diğerlerinin de belirttiği gibi, kod testi kapsamı önemlidir. Ben de görmek isterim:
Proje yapısı Testler kodun parçası mı, yoksa ayrı bir proje / paket / dizinde mi? UI kodu arka uçlarla mı yaşıyor? Olmazsa, nasıl bölümlenir?
Gelişme süreci. Koddan önce testler yazılsın mı? Kırık binaları tamir etmek gelişimden öncelikli midir? Kod incelemeleri ne zaman yapılır ve neleri kapsamalıdır?
Kaynak kodu yönetimi. Ne zaman kontrol edilir? Tasarım dokümanları ve test planları revizyon kontrollü mü? Ne zaman dallanır ve ne zaman etiketlenirsiniz? Önceki yapıları koruyor musunuz, öyleyse kaç tane / ne kadar süre için?
Dağıtım standartları Bir yapı nasıl paketlenir? Sürüm notlarına ne girmeli? Yükseltme komut dosyaları nasıl oluşturulur / kontrol edilir / çalıştırılır?
Bir isimlendirme, formatlama ve bir fonksiyon / yöntem / modülde kaç satır olabileceği ile ilgili tüm saçmalıkları unutun. Bir kural: Var olan tarzı ne kullanıyorsanız kullanın, düzenlemekte olduğunuz şeyi kullanın. Birinin tarzını beğenmiyorsanız, kod incelemesinde ayırın. Bunun tek istisnası, sadece çok sayıda editör / IDE'nin birisini diğerine körü körüne çevireceği ve ardından her satırın değiştiği için değişiklik geçmişinizi mahvedeceğiniz için, tabs-vs-spaces olayı olabilir.
Aslında, ele alınması gereken iki şey olduğunu düşünüyorum ve aslında her ikisini de önemli bulmama rağmen, aynı şekilde ele alınamayacakları için ayrı ayrı ele alırdım.
Ben hak teknik yönü Kodlama Standardı olarak yapmak Herb Sutter ve Andrei Alexandrescu onların ile C ++ Kodlama Standartları . Adlandırma kurallarını, girintileri vb. İçeren Kodlama Stiline hak kazandığım sunum ...
Kodlama standardı
Tamamen teknik olduğu için bir Kodlama Standardı çoğunlukla objektif olabilir. Bu nedenle, her kural bir sebeple desteklenmelidir. Her maddeye atıfta bulundum kitapta:
Gerekçe ve ne zaman özetledikleri için gerekçe ve istisnalar çok önemlidir.
Başlık, incelemeler sırasında yalnızca çalışmak için bir başlık listesine sahip olmanız yeterli olacaktır. Ve tabii ki, aramayı kolaylaştırmayı kolaylaştırmak için maddeleri kategorilere göre gruplandırın.
Sutter ve Alexandrescu, C ++ kıllı görünse de, yalnızca yüz öğelerin bir listesini çıkarmayı başardı;)
Kodlama Stili
Bu bölüm genellikle daha az nesneldir (düpedüz öznel olabilir). Buradaki amaç tutarlılığı garanti altına almaktır, çünkü bu, bakıcılara ve yeni gelenlere yardımcı olur.
Burada girintiliğin ya da ayraç tarzının daha iyi olduğu hakkında kutsal bir savaşa girmek istemezsiniz, bunun için forumlar vardır: bu nedenle bu kategoride lider (ler) in kararını oybirliği ile yaparsınız.
Biçimlendirme örneği için, Sanatsal Stil seçeneklerinin listesine bakın . İdeal olarak, kurallar bir programın kodu yeniden yazabileceği kadar açık ve eksiksiz olmalıdır (yine de bir kod yazmanız olası değildir;)
Adlandırma kuralı için, sınıf / türleri değişkenlerden / niteliklerden kolayca ayırt etmeye çalışacağım.
Ayrıca bu kategorideki gibi "önlemler" sınıflandırmak:
Misc?
Ve son bir kelime olarak, Kodlama Standartlarında tartışılan nadiren, belki de her uygulamaya özel olduğu için tek bir madde vardır: kod organizasyonu. Mimari sorun belki de en çarpıcı olanıdır, ilk tasarıma dikkat çeker ve bundan yıllar sonra başınız belaya girer. Temel dosya işleme için belki bir bölüm eklemelisiniz: kamu / özel başlıklar, bağımlılık yönetimi, endişelerin ayrılması, diğer sistemlerle veya kütüphanelerle etkileşime girme ...
Ancak bunlar gerçekte uygulanmadıklarında ve uygulanmadıklarında hiçbir şey değildir .
Herhangi bir ihlal kod incelemeleri sırasında gündeme getirilmeli ve bir ihlal üstündeyse, kod incelemesi tamam değildir:
Açıkçası, bir kuralı değiştirmek, liderlerden “öne geçmek” anlamına gelir.
Çerçeve Tasarım Kılavuzundaki formatı sevdim, genel bir bölüm ve ilkeler için gerekçeleri içeriyor. En kullanışlı bit, Do, Do Not, Avoid ve Unutma ile başlayan detaylardır.
İşte Arayüz Üyelerinin Uygulanması bölümünde bir örnek Açıkça aşağıdaki öğelere sahiptir (not, bervity'nin iyiliği için gerekçeleri düşürdüğüme dikkat edin).
Arayüz üyelerini, bunu yapmak için güçlü bir nedene sahip olmadan açıkça uygulamaktan kaçının
Üyeler sadece arabirim aracılığıyla çağrılmak isteniyorsa, arabirim üyelerini açıkça uygulamayı düşünün .
Do bir güvenlik sınırı olarak açık üye kullanın.
Do teklifler işlevselliği kastedilmektedir if> açıkça uygulanır üyesi olarak aynı işlevi türetilmiş sınıfları tarafından uzman olan bir korumalı sanal üyesini sağlamaktadır.
Bu iyi bir genel ton oluşturur. Avoid ve Consider uygulamasını kullanarak geliştiricilerin kararlarını kullanmalarına izin verebilirsiniz. Ayrıca kurallar oldukları ve kurallar olmadığı için geliştiricilerin onları daha lezzetli bulmaları ve ardından onları takip etmeleri daha olasıdır.
Kimsenin güvenlikten bahsetmediği görülüyor - bir kodlama standardında güvenli kod gereksinimlerine referans vermelisiniz (örneğin, giriş doğrulama modüllerinin kullanımı, strcpy, hata işleme gereksinimleri vb. Gibi bilinen zayıf işlevlere izin vermeyin)
Örnekler. Her kuralı kullanan, özenle düzenlenmiş, önemsiz, gerçek dünyaya yakın örnekler. Örneğin hangi bölümünün hangi kurala uyduğunu yorumlar (kodun bir parçası değil).
Şablonlar. C ++ türü değil, ancak kopyala yapıştır ve canlı olarak dolduracak bir şey. Kopyalanacak bir referansınız olduğunda 24 hatlı kazan plakasının yorumunu almak çok daha kolaydır.
Bir numaralı özellik: Mutlak maksimum iki sayfa.
Bu, her geliştiricinin okumasını ve hatırlamasını istediğiniz bir şey. Her yeni bir fonksiyon yazmanız gerektiğinde (veya yeni bir satırdan daha kötüsü) standarda bakmak zorunda kalmamalısınız. Bu nedenle, kısa tutun ve yalnızca nihai ürüne gerçekten daha fazla değer sağlayan kuralları koruyun.
Kodlama standartları gerçekten birkaç öğedir:
Kodlama kuralları
En İyi Uygulamalar
örneğin Denemeden sonra asla boş Catch'i bırakma
try { Foo(); } catch { //do nothing }
1) Foo () tarafından atılan bir istisna varsa, foo'nun başarılı olduğunu varsayan, aşağıdaki fonksiyonlarda başka sorunlara neden olabilir.
2) Genel hata işleyicisi, prod olduğunda istisna destek ekibine haber vermeyecektir
Kodlama Ortamı
Kodlama standartları, kağıda yazıldığında yalnızca çok etkilidir. Go'nun kodlama standardını yayınlamasından hoşlanıyorum. gofmtProgram metnini bir biçime biçimlendirme aracına sahiptir . Kodlama formatındaki herhangi bir tartışma, daha sonra kaynakların bir yaması olarak sonuçlanacaktır gofmt.
Formatın ne olması gerektiğine gelince,
ifFonksiyon gövdesi, başka bir amaç için ifade blokları söz konusu olduğunda {,}, (,), [,] nasıl yerleştirilir ,Başkalarının (çoğunlukla C dili) kodunu okurken, değişken / işlev adları proje bağlamında sezgisel değilse veya beş girinti seviyesini aşarsa veya işlevler altı veya yedi argümandan fazlasını alırsa veya bir işlev biterse ekranda iki ya da üç sayfa, kodu okumak ve anlamak çok zorlaşıyor. Üzerinde iyileştirmeler / bakım çalışmaları yapılması istendiğinde, yalnızca zorluklara eklenir. gofmtHer projeye (hatta dile) program yazılmasını ve projeye başlamadan önce her kaynak kod dosyasını bu programdan geçirmesini diliyorum .
Google JavaScript Stil Kılavuzunu beğendim .
Rehberindeki özlü, ancak ihtiyaç duyduğunuzda ayrıntılara sahiptir.