Örgütlerde kodlama tarzı isteğe bağlı bir şey midir?

Bu programlama stili belgenin genel bir kuralı vardır:

Onlara karşı güçlü kişisel itirazlar varsa kurallar ihlal edilebilir.

Bu düşündüğüm gibi çarpışıyor ve kodlama stilinin gerçekten önemli olduğunu söyleyen birçok makale var. Örneğin bu diyor ki:

Kodlama standartları belgesi, geliştiricilere kodlarını nasıl yazmaları gerektiğini söyler. Her geliştiricinin kendi tercih ettiği stilde kodlama yerine, tüm kodu belgede belirtilen standartlara yazar. Bu, büyük bir projenin tutarlı bir şekilde kodlanmasını sağlar - parçalar farklı programcılar tarafından farklı şekilde yazılmaz. Bu çözüm yalnızca kodun anlaşılmasını kolaylaştırmakla kalmaz, aynı zamanda kodu inceleyen geliştiricinin tüm uygulama boyunca ne bekleyeceğini bilmesini sağlar.

Öyleyse, bu belgeden bir şeyler yanlış mı anlıyorum ve bu sorunun üstündeki alıntı mı? İnsanlar gerçekten sadece kodlama stilini görmezden gelebilir mi?

Belki de yeterince açık değildim, bu yüzden bu düzenleme ile biraz netleşeceğim.

Ekibimiz için kodlama stili belgesini yazıyorum ve bazı statik analizörleri kullanarak stili kontrol etmek istiyorum. Başarısız olursa, Jenkins e-posta gönderecek. Stil uyuşmuyorsa kod incelemesinde başarısız olmak istiyorum. Bu açıkça ilk alıntı ile çarpışır.

Ama sonra, eğer teklif doğru ise, birileri ne isterse yapabilirse, kodlama stili belgesinin kullanımı nedir?

Söyleyebileceğim kadarıyla, sizi şaşırtan ifade, kılavuzların mümkün olduğu kadar geniş bir kitleye hizmet etmesi için yapılan pratik bir uzlaşmadır. Özel içeriğinize bağlı olarak (aşağıda daha fazlası), ayarlama ve kılavuzları daha verimli kullanma seçeneğiniz olabilir.

Gördüğünüz gibi, kurallar ihlali haklı çıkarmak için “güçlü kişisel itirazlara” atıfta bulunmaktadır. Bu itirazlar, özellikle tecrübeli geliştiricilerin geliyorsa, hafifçe görmezden gelinecek bir şey değildir.

Bu itirazlar yanlış olabilir , aklınızda bulundurun, ancak (ve bu çok büyük bir AMAÇ) ayrıca belirli bir kuralın yanlış olduğunu da belirtebilirler - ya genel olarak ya da belirli bir projenin bağlamında (kurallara uyumsuzluğun bir örneği; performans kritik kodunda ayrıntılı günlük kaydı).

Herhangi bir mantıklı stil rehberinin yukarıdakileri göz önünde bulundurması ve kendisini ayarlama olasılığını yerine getirmeye çalışması gerektiğini düşünüyorum. Şimdi, kafanızı karıştıran rehber, yalnızca verimli ve sorunsuz süreçler ve çevreye sahip olgun ekipleri hedef aldıysa, örneğin aşağıdaki gibi çok daha az belirsiz bir şekilde söylenebilir:

Kurallara, bunlara karşı bir meydan okuma ortaya çıkmadıkça - bu durumda, zorlu kural bu çözülene kadar görmezden gelinmelidir - ya meydan okumayı reddederek ya da kabul ederek ve kuralları uygun şekilde ayarlayarak.

Yukarıdakileri daha çok beğenebilir ve herkes için her yerde bu şekilde olmasını isteyebilirsiniz, ancak bu “meydan okuma yükseltilir / yok sayılır / ayarlanır” bölümüne daha yakından bakın ve kendinize nasıl uygulanabileceğini sorun. Kendinize projeye ve takıma bağlı olarak ne kadar sürebileceğini sorun . Bir saat sürerse, bu kabul edilebilir mi? Ya bir gün, bir hafta veya bir ay sürerse?

Görüyorsunuz, çözülene kadar görmezden gelinme yaklaşımına kadar olan yaklaşım, herhangi bir projeye rehberlik etmesi halinde kötüye kullanım için geniş bir kapı açabilir. “Evet, evet, sizi duyuyoruz, rehberin söylediğini yapalım. Öncelikle, bu sorun formunu doldurun ve CEO / CFO / CTO onaylarını alın; bunun bir veya iki hafta sürmesini bekleyin. Bundan sonra, kod kontrollerimizi güncelleyene kadar bekleyin. bir veya iki hafta sürebilir. Bu arada, performans kritik kodunuzun her kayıt hareketi için uygun biçimde biçimlendirilmiş günlük ifadeleri kullandığından emin olun. "

Rehber yazarlarının aklını okuyamıyorum ama yukarıda açıklandığı gibi bir karışıklığı haklı çıkarmak için kullanmaktan kaçınmak istediklerini varsaymak makul görünüyor. Bu açıdan bakıldığında, kılavuzun herhangi bir yaptırım kabul etmediğini açıkça belirtmek daha güvenlidir - ancak bu şekilde sakar, yine de keyfi bir şekilde geniş bir yelpazedeki ekipler ve projeler için kullanılabilir olmasını sağlar. Muhtemelen, bu kadar geniş bir ödeneğin daha olgun ve verimli ekiplere geliştirici verimliliğine zarar vermeden makul ölçüde daraltma fırsatı bırakması beklentisi vardır.

Özel durumunuza uygulanırsa, ekibiniz için kodlama stili belgesini yazın ve stil uyuşmuyorsa kod incelemesini başarısızlığa uğratın - geliştiricilerin belirli bir kurala itiraz etmesi için ne kadar zaman alacağını, göz ardı etmeyi düşünmeniz gerektiğini düşünüyorum. çözüldü ve çözünürlüğe bağlı olarak değiştirilmesini veya kurtarılmasını sağlayın.

Gelişim iş akışınıza pek çok engel getirmeden bu işlemi gerçekleştirmenin bir yolunu bulursanız, zorlukları / çözüm yollarını izlemek için resmileştirilmiş ve kolay bir yaklaşım, kaotik "yeteri kadar yüksek sesle ağlarsanız" yerine, gerçekten de buna değer.

Bir ek not olarak, başka bir yorumda yazdıklarınıza değinmek istiyorum , "Kodlama stilinin ideal olduğunu ve durum böyle değilse, varsayalım."

Bu gerçekten tehlikeli bir varsayım. Burnumu kırdım (iki kere! Tek bir projede! Engin bir deneyime sahiptim ve onunla ilgili her şeyi bildiğimi hayal ettim, gitmeye başladım) ve bırakmanızı şiddetle tavsiye ederim. Stil rehberinin hata yaptığını varsaymak ve bu tür hataların keşfedilmesi durumunda ne yapılması gerektiğini düşünmek için çaba sarf etmek daha güvenlidir.

İnsanların kişisel tercihlerden dolayı kodlama stillerini görmezden gelmelerine izin vermek kötü bir fikirdir.

Sorunuzdaki alıntı herhangi bir geliştiricinin "Bu tarzı kullanmayacağım çünkü hoşuma gitmiyor" demesine izin veriyor gibi görünüyor.

Bu, takımdaki herkesin aynı şeyleri tutarlılık ve okunabilirlik için aynı şekilde yapmalarını sağlayan tüm konuya aykırıdır.

Böyle bir ifadeye sahip bir stil belgesinin muhtemelen anlamsız olduğuna katılıyorum.

Bununla birlikte, stil kurallarına uyma konusunda biraz esneklik önerilebilir:

• Bir kuralı takip etmek, belirli bir kod parçasını yazmanın en iyi yolunu engelleyebilir . Geliştiriciler bu ilkeyi görmezden gelebilmeli ve yaptıkları şeyin bu durumda bir şeyi başarmanın en iyi, en okunaklı yolu olduğunu belirtebilmelidir.
• Eski kodla çalışmak esneklik gerektirebilir. Muhtemelen mevcut büyük bir kod üssünü dinlendirmek için iyi bir zaman değil. Belirli bir bölümü önemli ölçüde yeniden yazarsanız, tercih ettiğiniz stile yeniden biçimlendirebilirsiniz. Ancak, yalnızca küçük bir değişiklik yaparsanız, kodun mevcut stilini kullanmak daha iyi olabilir.
• Stil rehberinin her küçük ihlali hakkında bilgi edinmek zamanın iyi bir kullanımı değildir. Kod incelemesi, ekibin tarzına büyük ölçüde uygun olmayan herhangi bir kodu vurgulamak için iyi bir zamandır. Bununla birlikte, küçük tarz "hataları" yakalamak ve düzeltmek, yanlış şeye odaklanan yoğun bir iş haline gelme eğilimindedir. Elbette, stil açıkça göz ardı edildiyse kod incelemesinde başarısız olun. Ancak analizör çalıştırma ve yanlış yerleştirilmiş her parantezi veya girintiyi işaret etme fikrinden hoşlanmıyorum.

Sonuç olarak: ekibinizin ihtiyaçlarını en iyi şekilde karşılamak için stil kurallarına uyma esnekliği sağlayın - kişisel tercih gibi rastgele nedenlerden ötürü değil.

Kodlama stili ve stil kılavuzları, kodu daha okunaklı hale getirmek için mevcuttur. Ve okunabilirlik, karmaşıklığa yardımcı olmak için vardır.

Dolayısıyla, nihayetinde ihlal edip etmemek (uyum olarak adlandırmak) örgütsel ihtiyaçlarınızı karşılayacak kodlama stilinin, işlerin anlaşılabilir olmasına ne kadar yardımcı olduğunu ortaya koymaktadır.

Unutmayın, her şey ve OO programlamasından işlevsel paradigmalara, çeşitli eşzamanlılık modellerine kadar HER ŞEYE vurgu yapıyorum, insanların karmaşıklıkla başa çıkmalarına yardımcı olmak için var.

Herhangi bir aptal bir bilgisayarın anlayabileceği bir kod yazabilir. İyi programcılar, insanların anlayabileceği bir kod yazar. - Martin Fowler, 2008

Örgütlerde kodlama tarzı isteğe bağlı bir şey midir?

Örgütler kodlama stillerine sahip olmayı tercih eder - ilk başta olması şart değildir.

Bu nedenle, okuduğunuz alıntı, "stil" ve gerçek süperstar "bilgisayar korsanları" kodlamasıyla ilgili gördüğüm en büyük sorunu ele alıyor - gemiye yeni bir adam getiriyorsunuz ve zombileri bırakacak ve sizin eski sunucularınızı hızlı bir şekilde çığlık atan hale getiren bir kod yazıyor. .. ama onun kodlama stili, "kabul edilen organizasyon stilinden" farklı. Değişmeyi reddediyor ve herkesin kendi tarzına uymasını sağlama süreci zaman alıcı ve pahalı olacak. Şimdi ne olacak?

Bildiğim süper bilgisayar korsanlarının çoğu, yetenekleri kadar büyük egoları ile birlikte geliyor ve örgütün kendilerine uyum sağlamasını istiyorlar . Yani, belki kodlama stili, standart daha bir gibi olmalıdır kodlama stili kılavuz bu katil korsan adam bazı stil sapma ile hızlı yanan ve şaşırtıcı kod yazmaya devam edelim, ama herkes anlar emin olabilir ki bu onun epik korsanı ulaşana kadar statü, kuralları takip etmeleri gerekir (hatta ondan sonra temizlemeye yardım ederler).

Tabii ki, bu bir yönetim kabusu, ama genel olarak teknoloji insanları yönetmek, yine de kedi gütme gibidir. Bu yüzden çoğu şirket "stil standartları" yerine "stil kuralları" na sahiptir. Yapılar başarısız olmaz ve kod incelemeleri tüm şirketlerde yapılan stil ihlalleri nedeniyle otomatik olarak başarısız olmaz. Sahip olmak istediğiniz yönetim sorununa karar verirsiniz - süperstar bilgisayar korsanlarına izin verin ve "kurallara" sahip olun, süperstarları kaybettin ve daha tutarlı kod stiline sahip olun.

Öyleyse, bu belgeden bir şeyler yanlış mı anlıyorum ve bu sorunun üstündeki alıntı mı? İnsanlar gerçekten sadece kodlama stilini görmezden gelebilir mi?

Değişir.

Şu an bulunduğum yerin stil rehberi yok ve çok da önemli değil. Programcılar arasında okunabilirliği, keşfedilebilirliği veya tutarlılığı herhangi bir anlamlı şekilde etkileyecek kadar küçük farklılıklar vardır. Ve ekibe yeni katılan herhangi bir üyenin aynı sıraya girmesini sağlamak için yeterince büyük bir gruba ve yeterince güçlü bir kültüre sahibiz.

Daha önceki şirketlerde, hızla büyüyoruz ve dili ve deyimlerini bilmeyen bazı insanlara sahiptik. Bu şirkette, insanların akını, iyi yazı yazmayı zorunlu kılan bir kültürün olmadığı anlamına geliyordu. Dilde yeni insanlar, düzeltilmesi gereken çok şey olduğu anlamına geliyordu. Orada otomatik stil dama düzenlemeler yaparak en etkili yolu olduğunu ve gerçek bir yazılı rehber bizim beklentileri yeni millet yetiştirmek için en iyi yolu oldu.

Şahsen, stil rehberlerine pek de önem vermiyorum ve otomatik stil uygulamalarına daha az önem veriyorum. Eğer kişi temel deyimleri bile alamıyorsa, neden onları bir programcı olarak kullanıyorsunuz? Ve eğer o kadar kötü bir takım oyuncusu iselerdi ki, başkalarının birlikte çalışmayı zor bulduğu kodları sürekli yazacaklar, neden onları kullanıyorsunuz?

Bu, kodlama stillerini en iyi nasıl yöneteceğine dair bazı gerçek yorumlar yerine, daha çok psikolojik bir hile. Takım / şirket / yönetici / lideri daha az otoriter yapar. Kişisel yerine durumsal istisnalara daha çok odaklanacağım. Kodlama belgesinden bağımsız olarak amaç, okunması kolay şeyleri sağlamaktır. Kafa karıştırıcı kod gerekli görüldüğünde ele alınmalı ve değiştirilmelidir. Küçük sıkıcı şeylerle ilgilenmek için birçok araç var, bu yüzden onları kullanın.

Her kuralın istisnaları vardır. İnsanlara "biraz" kıpırdatma odası verin. Kodlama stil kurallarını kabul etmekle daha az herkes ilgilenir (Hoşgeldin yeni adam.), Daha çok savaşmaya istekli olurlar. Birçok şey siyah ve beyazdır, ancak bazıları yorumlara açıktır.

Amaç, her küçük ayrıntı ve yorumla mücadele etmek yerine, herkesi kodlama ilkelerinin ruhuna dahil etmektir.

Evet, kodlama stili belgesinin kullanımı mantıklı olmadığı ve profesyonel ve yetişkin geliştiricilerin farkı bilmelerine izin verilmesi gereken bir zaman gelecektir.

Düzenlemelerinize dayanarak, doğru amacı hedeflediğiniz.

Bir stil rehberi kullanmanın birçok yararı var, ama bence en önemlisi, ekip üyeleri arasında kodun okunabilirliği ve "saçma" taahhütlerin olmaması (sadece beyaz boşluk veya ekstra çizgiler ve benzerleri).

Hedefinize ulaşmak için, seçtiğiniz (veya oluşturulan) stil rehberiniz basit ve kolay bir şekilde uygulanmalıdır. Gereksinim duyduğunuz şeye odaklanmaya çalışın. Hiç kimse geri dönüp sadece bir linter mutlu etmek için büyük kod örneğini yeniden yazmak zorunda kalmayı sevmiyor. Ancak yine de bazı faydalar olabilir.

Ekip üyelerinizin stil rehberini onayladığından emin olun. Onları ona tutacaksın, aynı fikirde olduklarından emin ol yoksa ebedi bir mücadele olacak.

Stil ihlallerinin bir "uyarı" olduğundan ve "başarısız" olmadığından emin olun, ihlalin başarısızlıkla sonuçlanıp karşılanmadığına karar vermesine izin verin. Bunun nedeni basit. Basit bir iş akışına inanıyorum. "Test" aşamasında bir yerde "başarısız" olursa, üretime zorlayamazsınız. Kullandığım bir güvenlik gibi. Sıcak düzeltmeler bile test aşamasından geçmelidir (daha kısa bir süre olsa da). Gerçekten biriniz bir "yerine" kullandığı için bu kritik hata düzeltmesini üretime sokmayacağınızı söyleyebilir misiniz? Her biri için bir for döngüsü kullanmaya ne dersiniz? Bir makinenin (linter) yapamayacağı kararlardır, bu nedenle bir insana sahip olduğunuzdan, uyarıya karar verdiğinizden ve makine arızalanmadığından emin olun.

Tarz rehberini görmezden gelmek için, duruma göre bunu yargılamak zorunda kalacaksınız. "Sapma" nın gerçek bir sebebi olduğundan emin olun. Gelecekler. Gözden geçirenlerin işi, sapma için değil, önemsiz bir sebep için iyi bir neden olduğundan emin olmaktır.

Bence buradaki ruh hali müziği, eğer kabul edilen bilgelik, kodlama standartlarının yanlış veya eksik olduğuysa, o zaman, geliştiricilerin zorlu bir süreçten geçmek yerine genel mutabakata varmışsa, üzerine basılması gereken iki kötülüğün daha az olduğunu düşünüyorum. doküman değiştirildi ve yeniden incelendi.

Ayrıca, notteryear'ın standart kod uygulama politikalarının tipik olarak işlerin şu anda yapıldığı gibi olmadığı da belirtilmelidir.

Eski günlerde, geliştiricinin masasının sonunda tome tutarken sallanırsınız ve bölümünün alıntılarını yapar ve neden kodunun 34.5.5767 bölümünü ihlal ettiğini öğrenirsiniz.

Artık çok sayıda kod standardının zorluğunu alan statik kod analizi ve otomatik dokümantasyon araçlarına sahibiz.

Tüm bunları başaramazsanız, geliştiriciye geri atabilir, bir kod incelemesinde yükseltebilir veya çok eğimli iseniz sadece kendiniz değiştirebilirsiniz.

Sorunuz, iki teklifi uzlaştırmak etrafında toplanıyor. Sanırım ağaç kod yazıcısının yazdığı soru genellikle sorunuzu yanıtlar. Stil kuralları yazmada yol gösterici ilkenizi temsil eder.

Daha spesifik olarak, kodlama stili kurallarını belirlemekten sorumlu olduğunuzdan (bu, belge yazarı olduğunuzdan beri benim varsayımım), neyin isteğe bağlı olup olmadığına ve kişisel stilinizde hangi dereceye kadar esnekliğe izin vereceğinize karar vereceksiniz. takım. Gerektiğinde geri bildirim alacaksınız. Ancak kurallar yerine getirildiğinde, onlarla bağlantıda kalın.

Böylece bunun gibi görünen iki çelişkiyi uzlaştırabilirsiniz:

Kurallar belgesi tamamlanmadan önce, stil karar vericisi olarak size sunulan ilk teklifi düşünün. Belirli bir stil standardı ekibiniz için işe yaramazsa, bu “güçlü kişisel itiraz” olarak sayılır ve rehberiniz bunu yansıtacaktır.

Belge tamamlandıktan sonra ikinci teklifi ekibinize hitap ettiğiniz gibi düşünün. Takım için kuralları belirledikten ve doküman yazıldıktan sonra, ekibinizdeki tüm geliştiricilerin stil kurallarına uyması önemlidir.

Kodlama stilinin, kodlama stilinin olduğu sürece, sahip olduğu şeylerin önemi yoktur. Bir şirket kodlama stilinde ısrar ederse, geliştiricilerin yaklaşık% 49'unun ayak parmaklarına basar.

Buradaki sorun, çok sayıda geliştiricinin kodlama stillerini bir şirkette yaygın bir standarda uyarlama konusunda çok fazla sorun yaratmadığı, ancak şirket politikalarında daha iyi (veya sadece daha fazla önemseyen) kişiler tarafından söylenmesini çok fazla önemsemeleridir.

Bu, bir kodlama tarzı standardı oluşturmak anlamına gelir; büyük bir zaman kaybı, sonsuz bir argüman kaynağı, sonsuz kızgınlığın nedeni ve genel olarak büyük bir zaman ve enerji tüketimi olabilir.

Bu forumda diğerleri gibi, yıllardır kod stili yönergeleri ile boğuldum. Bu, benim hem rahatsız olduğum dövüş stil rehberlerini hem de başkalarını stillerini yeniden dizmek için stil rehberlerini kullanmaya teşvik etmeye çalışmak, böylece bir bütün olarak daha okunaklı olmasını da içeriyor.

Kurum ortak bir kodlama standardından faydalanmaktadır. Bir şirket için yazılım geliştirirken, yeni geliştiricileri önceki neslin kodunu almak için nasıl eğiteceğimiz gibi göz önünde bulundurulması gereken birçok önemli şey vardır. Kod yazarken, her zaman bunu düşünmüyorsunuz. Aslında, birçok kodlayıcı, başkalarının gittikten 5 veya 10 yıl sonra kodlara nasıl yaklaşmak istediklerini bile düşünmemeyi tercih eder. Kodlama stili kılavuzu, bir şirketin bu 5 ve 10 yıllık hedeflere odaklanmasını sağlamanın bir yoludur ve geliştiricilerin daha geniş şeylerle çalışmasını kolaylaştırır.

Öte yandan, kodlama stili kılavuzları açıkça mükemmel değildir, çünkü mükemmel bir kodlama stili geliştirmek ve yazmak mümkün değildir. Aslında, matematiksel kanıtların kusursuz hale getirmeye çalışırsanız başarısız olmaya başladığı komik köşe davalarıyla karşılaşmaya başlarsınız. Dolayısıyla kodlama tarzı kılavuzlarının kusurlu olduğunu biliyoruz. Tam olarak 5 ila 10 yıl boyunca ihtiyaç duyduğumuz şeye odaklanmayabilirler.

Bir kodlama stilini "uygularsak", daha sonra değer için şimdi değeri feda ederiz. Çabalarımızın karşılığını alacağımızdan emin olabilirsek, buna "yatırım" denir, ancak kötü yazılmış bir kodlama stili rehberiyle çalışan herhangi bir geliştirici, bu "okunabilirlik" kazanımlarının, geliştiricilerin dikkatini dağıtacağı için, büyük ölçüde ödendiğinin kanıtı olabilir. kodlarından uzakta. Tecrübelerime göre, zorla kodlama stillerinin hak ettiği çok az sayıda vaka vardır, genellikle yazılımın 30 veya 40 yıl boyunca kullanılabileceği benzersiz buzul müşteriler için yazılımda!

Bunun yerine, kodlama stili rehberini manifesto olarak değerlendirmenin en etkili olduğunu düşünüyorum: "Bu, grubumuz için en iyi kodlama stilinin olduğuna inandığımız şeydir." Sözleriyle belgelenen bir sürü akıcı düşünce. "İnanç" kelimesi önemlidir: eğer inançlar değişirse, kodlama tarzı kılavuzları da bununla birlikte değişmelidir.

"Güçlü kişisel itirazlar" teklifinizin geldiği yer burasıdır. "Mükemmel" bir dünya dediğimde, en iyi olduğunu düşündüğünüz kodu yazarsınız ve sonuçlarıyla yaşarsınız. Programlama yaparken genellikle "yumuşak" sonuçların üstesinden gelmeyi severiz, ancak bu durumda önemlidir. Kendi tarzında yazarken seninle hiçbir problemim yok, eğer sana önemli ve uzun ömürlü bir şey vermeme izin vermezsen.

Tüm sistemi bir golf sahası gibi düşünün. Kodlama tarzı, panayırdaki kolay yolu oluşturur. Kendinizi kodlama standardına bağlı tutarsanız, yaşamın elimizden geldiğince kolay olmasını sağlayacağız. Sertleştikçe, kendi kodlama standartlarınızı kullanarak, takımdaki değerini kanıtlamanız gerekecek.

Pazartesi sabahı gelirsem, bütün hafta sonunu geçirdiğin bir sorunu çözmek için geçirdiğimiz bir sorunu çözmek için harcadığını ve kendi "özel" kodlama standardında yaptığını bulmak için, sana söylemeyeceğim. düzelt. Sana gidip duş almanı söyleyeceğim. "Özel" kodlama standardınız istisnai olarak "özel" ise, bir giriş seviyesi geliştiricisinin, kodunuzun nasıl çalıştığı hakkındaki bilgiyi yaymak için kodu "gözden geçirmesini" önerebilirim ve tereddüt etmeden bir şey okumak zor görünüyorsa toparla. Şirkete, hafta sonu yaptığınız korkunç kodlama standartları ihlallerinden bahsetmemeye bile değecek kadar değer verdiniz.

Elbette, bu golf oynama metaforunda sınırlar dışında. Sizden bir rütbe ve dosya görevi yapmanızı, belki de bir forma yeni alanlar eklemenizi ve tüm form doldurma kodunu, kendi stilinize uyması için, makroları tanımlamak gibi bir sürü gölgeli karakter kullanarak yeniden düzenleme fırsatını kullanmaya karar verirseniz ve borsadan yeni öğrenmiş olduğunuz bazı müthiş şablon meta-programlama tekniğinden, geri dönüp düzeltmeniz istenecektir. Sen hareket etmeyi seçtin, sonuçları bunlar.

( Feragatname: Bu uygulamayı genel bir reddi is_base_ofgörevi çözmek için yazdım ve üst düzey geliştiricilerden aldığım cehennemin her bir parçasını kazandım. Buna değer olduğunu söyledim. Bu kalitenin nasıl bir araya geldiğini görmek için birlikte C ++ teknik özelliklerinin 7 ilgisiz bölümünü bir araya getirerek şaşırtıcı bir şeyler yapın. Bunu üst düzey geliştiriciler edin! Bu boostözel projeyi yasaklamak için ne elde edersiniz ! )

Hemen hemen her iniş IDE'sinin yerleşik bir özelliği olan ve neredeyse daha fazla veya daha az yaygın programlama dili için bulunması gereken otomatik kod formatlayıcıyı kullanmak en iyisidir. Bu, kod incelemeleri sırasında birçok gereksiz işi ve sürtünmeyi sessizce ortadan kaldırır.

Tüm geliştiricilerin, biçimlendiriciyi kodun yeni oluşturulan bölümüne uygulama alışkanlığı geliştirmelerini istemek tamamen mantıklıdır.

Yapabileceğiniz en kötü şey, mevcut kod formatlayıcının desteklemediği bazı özel kodlama stillerini istemektir.

Nispeten nadir durumlarda, formatlayıcı bunu gerçekten çok fazla yaparsa bazı bölümler farklı formatlanabilir, ancak genellikle formatlayıcının herkesin daha iyi formatlanması için ayarlanması daha iyidir.

Biçimlendiricinin destekleyemeyeceği bazı yararlı kurallar olabilir (örneğin, değişkenlerin nasıl adlandırılacağı gibi), ancak yalnızca bunlar kalırsa, izlemeleri nispeten kolaydır.

Gerçek Çözüm (sadece felsefe değil)

Kod açıklamalarının geçersiz kılmaya çalışmasına izin verin ve isterseniz yorumların listesini derleyin (yorumlarda sıkça yapıldığı gibi)

Geliştiricilerinize kongre dışında açıkça ve makul bir şekilde çalışma yeteneği verin - ve insanlar tarafından yapılan kod incelemeleri sırasında ihtiyaç duyuldukça incelenebilir.