Ekibim, ortak bir saygın kodlama standardını kendi temeli olarak mı kullanmalı?


9

İçinde bulunduğum Ar-Ge ekibi bir kodlama standardı benimsemeye karar verdi. Kısa bir süre önce oluşturduk ve standartlarımız / sözleşmeler dokümanımızı ekibimizde organik olarak neyin geliştiğine ve kendi kodumuzdan iyi örneklere dayanarak oluşturmak için çok az kod ve ortak kodlama süremiz var.

Şimdi, her birimiz geçmiş işyerlerinden biraz deneyime sahibiz - hiçbirimiz "burada yaptığımız iş için uygun bulduğum bu kapsamlı belgeyi kabul edelim" (*) diyebiliriz. Ayrıca, bazılarımız (ben dahil) yalnızca resmi kodlama standardı olmayan veya farklı bir ortamda farklı dillerde yazılan (daha fazla araştırmaya yönelik geliştirme çalışmasının aksine yüksek basınçlı haftalık üretim ortamı) deneyimlerimiz var.

Bu yüzden, düşündüğüm seçeneklerden biri, nispeten iyi bilinen ve saygın bir belge almak, umursadığımız / umursamadığımız şeyleri kırpmak ve tercihlerimize göre bazı değişiklikler yapmak.

Bu yaygın bir uygulama mı? Bunun iyi bir fikir olduğuna inanıyor musunuz? Öyleyse, makul bir 'temel' kodlama standardı ne olurdu (hangisinin en iyisi olduğunu söyleme, burada dini bir çatışmaya başlamak istemiyorum; sadece üzerine inşa edilecek kapsamlı veya 'nötr' ne işaret edeceğinizi belirtin .)

Notlar:

  • C, C ++, OpenCL, CUDA, Python ile çalışmayı bekliyoruz.
  • Biz 4 kişilik + bir ekip, bir yıl kadar yaklaşık 5-6 büyümesi bekleniyor.
  • Şirketimizde, takımlar neredeyse tamamen özerktir ve genellikle hiç etkileşimde bulunmazlar (birbirlerinin kodunu kullanarak bile değil - iş tamamen farklı projelerde); yani - şirket genelinde dikkate alınması gereken hususlar yok.
  • Araçlar ile ilgili olarak, şu anda bildiğimiz şey Eclipse kullanacağımızdır , bu yüzden kod formatlayıcı en azından bir araç olacaktır. Ctrl + Shift + F uzun zamandır arkadaşım oldu
  • Java yazdığımda, Bloch'un Etkili Java'sına olabildiğince sıkı bir şekilde bağlı kalmayı denedim . Şimdi, bu bir kodlama standardı değil, ancak bir kodlama standardı için bazı tuğla, çimento ve harç çağırabilirsiniz. Muhtemelen böyle bir şeyi 'mix'in bir parçası olarak dahil etmeyi düşünüyordum (Java yapmamayı düşünerek).
  • Kelimeyi daha geniş anlamda kodlama standartlarını kastediyorum, örneğin bu P.SE sorusunun cevaplarında yapılan önerileri benimsemek .
  • C ++ kodlama standartları belgelerinin büyük bir listesini buldum ; belki de benim temelimiz benim olmalıyım.
  • (*) Bu doğru değil, ama bu soruyu çok fazla ayrıntıyla karmaşıklaştırmak istemiyorum.

9
Harici olarak oluşturulan bir kodlama standardının kullanılması, belirli kodlama stilleri hakkındaki kutsal savaşların azaltılmasına yardımcı olur.
Robot Gort

4
Hangi kılavuzu kullandığınız gerçekten önemli değil. Önemli olan birini kullanmanız ve herkesin bunu kullanmayı kabul etmesi . Aklı başında olanı seçerseniz, bu son bölüm daha kolaydır.
Joachim Sauer

3
Adlandırma kuralları abartılıyor. İşlevlerin CamelCase ve başkalarının snake_case olduğu bir modülünüz varsa, en azından her bileşen için geçerli olan kurala uymayı kabul ederseniz bu önemli değildir. Kutsal savaş çok ısınırsa, durdurun ve tutarsız bırakın.
Jan Hudec

1
Çok az Eclipse deneyimim var, ancak Eclipse için kod standardı (stil değil) uygulayıcısı yardımcı olabilir
Dan Pichelman

1
Yani seçiminiz mevcut bir standardı kullanmak mı yoksa bir standart oluşturmak için zaman ve para harcamak mı? Burada bir seçim görmüyorum. Ücretsiz seçenekle devam edin.
Ramhound

Yanıtlar:


9

Başka bir deyişle, bulduğunuz dış standartları ödünç alarak ekibinizin kodlama standartlarını hemen başlatmanız gerekip gerekmediğini soruyorsunuz. Takımdaki hiç kimsenin bu standartların ne olması gerektiği konusunda çok güçlü görüşlere sahip olduğu anlaşılıyor.

Hiç kuşkusuz, cevap evet.

Dış kaynaklı bir standart hiçbir şeyden üstündür. Bir standarda sahip olmanın avantajlarından bazılarını görmek için " https://softwareengineering.stackexchange.com/q/84203/53019 " adresindeki yanıtlara bakın. Tutarlılık ve değişiklik yapmak için bir temele sahip olmak sizin bakış açınızdan kritik öneme sahiptir.

Ayrıca , standartların ne olacağını seçerken ekibinizin dikkate alması gereken bazı takım dinamiklerine girerken , " İşyerinde Kodlama Standartlarını Kullanma (patron değilim) " ' a da göz atın . Takımın kodlama standart (lar) ına sahip olması gerekir, böylece herkes isteyerek her bir kişinin kodlama şekline getirdiği kısıtlamalara uymaktadır.

Bu soru ile bağlantı kurdunuz, ancak en iyi yanıtı ve gereksinimlerin neden yerinde olduğunu anlamaya odaklanmaya değer . Harici bir standart kullanırsanız, ekibinizin tüm bu gereksinimlerin arkasındaki temeli anlaması zor olacaktır. Ancak, ekibinizin başlamak için bir şeye ihtiyacı olduğu için orada olduklarını kabul ederseniz, o dış standardı ekibiniz için daha iyi çalışan bir şeye değiştirmeye geçmek kolaydır.

Herhangi bir standardın mevcut olması, IDE'nizle kullanacağınız biçimlendirme kurallarını doldurmanıza olanak tanır (davanızdaki Eclipse). “ Zorunlu Kod Reformatının Avantajları ve Dezavantajları ”, ekip üzerindeki herkesin üzerinde çalıştıkları kodla bu tutarlılığa sahip olma avantajlarından yararlanır ve size diğer projelerden ödünç alabileceğiniz parçacıkları yeniden biçimlendirme olanağı sağlar. Harici bir standart kullanmanın bir avantajı da, IDE'nizin kod biçimlendirme bölümünde önceden doldurulmuş olabilmesidir.

Takımdaki bir kişi muhtemelen standardın belirli bir kısmından şikayet edecek ve üs olarak harici bir standart kullandığınızdan sorumlu olacak. Onları okutun:
- Kodlama standartlarımızdan nefret ediyorum ve beni delirtiyor, nasıl işleyeceğim?
- Eski kod verildiğinde kendi kodlama önyargılarınızın üstesinden nasıl gelirsiniz?
ve sonra nereden gelirse gelsin, standarttaki bir şeyden şikayet edeceklerini fark ettiler. Üzerinde çalıştığım takımların sayısı boyunca, herkesin a) evrensel olarak sevdiği ve b) standardın her bölümü ile hemfikir olduğu bir standart görmedim. Bu endişelerle nasıl başa çıkılacağını görmek için bazı erken bağlantılara bakın.


Zeyilname, "hangisini" kullanmanız gerektiğini sordunuz. Özellikle herhangi bir sorunun potansiyel olarak körüklenmiş alev savaşları ile dolu olması nedeniyle buna cevap vermeyeceğim. Ancak IDE'nize (Eclipse) bakabilir ve standart yapılandırma olarak hangi seçenekleri sağladığını görebilirsiniz. Ayrıca biraz araştırıp IDE'nize eklenti ve seçim için ek standart seçenekleri sağlayan herhangi bir proje olup olmadığını görüyorum. Doğru ya da yanlış, bu standartlar sizin için zaten doldurulmuştur ve ekibinizi herkes için yapılandırırken bir yığın iş kaydedebilir.


6

Python ile başlardım. Python, hemen hemen her python programcısının takip ettiği kodlama kurallarına sahiptir. Bunlar PEP8 adı verilen resmi belgelerin bir parçasıdır .

C / C ++ tarihsel nedenlerden dolayı büyük bir karmaşa, ancak python olmadığından, tutarlılık uğruna da C / C ++ 'daki python adlandırma kuralını izlemenizi tavsiye ederim.

Şimdi C ++ için ortak deyimler üzerinde anlaşmak ve herkesin adlandırma kurallarına ilişkin savaşlardan daha makul modern C ++ stilini anladığından emin olmak daha önemlidir. C ++ Kodlama Standartları ile başlamalısınız ve çevrimiçi kaynaklardan C ++ SSS'yi okuduğunuzdan emin olun .


Aslında biz C, C ++ ve Python her biri için farklı adlandırma kurallarına gerekecek inanacaksýn - en azından, büyük harf ve alt çizgi vs. kullanımı gibi wrt şeyler MyTypeNamedaha belki daha iyi C ++ olduğunu my_type_name_tve karşısındaki C. Ama için teşekkürler için de geçerli referanslar.
einpoklum

C ++ için, STL ve boost tarafından kullanılan standardı kullanabilirsiniz. Herkes beğenmez ama kesinlikle bazı stl kapları kullanacağınız için bu ile tutarlı olacaktır.
Laurent Bourgault-Roy

@ einpoklum: Tür olmayan türler için tüm C, C ++ standart kitaplığı ve Python "snake_case" kullanır; orada fark yok. Tek fark, türler için "MixedCase" mi yoksa "snake_case" için mi kullanmak istediğinizdir. C ve C ++ kitaplığı "snake_case" kullanır, ancak aksi takdirde "MixedCase" çok yaygındır.
Jan Hudec

@ einpoklum C ++ için standart kitaplık tarafından ayarlanan standardı kullanın.
Miles Rout

3

Bir kodlama standardı ve bir kodlama stili standardı arasında ayrım yapmadan bu konuyu bile tartışamazsınız .

Kodlama standardı, hangi dil mekanizmalarını kullanmanıza izin verildiğini, hangilerini kullanmanıza izin verilmediğini ve bunların nasıl kullanılacağını tanımlayan bir dizi kuraldır. Başka bir deyişle, kodlama standardı belirli standart dışı uzantılara yönelikse, kullanılan dilin bir alt kümesini ve / veya bir üst kümesini tanımlarsınız.

Bir kodlama stili standardı yalnızca kozmetik konularla ilgilidir: kaşlı ayraçlar ve boşluklar nereye yerleştirilir, tanımlayıcıların nasıl adlandırılacağı, yorumların nasıl yerleştirileceği vb.

Bu iki farklı şey aynı belgede bulunabilir. Bununla birlikte, kodlama standartlarının en ciddisi kendilerini stil ile ilgilendirmez - aşağıda tavsiye ettiğim şeyler değildir. Büyük olasılıkla kodlama stili çok öznel ve bu nedenle fikirler çarpıştığında çok fazla sürtünmeye neden oluyor.

C / C ++ için, en iyi üne sahip kodlama standartları MISRA'ya aittir . Bunlar birincil olarak güvenlik / kritik görev uygulamaları için tasarlanmıştır, ancak programları daha güvenli hale getirmenin anahtarı hataları ortadan kaldırmak ve önlemek olduğundan, MISRA standartları hataların istenmediği herhangi bir programlama dalı için geçerlidir.

CERT'in standartları da oldukça iyi biliniyor ve masaüstü programlama ve yazılım güvenliğine (güvenlik yerine) daha eğilimli. CERT, C, C ++, Java ve Perl için standartlara sahiptir ve standartlar ücretsizdir.

Web'de bulunan bazı rastgele garaj standardından ziyade MISRA ve CERT'ye bakarak başladım.


1
Daha önce MISRA'yı hiç duymamıştım ve bileşenlerinin aşırı derecede önemli oyuncular olduğunu görmüyorum. İtibarlarını açıklayabilir misiniz? CERT belgelerine gelince, bunların güvenli programlar için standartlar mı yoksa daha genel standartlar mı olduğunu açıklayabilir misiniz?
einpoklum

@einpoklum Başlangıç ​​olarak, MISRA-C dünyadaki hemen hemen her otomobil üreticisi tarafından kullanılıyor. En iyi bilindiği tüm gömülü sistemler endüstrisinde C programlama için "fiili" bir standart haline geliyor. Yine de, MISRA belgesinde herhangi bir C programında kullanılmasını engelleyen hiçbir şey yoktur. Hem MISRA hem de CERT oldukça geneldir, sonuçta bir programdaki hata sayısını, kötü uygulamaları ve güvenlik açıklarını azaltmayı amaçlamaktadır. Bu standartlar statik kod analizini de teşvik eder.

1

Mevcut bir standardı kendiniz için temel olarak kullanmanın birçok avantajı vardır. Kodunuz muhtemelen harici koda daha benzer olacaktır, bu da kodu okumayı / entegre etmeyi kolaylaştırır. Ayrıca, iyi bir standart seçerseniz, kendi kurallarına karar vermek için iyi nedenleri olan uzmanlar tarafından incelenecektir. Ekibinizdeki hiç kimse bir standarda özellikle bağlı olmadığı sürece, mevcut bir standardı kendiniz için bir temel olarak kullanmamak için çok az neden vardır.

Hangi kodlama standartlarının kullanılacağından emin değilseniz, bazı ideal ideal seçenekler vardır. Belirli bir sırayla:
1. IDE'niz tarafından hangi standart zaten destekleniyorsa. Bu muhtemelen yapılandırılabilir.
2. Derleyicinizin yazarı tarafından hangi standart kullanılır / önerilir.
3. Birincil çerçevenizin yazarı tarafından hangi standart kullanılırsa / önerilirse (varsa).
4. Programlama dilinizin yazarları / tasarımcıları tarafından kullanılan / önerilen standart.
5. Hangi standart çok büyük bir şirket tarafından kullanılırsa / tavsiye edilirse.

Teknik uzmanlığı olan birini kendi standardınız için hangi standardı kullandığınızı okumanızı tavsiye ederim. İyi bir standardın her kural için genellikle bir gerekçesi vardır, bu da standardı ihtiyaçlarınıza en uygun şekilde değiştirmenize yardımcı olacaktır.


0

Bir standart genellikle iletişim ve bakıma yardımcı olur. Benim düşünceme göre, özellikle küçük takımlarda bazı ver ve allara tabi olmalı ve gelişmelidir. Onlara yönergeleri çağırmak yardımcı olabilir :-)

İlham almak için Google yönergelerine göz atın .


5
C / C ++ için hangi kodlama kurallarının seçileceği çok özneldir. Ben ediyorum eğer varsa Ve değil seçim, Google politikalarına. Çoğunlukla modern C ++ tarzı olarak düşünülen pek çok şeyi boost gibi diğerleri tarafından yasaklarlar.
Jan Hudec

1
Cevabınız OP'nin harici bir standart kullanma konusundaki endişelerini nasıl ele alıyor? Kodlama standartları için bir isim değişikliği önermek, ele almaları gereken temel sorunlara yardımcı olmaz.

1
@ JanHudec katılıyorum. Yasakladığı şeylerden biri de istisnaların kullanılmasıdır.
BЈовић

-3

HAYIR, rahatsız etmem - bence tek fayda takımınızın bu standartların kullanıldığı bir yere taşınması olurdu, ki bu olmasını istemediğiniz şey değil :)

Standartlar yalnızca daha kolay işbirliğini teşvik etmek için vardır, bu nedenle #define makronun her zaman büyük harf olduğunu biliyorsanız, kodda büyük harfli bir tanımlayıcı gördüğünüzde, bunun makro olduğu konusunda adil bir fikre sahip olursunuz. Benzer şekilde, diğer adlandırma kuralları veya stil kuralları size ne ile uğraştığınızı hatırlatacaktır.

Ben dosya konumu ve adı gibi standartlar daha yararlı1 buluyorum kod olanlar (sonuçta, kod tüm şekil ve boyutlarda geliyor ve hala okumak zorunda) iken readme.txt bilmiyorum / bin / doc / debug / release / belgeler gerçek bir acıdır (boktan bir yol gibi, ama bu başka bir hikaye).

Siz ilerledikçe kendi standartlarınızı oluşturmanızı tavsiye ederim. Bu şekilde, sadece sevdiklerinizi değil, sizin, ekibiniz ve yaptığınız iş için kesinlikle uygun olanları da elde edersiniz. Eğer bir while döngüsünün neye benzediğini gerçekten önemsemediğinize karar verirseniz veya bu vaka ifadelerinin belirli bir şekilde girintili olması gerekir, o zaman iyisinizdir. ++ operatörlerinin yasaklandığına karar verirseniz, iyi olur. Tamamen kendi seçiminiz.

Metin tanımından bir wiki belki veya otomatik olarak oluşturulmuş web sayfasını bulmayı ve güncellemeyi kolaylaştırmanız gerekir, ancak aksi takdirde - bunun için gidin. Standartlar, iyi kod yazmaktan ziyade standardı takip etmekle fanatik olarak ilgilenmek isteyen bazı insanların efsanevi bir tutumuna sahiptir, onlar gibi olmayın - ihtiyacınız olan yerde size yardımcı olan kendi standardınızı yapın.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.