Bob Amca neden önleyemiyorsanız kodlama standartlarının yazılmaması gerektiğini öne sürüyor?

Ben bu soruyu okurken , Bob Amca’nın kodlama standartlarına göre alıntı yaptığı yanıtı oyladı , ancak bu ipucuyla kafam karıştı:

3. Bunu önleyebilirsiniz eğer onları yazmayın. Aksine, kodu standartların yakalanma şekli olsun.

Bu beynimde zıpladı, ama yapışacak bir yer bulamadım. Yeni bir kişi takıma katılırsa veya kodlama standartları değişirse, bilgi karışıklığı olamaz mı?

Neden bir kodlama standardı yazmamalıyım?

Bir kaç neden var.

1. Kimse belgeleri okumaz.
2. Belgeleri okumuş olsalar bile kimse izlemiyor.
3. Hiç kimse belgeleri okumuş ve takip etse bile belgeleri güncellemez.
4. Bir uygulama listesi yazmak, kültür oluşturmaktan çok daha az etkilidir.

Kodlama standartları insanların yapması gerekenlerle ilgili değil, gerçekte yaptıkları ile ilgilidir. İnsanlar standartlardan saptığında, bir kod gözden geçirme süreci ve / veya otomatikleştirilmiş araçlar aracılığıyla bu seçilmeli ve değiştirilmelidir.

Unutmayın, kodlama standartlarının tüm amacı hayatımızı kolaylaştırmaktır. Beynimiz için kısayollar, böylece gerekli şeyleri önemli şeylerden filtreleyebiliyoruz. Bunu uygulamak için bir inceleme kültürü oluşturmak, onu bir belgede resmileştirmekten çok daha iyidir.

Başka bir yorum var. Bob Amcanın kastettiğine inanmıyorum, ama düşünmeye değer.

Bir belgedeki kodlama standartlarını yakalamayın. Standartların karşılandığını doğrulayan otomatik bir işlemle kodda yakalayın .

Bir belgeyi referans alan insanlara güvenmeyin, aynı zamanda, zaten var olan kodu yorumlayan ve sözleşmenin ve neyin tesadüf olduğunu tanımlayan insanlara güvenmeyin.

Taahhüt yapınıza Checkstyle gibi bir şey ekleyin. Bu, biçimlendirme ve standartların isimlendirilmesi gibi temel kuralları uygulayabilir ve daha sonra, stilin dikkate alınmasında zihinsel çaba harcamak yerine, en azından eksiksiz olması garanti edilen aptal bir sürece boşaltılabilir.

Önemli ise, ne istediğinizi kesin olarak tanımlayın ve yanlışsa başarısız olun.

İnsanlar, anlaşmazlıkları çözmek için bir kodlama standartları belgesinin gerçek amacını görmezden geliyor .

Kodlama standardındaki kararların çoğunun okunabilirlik ve üretkenlik üzerinde yalnızca çok küçük bir etkisi olacaktır. Özellikle dil için 'normal' tarzını benimserseniz ve dil tasarımcıları bunun şartnamenin bir parçası olması gerektiğinin farkına varmaya başlarlar (örn. Go).

Çok önemsiz oldukları için, argümanlar gerçekten ısınabilir ve sonsuz bir şekilde devam edebilir, üretkenlik ve takım uyumuna gerçek zarar verebilir. Veya iki veya daha fazla insanın tercih ettiği stiller arasında yapılan yeniden biçimlendirme ile değişim geçmişinizi gizleyebilir.

Yazılı bir standarda sahip olmak argümanı sonlandırır. Yöneticiler buna işaret edebilir ve belgeye olan memnuniyetsizliklerini saptırırlar. Bir kağıt parçasıyla tartışabilirsin ama seni dinlemeyecek.

(Ayrıca bkz . Yapısızlığın Tiranlığı )

Çünkü yorumlar yalan .

Kodlama standardı, kodun ne olması gerektiği konusunda büyük bir yorumdur. Kodun kendisi gerçekliğin kaynağıdır. Bu durumda gerçeği kod davranışı değildir, ifade edildiği stildir. Standartlarınız zaten kodunuza yansıtılmamışsa, önünüzde çok iş var.

Bob Amca bir yorumlamayı programcının kişisel başarısızlığı olarak görüyor, çünkü kod parçasının amacını programlama diliyle birlikte ifade edemediğini kanıtlıyor. Benzer şekilde, standartlar belgesi, kod tabanında tutarlı bir stil ifade etmede başarısızlıktır.

Yeni programcılar kodları incelemek için zaman harcamalı, günleri çok bölümlü standartlar belgesini okuyarak geçirmemeliler (bunu yapmak zorunda kaldım).

Standartlar belgesi o kadar kötü bir fikir değil, ancak standart belgelerini korumanın birinin tam zamanlı işi olduğu programlama dükkanlarında bulundum. Lütfen standart bir belge tutmanız gerekiyorsa, bir sayfada tutun. Ancak zaten kodunuz varsa, hiç kimse aynı belgeyi bir günden daha kısa sürede bir araya getiremez mi?

Kod standartlarına sahip olmak önemlidir. Ne olduklarını belirten bir belgeye sahip olmak.

Bob Amca neden önleyemiyorsanız kodlama standartlarının yazılmaması gerektiğini öne sürüyor?

Sizce fikrinin arkasındaki nedenleri soruyorsanız, o zaman bir cevap gönderirse bir cevabınız olabilir ( bizim fikrimiz önemsizdir),

Neden bir Kodlama Standardı yazmamalıyım?

Bu konuda haklı olup olmadığını soruyorsanız : İzin vermemek için hiçbir nedeniniz olmadığını söyleyen tek popüler kişi olmamı sağlayın.

AŞAĞI YAZIN . Ancak nedenlerimi açıklamaya çalışacağım ...

David olmamalıdır neden Stephen cevabın ana noktası olmadığını bir yorum önerdi yazma belgeleri ancak hangi olduklarını oluştururlar. Eğer kurallar araçlarda resmileştirilirse (yalnızca manuel kod incelemesi değil) o zaman katılıyorum (yasa başka bir şey gerektirmediğinde). Maalesef araçların her şeyi kontrol edemediğini (hesaplama teorisi arkadaşımız değildir), çünkü belirli bir çeviri birimi veya paketi ile sınırlıdırlar ya da en sevdiğiniz dil sınır ne olursa olsun .

Ancak Bob Amca'nın ifadesi, onun hakkında konuştuğunu düşünmemi sağlamaz.

Böyle bir uzmanla aynı fikirde miyim? Alıntı yaptığım yazıdaki hemen hemen her nokta için bunu yapıyorum (ayrıntılar için bu cevabın ikinci bölümüne de bakın). Nedenini anlamaya çalışalım (kodlama yönergelerinin yalnızca küçük biçimlendirme sorunları hakkında olmadığını zaten varsayalım ).

• Bazı durumlarda, yazılı kodlama standartları kanunen zorunludur.
• Belgeleri okudum ve yalnız olmadığımdan eminim. Ekip üyeleri zaman içinde değişebilir, bilgi 5-10 yıllık bir kod tabanında veya ekip üyelerinin zihinlerinde olamaz. Kuruluşlar, iç yönergelere uymayan insanları kovmalıdır.
• Kodlama standartları bir kez onaylandıktan sonra , sık sık değişmeyecekler ve eğer bunu bilmek istiyorlarsa. Standartlar değiştiyse, belgeleriniz (koddaki) güncel değildir, çünkü tüm kodunuz yeni standarda uymaz. Yeniden biçimlendirme / yeniden düzenleme yavaş olabilir ama her zaman yazılı olan yetkili takip etmek kılavuz.
• Hiç şüphesiz, bir kural (ek olarak yanlış anlayabileceğiniz BTW) öngörmek için 10 / 20K LOC'yi denetlemekten daha 5 sayfalık bir belge okumak daha iyidir .
• Tasarım ilkeleri ve kodlama tarzı hakkında birçok kitap yazan birinin, kendi kurallarınızı yazmamanız gerektiğini önermesi, bize bazı kod örnekleri bırakması durumunda daha iyi değil mi? Hayır, çünkü yazılı kurallar size sadece ne yapmanız gerektiğini değil, aynı zamanda kodlarından yoksun olan iki şeyi söyler: ne yapılmaması ve yapılmaması için nedenler.

"Özgür öz-örgütlü programlama" ninja 16 yaşındaki bir adam için iyidir, ancak kuruluşların başka gereksinimleri vardır :

• Kod kalitesi şirket düzeyinde verilmelidir (ve tanımlanır) - bu, tek bir ekibin karar verebileceği bir şey değildir. Neyin daha iyi olduğuna karar verme becerisine bile sahip olmayabilirler (örneğin, MISRA'yı incelemek veya her bir kuralı yalnızca anlamak için gerekli geliştiricilerin sayısı kaçtır ?)
• Üyeler farklı ekipler arasında hareket edebilir: eğer herkes aynı kodlama standartlarına uyarsa, entegrasyon düzgün ve hataya açıktır.
• Eğer bir ekip kendi kendini organize ediyorsa, ekip üyeleri değiştiğinde standartlar zaman içinde gelişecektir - o zaman geçerli kabul edilmiş standartlara uymayan büyük bir kod tabanına sahip olacaksınız .

Süreçten önce insanları düşünürseniz , sadece TPS hakkında okumayı önerebilirim: insanlar Yalın'ın merkezi bir parçasıdır, ancak prosedürler oldukça resmileştirilmiştir.

Tabii sadece bir ekiple küçük bir organizasyon olabilir ekibi benimsemeye standartlarını karar versin ama sonra aşağı yazılmalıdır. İşte Programcılar'da. Eric Lippert'in yayınlarını okuyabilirsiniz: Sanırım hepimiz Microsoft için çalıştığı zaman, kendi yazılı yönergelerine uyması gerektiğine (bazı kurallar yanlış olsa bile , uygulanamaz veya yararsız olsa bile) deneyimli bir geliştirici olduğuna katılıyorum. Ona.) Peki ya Jon Skeet? Google yönergeleri oldukça katıdır (ve birçok kişi onlarla aynı fikirde değildir) ancak bu tür kurallara uyması gerekir. Onlara saygısızlık mıdır? Hayır, muhtemelen bu rehberleri tanımlamak ve geliştirmek için çalıştılar, bir şirket bir üye (veya bir takım) tarafından üretilmedi ve her takım bir ada değil .

Örnekler

• C + 'da çoklu kalıtım ve iç içe geçmiş sınıfları kullanmamaya karar verdiniz, çünkü asıl ekip üyeleriniz bunu iyi anlamıyor . Daha sonra çoklu miras kullanmak isteyen birisinin, daha önce kullanılmış olup olmadığını görmek için tüm 1M LOC'ye göz atması gerekir. Kötü çünkü tasarım kararları belgelenmemişse, onları anlamak için tüm kod tabanını incelemeniz gerekir. Ve o zaman bile, kullanılmamışsa, bunun nedeni kodlama standardına aykırı olduğu ya da izin verildiği için mi, ancak çoklu kalıtımın uygun olduğu daha önceki durumlar olmadı mı?
• C # 'da varsayılan parametreleri sağlamak için aşırı yükleme yöntemlerine sahipsiniz, çünkü isteğe bağlı parametreler C #' da mevcut olmadığında kod tabanınız başladı. Ardından değiştiniz ve kullanmaya başladınız (eski işlevleri yeniden düzenlemek için bu tür işlevleri değiştirmek zorunda kaldığınızda bunları yeniden kullanmak). Daha sonra bile isteğe bağlı parametrelerin kötü olduğuna karar verdiniz ve bunları kullanmaktan kaçınmaya başladınız. Kodunuzun size söyleyeceği kural nedir ? Kötü çünkü standart evrim geçiriyor ancak kod temeli gelişmeye yavaşlıyor ve sizin belgeniz ise başınız belada.
• Jon, A takımından B takımına taşındı. Jon yeni bir standart öğrenmek zorunda ; Öğrenirken muhtemelen daha ince hatalar ortaya çıkaracaktır (ya da eğer şanslıysanız, mevcut kodu anlamak ve kod incelemesini daha uzun yapmak için uzun zaman alacaktır).
• A takımı, daha önce B takımının sahip olduğu bir kod tabanına taşınır. Tamamen farklı kodlama standartlarına sahiptir. Yeniden yazmak? Adapte olmak? Mix? Hepsi eşit derecede kötü.

Bob Amca

İlk birkaç tekrar sırasında gelişmelerine izin verin.

Doğru, bir standarda sahip değilseniz ve kuruluşunuz size bir tane oluşturma görevi verene kadar .

Şirkete özgü yerine takıma özel olmalarını sağlayın.

Hayır, yukarıda açıklanan tüm nedenlerden dolayı. Sadece kod formatlamayı (resmileştirmek isteyebileceğiniz en az faydalı olan şey) resmileştirmeyi düşünseniz bile, hala biçimlendirme konusundaki sonsuz (ve işe yaramaz) savaşların hatırasına sahibim. Onları tekrar tekrar yaşamak istemiyorum, hepsini bir kez ayarlayın.

Bunu önleyebilirsiniz eğer onları yazmayın. Aksine, kodu standartların yakalanma şekli olsun.

Hayır, yukarıda açıklanan tüm nedenlerden dolayı (elbette kurallar değiştiğinde tüm kodunuzu tek seferde yeniden sıralayamazsanız). Kodunuzu olduğu gibi bırakmak ister misiniz? Geçerli yönergeleri anlamak için kod tabanını nasıl denetlersiniz ? Dosya yaşına göre arama ve kodlama stilinizi kaynak dosya yaşına uyarlama

İyi tasarımı yasaklama. (örneğin insanlara goto kullanmamalarını söyleme)

Doğru, kurallar kısa olmalı ya da hiç kimse bunları okumaz. Bariz tekrar etmeyin.

Herkesin standardın iletişim ile ilgili olduğunu ve başka bir şey olmadığını bildiğinden emin olun.

Yalnızca küçük ayrıntılarla ilgili bir standarda sahip olmak istemediğiniz sürece , sadece iyi bir standart kalite ile ilgili değildir.

İlk birkaç tekrardan sonra, kararı vermek için ekibi bir araya getirin.

İlk noktaya bakın ve bir kodlama standardının genellikle geliştirilmesi ve rafine edilmesi uzun yıllar süren bir süreç olduğunu unutma: belki de küçük geliştiricilerle? Gerçekten mi? Bir (eğer varsa) üyenin hafızasına güvenmek ister misiniz?

Üç not:

• Bence bazı dezavantajlar diğerlerinden daha ciddi, örneğin C ++ 'da şirket düzeyinde bir standardın Java'dan bile daha fazla olması gerekiyor.
• Sadece bir küçük ekibiniz olduğu çok küçük bir şirkette çalışıyorsanız, bu akıl yürütme tamamen geçerli olmayabilir (ve Bob Amca sebepleri daha az aşırı olabilir ).
• İşe alındınız (takım olarak) ve yeni bir proje ile tek başınıza çalışacaksınız, sonra unutup devam edeceksiniz. Bu durumda sen umurumda değil olabilir (ancak işverenin gerekir ...)

1. Yararlı olmak için bir kodlama standardı madde meseleleri hakkında konuşmamalıdır; sadece stil meseleleri. Yalnızca keyfi ve belirsiz olanları belirtmelidir. örn. Brace yerleştirme, girinti derinliği, boşluklara karşı sekmeler, adlandırma kuralları vb.
2. Tarz meseleleri küresel değil yereldir. Her takım kendi kendine özgü stilini benimsemeli, görevlerine uygun ve kişiliğini benimsemelidir. Bu, standartları basit ve hafif tutar. Kurumsal standartlar, olası tüm düşünceler, konfigürasyonlar ve istisnalar ile aşırı yüklenildi.
3. Bir ekip içinde, ayrı bir kodlama stili belgesi yazmanın tek nedeni, ekibin ürettiği kodun standartlara uymamasıdır. Bu durumda standart yok. Etkili olması için, standart kodun kendisi tarafından ifade edilmelidir. Ve eğer öyleyse, ayrı bir belgeye gerek yoktur.
4. Eski sistemlerde ekipler ve stiller zamanla değişiyor. Bunda yanlış bir şey yok. Eski kod eski stilde olacaktır. Yeni kod daha yeni bir tarza sahip olacaktır. Ekip, stillerin ve yaşlarının farkında olmalıdır. Her ne zaman yeni kod yazılsa, kodun neresinde olursa olsun, yeni stilde olmalıdır.

Neden bir Kodlama Standardı yazmamalıyım?

Bunun için birçok nedeni vardır. İşte bazı düşünceler:

1. Kod standartlarını gözden geçirmek, tartışmak, belgelendirmek, revize etmek vb. İçin tüm ekip kodlarını yalnızca öğrenmek için ne kadar zaman harcıyorlar? Bu, “Çalışan El Kitabınızı” sürekli tartışmak gibidir - bu ne sıklıkta bir ekip toplantısının gündeminde yer alır?

2. Bir proje geri alındığında / rafa alındığında / etc. O zaman kalan birkaç kişi, standartlara uymaya devam edemez (hatta belki okumamış). Bildiğiniz bir sonraki şey, "kodu temiz tutmak" için harcadığınız her şey zaten boşa gitmişti.

3. Eğer proje durursa veya yeni bir ipucu getirilirse, o kişinin önceki kuralları tamamen görmezden gelmesi ve bunu yeni bir yolla yapması çok muhtemeldir. Yine, standartların kodlanmasıyla ne kazanıldı?

# 6'yı mutlaka okuyun:

İlk birkaç tekrardan sonra, kararı vermek için ekibi bir araya getirin.

Başka bir deyişle, bir projeye başlama zamanı geldiğinde, bir süreliğine akışa devam edin. Ardından mevcut ekibin kullandığı kodlama standartlarının genel kurallarını tartışın - ve temelde onları takip edin. Bu şekilde, çalıştırılabilir kod almaya başlayan "sözdizimsel şekeri" yazmak, gözden geçirmek ve belgelemek için harcanan çabayı en aza indirirken, ürünü geliştirme çabalarını en üst düzeye çıkarırsınız.

Çok az sayıda takım kodlama standartlarından büyük faydalar elde eder. Genellikle "okunabilirliği" çok belirsiz - ve çoğu geliştirici ölçüde fayda görmeyen tam vb aralık, yeni hatlar, kurallarının ama sürekli önleyebilirsiniz can sıkıcı en az birkaç kural alarak geliştiricilerine.

Yeterince açıkça ifade etmediğimi düşündüğüm bir başka cevap da, insanların kurallara kör şekilde uymadıkları anlamına geliyor. Bu, insanların haklı çıkarmak için yazıldığına bağlı olmak yerine , tasarım kararları ve kodlama kuralları için gerçek gerekçeleri bulmaları gerektiği anlamına gelir .

Öncelikle, bildiğim kadarıyla, Bob Amca bir Java insanı, ne dediğini anlamak için bu çok önemli.

Bir Java veya C # ekibinde çalışırken, mevcut kod deneyimli geliştiriciler tarafından yazılmışsa, kodlama stilini alıp bunlara ayak uydurmak benim için kolaydır. Yapmaya istekli olmazsam, belki de iş için doğru kişi değildim ... Tarzda kalmadığım zamanlarda beni almak için herhangi bir kod gözden geçirme ya da eşleştirme programı yoksa, o zaman şirketin Üye alanlarını adlandırdığımdan daha büyük sorun!

Hem Java hem de C #, çoğu modern dille birlikte, bir programcının düşebileceği "basit" tuzakların olmadığı şekilde tanımlanmıştır.

Ancak programlamaya başladığımda C (ve üstü C ++) kullanıyordum. C gibi bir kod yazabilirsiniz

if (a = 3);
{
   /* spend a long time debugging this */
}

Derleyici bir hata vermez ve çok fazla kod okurken fark etmek zor. Ancak yazarsanız:

if (3 = a)
{
   /* looks odd, but makes sense */
}

Derleyici bir hata veriyor ve kodu değiştirmek çok kolay 3 == a. Benzer şekilde, kodlama standardı =bir ifkoşulda veya "boş ififade" içinde kullanılmasına izin vermiyorsa , bu hatayı izlemek için derleme sisteminin bir parçası olarak bir kod denetleyicisi kullanılabilir.

Kodlama standartları konusundaki görüşlerim C / C ++ 'dan uzaklaştığımda büyük ölçüde değişti: Sıkıca uygulanan kodlama standartlarını ve birçok sayfayı uzun süre severdim. Şimdi yalnızca kullanılan araçları listelemeniz ve orijinal ekip üyeleri arasında birkaç isimlendirme sözleşmesinde gayrı resmi bir anlaşma yapmanız gerektiğini düşünüyorum. Artık C / C ++ 'da başvuru yazan 30'dan fazla geliştiriciden oluşan ekip dünyasında yaşamıyoruz ...

JScript'i hiç sevmememin bir nedeni var ve TypeScript'in yıllarca web geliştirmede yaşanabilecek en iyi şey olduğunu düşünüyorum. Web UI geliştiricilerinin hala HTML / CSS / JScript vb. Tasarımındaki hatalar nedeniyle kodlama standartlarına ihtiyaç duymalarını bekliyorum.

Kaynağın kendi kendini belgeleyen kodlama standardı olması iki şeyi ifade eder.

1. Çalışanların yeteri kadar katkıda bulunmak için kod tabanına başvurması ve incelemesi gerekir. Bu inanılmaz derecede önemli. Kodlama kurallarının okunması, kod tabanına dalmaya kıyasla zaman kaybıdır.
2. Küçük farklılıkların önemsiz olduğunu kabul eder. Temel prensipleri kabul etmek ve anlamak önemlidir. Tutarlı bir stilin sürdürülmesi l'art pour l'art olarak takip edilmez. Yaratıcı olmayan nitpicker'ların diğer insanları rahatsız etmesine ve rahatsız etmesine izin vermez. Bir takımdaki kodla iletişimi kolaylaştırmakla ilgilidir.

Sık sık güncellenen ve iyi yazılmış bir kod standartları belgesi çok faydalı olabilir, ancak genellikle bu böyle değildir. Standartlar dokümanı, şirket tarafından kullanılan gerçek kodlama standartlarını yansıtmamaktadır, çünkü iyi bir standartlar dokümanı oluşturmak çok zordur ve güncel tutmak çok daha zordur.

Zayıf ve yanıltıcı kodlama standartları belgesine sahip olmak yerine, hiçbirinin olmaması ve kodun kendisinin bu standartları temsil etmesine izin vermek daha iyidir. Her iki durumda da en önemli kısım, koddaki standartları uygulamaktır ve bu sadece bir belgeden çok daha fazlasını gerektirir. Motivasyon, süreçler, eğitimler, araçlar vb. Çok daha önemlidir.

Açıkça yeterince ifade edilmemiş olan çok önemli bir şey, kodlama standartlarının dil gibidir: gelişirler. Yazılı bir kodlama standardı bunun önüne geçiyor ve eğer sürekli olarak eskimez ve işe yaramazsa.

Çivilenmiş bir kodlama standardına sahip olmamak o kadar da kötü değil. Check-in sırasında meslektaş incelemeleri yaparsanız, kodlama standardına uygun olmayan bir şey depoya girdiğinde, bunun hakkında 2 kişi düşünmüş demektir * ve bu varyasyonun yararı kararın geri kalanıyla tutarsızlığa ağır basar.

Yazılı bir standarda sahip olmamak aynı zamanda bir şirket ekibinin yeni bir proje için kodlama standardında yeni bir varyasyon denemesini önleyecek olan ya da bir şeyi denemek istedikleri için ya da farklı bir standardın pratik uygulamaları olduğu için bürokrasiyi de kaldırır. kullandıkları bazı otomatik araçlarda.

Bir standardın yazılması, orijinal olarak tasarlanandan daha fazla esnekliğin kaldırılması ve aynı zamanda başka şeyler yapmak için harcanabilecek oldukça fazla zamanın alınması eğilimindedir. Kodlama standartlarını asla yazmamanız gerektiğini söylemiyorum, özellikle de farklı yerlerde çalışan ekipler aynı kod tabanında çalışıyorsa, yazılı standartların kesinlikle faydaları olur.

Güçlü bir şekilde ilişkili: Kodlama standartlarındaki evrim, onlarla nasıl başa çıkıyorsunuz?

* Eğer insanlar check-in sırasındaki kodu gözden geçirirken düşünmezlerse, sorunlarınız kodlama standartlarından çok daha büyüktür.

Bunları değiştirmek büyük bir engel haline gelir ve insanlar beyinleri meşgul etmek ve doğru olanı yapmak yerine yasaların harfine güvenli bir şekilde yapışırlar.

Standardın bir kısmının yararsız olduğu ve kodu daha da kötüleştirdiği bir gün gelecek. Bazı insanlar standarda uyacaktır, çünkü yazılıdır ve güvendedirler, çünkü kurallar izlenecek. Standart uyumlu kod yerine iyi kod yazmak isteyenler hayal kırıklığına uğrayacak ve sinirli olacaktır. Argümanlar ve anlaşmazlıklar olacaktır; oysa standart yazılı değilse, keşif ve tartışma olur.

Bence buradaki birçok yazı kodlama standardını stil kılavuzu ile karıştırıyor .

Farklı ekipler tarafından geliştirilen modüllerin aynı derleyici seçeneklerine sahip olmasını sağlamak ve ABI kaç alan girintisinden farklı bir şeydir.

Bir başlık dosyasına genel ad alanını kirletici #include dosyaları ve yapılandırmaya uygun bir yol gibi şeyler olmalı onlar ilk kodlama ve kod incelemeleri sırasında bir kontrol listesi olarak kullanılabilecek şekilde belgelenmelidir.

Özellikle "XXX kullanmayın çünkü YYY ile uyumluluk sorunlarına neden oluyor", diğer kodları takip ederken göreceğiniz bir şey değil çünkü orada değil . Bu nedenle , kod standartların yakalanma şekli olsun, bazı standartlar için belirsiz ya da tamamen eksik olabilir ve bu evrensel bir plan olamaz.

İstisnaları kullanmayan veya kullanmamak gibi ciddi yaygın bir şey ve önemli newbazı gömülü sistemlerde olamaz sadece o ISO-9000 gibi üretim standartları temel ilkelerine ters düşmektedir "bilgi (yalnızca) kültürel olduğu" gibi, ortak kültür bilgisine olmaya sol olmak Bu gömülü sistemlerin geliştiricisi kullanıyor (örneğin otomotiv uygulamaları için). Bu önemli şeyler resmi olarak belgelenmeli, imzalanmalı ve dosyalanmalıdır.

Ancak bu , stile değil kodlamaya uygulanır .

C ve C ++ 'nın yaratıcıları, örneğin CaMelCaSe değil , küçük harf adlarının kullanıldığını gösterir. Öyleyse neden bu kadar çok geliştirici, gizli örneği örnek olaydan takip etmiyor? Standart kütüphanenin stili ve kanonik öğretim materyalleri izlenecek tam stil olmamalı mıdır?

Bu arada, insanların yapmak kullanımı gibi kopyalanamaz gereken şeyler için standart kütüphane başlıkları örneğini takip __Uglymakro parametreler için isimler ve olmayan tekrar desen dosyası bulunmaktadır.

Yani malzeme olan genellikle önemli tarzı olarak görmedim ya da tam tersi olan örnekler gerektiğine dair net olmayabilir değil proje kodunda takip edilecek. Her ikisi de "stil" in (veya kodlama kurallarının) en iyi kapalı kaldığı tezine karşı örneklerdir.