Şirketinizin kodlama standardı var mı? [kapalı]

Geçenlerde Microsoft'un bir kodlama standartları belgesi ( All-In-One Kod Çerçevesi Kodlama Standartları ) yayınladığını ve beni düşündürttüğünü gördüm ... Çalıştığım şirketin hiçbir resmi kodlama standardı yok. Sadece birkaç geliştirici var ve benzer tarzlara dönüşecek kadar uzun süredir birlikteyiz ve bu asla bir sorun olmadı.

Çalıştığınız şirketin yazılı bir kodlama standardı var mı? Hayır ise neden olmasın? Bir standarda sahip olmak bir fark yaratır mı? Sıfırdan bir standart yazmaya değer mi yoksa başka bir standardı kendiniz olarak mı benimsemelisiniz?

Birkaç problemden kaçınmak için bir ekibin her dil için tek bir kodlama standardı olması önemlidir:

• Standartların eksikliği kodunuzu okunamaz hale getirebilir.
• Standartlar üzerindeki anlaşmazlık geliştiriciler arasında check-in savaşlarına neden olabilir.
• Aynı sınıfta farklı standartlar görmek son derece tahriş edici olabilir.

Bob Amca'nın standartlar hakkında söylediklerinin büyük hayranıyım :

1. İlk birkaç tekrar sırasında gelişmelerine izin verin.
2. Şirkete özgü yerine takıma özel olmalarını sağlayın.
3. Bunu önleyebilirsiniz eğer onları yazmayın. Aksine, kodu standartların yakalanma şekli olsun.
4. İyi tasarımı yasaklama. (örneğin insanlara goto kullanmamalarını söyleme)
5. Herkesin standardın iletişim ile ilgili olduğunu ve başka bir şey olmadığını bildiğinden emin olun.
6. İlk birkaç tekrardan sonra, kararı vermek için ekibi bir araya getirin.

“3 boşluklu girintiler kullanıyoruz ve açık parantezler bir sonraki satıra gidiyoruz” olsa bile, bir kodlama standardına sahip olmanın şart olduğunu düşünüyorum. Birkaç fayda:

• Dosyalar arasında kodlama stilleri arasında geçiş yapmak can sıkıcı olduğundan, tüm kod tabanında okuma işlemini kolaylaştırır.
• Tek bir dosyayı okumayı kolaylaştırır, çünkü çakışan stillere sahip iki geliştirici tarafından güncellenen herhangi bir dosya sonunda bu stilleri karışık hale getirir. Sekmeleri ve boşlukları birleştiren bir dosyayı okumak (ve daha sonra düzenlemek) kıçınıza acı verir.
• Yeni geliştiricilerin, açık bir standart yerine, açık bir standart varsa, iyi stil kullanmasını kolaylaştırır.
• Tutarlı adlandırma kuralları, işlev / değişken bulmayı çok kolaylaştırır. ArraySort veya array_Sort mu yoksa sortTheArray mı yoksa doSortArray mı yoksa ...?

Mevcut bir standardın benimsenip kabul edilmemesi açısından, önemli olan şey aslında tutarlılık değildir. Geliştiricilerinizde bir düzine farklı stil varsa, mevcut bir yayınlanmış stili de seçebilirsiniz. Hepiniz oldukça tutarlı bir stile dönüşmüşseniz, sadece bunu yazın ve kullanın.

"Biz bir X mağazasıyız" ile aynı fikirde değilim, bu yüzden kodumuzu tüm dillerde aynı şekilde formatlıyoruz.

Şahsen, çoğu dilin farklı kabul edilmiş stilleri olduğunu buldum.

C programcıları C formatı ile Java kodu yazarken gerçekten duramıyorum. Sadece Java gibi görünmekle kalmaz, aynı zamanda Java'daki diğer C benzeri uygulamaları kullanabileceklerini düşünmeye zorlar.

Sanırım bir standart varsa, bu dilden olmalı.

Eski işverenimin bir kodlama standardı var. Resmi olarak kendim için de belgelemeyi düşünüyorum.

Ya da önerdiğiniz gibi, uygun bir standart bulmak ve bunu değiştirmek / benimsemek. Bir şirket için, kesinlikle mevcut kodlama standartlarına bakmalarını, ancak kendi özel ihtiyaçları için bir tane yaratma / değiştirme yapmalarını öneririm. Sıfırdan bir tane yaratma gereği duymazsınız, ancak kodlama standardının şirketin yarattığı yazılım türü için anlam kazandığından emin olmak için biraz özen gösterilmelidir.

Evet, bir kodlama standardına sahip olmak bir fark yaratıyor, ancak gümüş bir mermi değil. Kod, çok fazla farklı stil çatışması olmadığından ve bazı yaygın hatalardan / tuzaklardan kaçınılabildiğinden daha okunaklıdır. Bir standart bile olsa, kodlama stillerinde bazı değişiklikler olabilir, ancak bu değişkenlik azalır. Amaç, tüm değişkenliklerden kaçınmak veya mümkün olan her duruma hazırlıklı olmak değildir. Çok karmaşık bir kodlama standardı hiç olmamasından daha kötü olabilir.

Ne yazık ki değil. Bu yüzden herkesin her şeyi karıştırmak için boşluk bırakma, girinti ve benzerlerini kullanma yolu vardır (bu şekilde, bir kod satırının yazarı kim olduğunu bilmek için "suçlama" işlevini kullanmak zorunda bile değiliz!)

Ama en kötüsü, biri İtalyanca, biri İngilizce, biri değişken ve sınıf isimleri yazıyor.

Tarzımı daima kullandığım dilin, kütüphanenin ve çerçeveninkine uyarlarım, böylece bir kaynak kod tek tip ve sade görünür.

Bunun, All-In-One Kod Çerçevesine özgü bir kodlama standartları belgesi olduğunu unutmayın .

Bazıları mevcut bir standarda sahip, bazıları da (çoğu) standardın geliştirilmesine yardımcı olduğum çeşitli firmalarda çalıştım. Çoğunlukla, .NET tabanlı bir geliştirme yapıyorsanız (ve olmasanız bile, kuralların çoğu hala geçerlidir), Çerçeve Tasarım Kurallarına bir göz atmalısınız . Bu, halka açık API'leri yazmaya özel olmakla birlikte, kılavuzların çoğu herhangi bir koda eşit derecede uygulanır.

Kod standartlarıyla ilgili en büyük sorun, nispeten basit ve anlaşılır olmasını sağlamaktır. Geliştiricilerin sunulan yönergeleri içselleştirebilmelerini istersiniz, bu nedenle 50 sayfalık bir sayfa belgesi vermek işe yaramaz. Arka plan, örnekler vb. Sağlamak istiyorsanız yine de bu belgeyi oluşturabilirsiniz, ancak aynı zamanda bir madde işareti kurallarına uyacak bir şey isteyeceksiniz. Kodlama standardınız, teknoloji değiştikçe değişmesi gereken esnek ve canlı bir belge olmalıdır.

Kodlama Standart tartışmaları şu şekildedir:

• Evet, onlara ihtiyacınız var, tutarlılık ve temiz kod, iyi bir gelişimin temel taşıdır.
• Ne olduklarını neredeyse kadar uzun herkes aynı standartları aşağıdaki gibi önemli değildir.
• Kendinizinkini yazma, bitmeyen ve acı dolu bir tartışmaya gireceksiniz. Orada popüler olan birçok şey var.
• Genel standartları kullanmak ( MSDN’deki gibi ) size tartışılamayan agnostik bir 3. taraf verir. Onlarla tartışmak istiyorsanız, 2. maddeye bakın.

Visual Studio'da C # ile geliştiriyorsanız, StyleCop gümüş bir mermidir. Ayrıca ReSharper kullanıyorsanız, o zaman ReSharper eklentisi için StyleCop sadece harika.

Biz bir blub dükkanıyız, bu yüzden blub programlama kurallarını kullanıyoruz.

Artık Paul Graham ve arkadaşları bizden çok daha zeki, ama biz blub programcıları, birbirimizi blub okuyabiliriz, aslında, herhangi bir blub programcısı blub kodumuzu okuyabilir.

Aslında, blub tasarımı nedeniyle, herhangi bir blub programcısı herhangi bir blub dosyasını okuyabilir ve anlayabilir, çünkü blub bir makro sisteme sahip değildir.

C veya C ++ 'ı programlıyorsak (hepimiz çok dillidir, blub'da programlamamıza rağmen) çoğunlukla yeni kod için veya üzerinde çalıştığımız projenin standardı olan açık kaynaklı şeyler için blub stilini kullanırız.

Bir standarda ihtiyacınız var. Bir uygulamanın farklı köşelerinde, hepsinin "kendi tarzını" yapmak istediği farklı müşteri adayları olan farklı standartlar gördüm. Belki de "standart" kavramı yanlış anlaşılmıştı. Çok çılgınca. Ve en kötü standartlar bir kişi tarafından üretiliyor. Bu kişinin kim olduğu önemli değil, eğer bir kişi standart geliştirirse, neredeyse kötü biri olduğu garanti edilir.

İnsanlara yardımcı olabilir, araçlarla da gerçekten yardımcı olabilir:

Herhangi bir tür otomatik kod biçimlendirmeyi kullanabilmek istiyorsanız, gerçekten kullanacağı kuralları standartlaştırmanız gerekir, aksi halde farkınızı kaldıran birçok anlamsız biçimlendirme değişikliği elde edersiniz.

Statik analiz araçları için varsayılan kural kümeleri, belirli bir adlandırma stilini iyi kontrol edebilir ve buna uyması daha kolay olabilir, daha sonra bir dizi yeni kural yazın. (sadece kuralı tamamen kapatmayacaksanız)

Son olarak, ekibinizin dışındaki birisine danışılması gereken herhangi bir şeyi standartlaştırmak iyidir. yani, muhtemelen şirketlerinizin hukuk ekibine yazdığınız her yeni dosyayı çalıştırmak istemediğiniz için başlıklarınızda standart bir telif hakkı uyarısı istiyorsunuz ve kesinlikle herhangi bir kamu API'sinin adını ilk defa almak istiyorsunuz.