Kodlama standartları herhangi bir yazılım geliştirme organizasyonunda ortaktır, ancak takip edilmesi ne kadar önemlidir? Bazı tutarlılık ihtiyacını anlayabiliyorum, ancak parantezlerin konumu, hat uzunluğu vb.Gibi basit şeylerle uğraşırken, aşırı sıkı standartların yazılım geliştirmeye çok katkıda bulunduğundan emin değilim.
Kodunuzun okunabilir olması, önceden tanımlanmış bir standarda uygun olması daha önemli değil mi? Görünüşe göre daha çok ... kurallar gibi.
Yanıtlar:
Herkesin aynı standart kod biçimlendirme kılavuzuna% 100 bağlı kalmasını istemek, aynı yazma stiliyle 100 sayfalık bir kağıt yazmak için herkesten ayrı olarak işbirliği yapmasını istemek gibidir.
Umarım herkes makaleyi İngilizce (veya aynı dilde) yazacaktır, ancak farklı stiller belirgin olacaktır. Bazıları iyi yazacak, bazıları yazmayacak. Bazıları kasılmalar kullanacak, bazıları kelimeleri tamamen heceleyecek (örnek: verus olduğu gibi). Vb.
Bence en önemli noktalara değindiniz:
Kodun, aynı yazma tarzında olduğu gibi, aynı biçimlendirmeye uymasını istiyorsanız, düzenlemesi ve düzeltmesi gerekir. Kodun temizlenmesi, incelenmesi, yeniden faktoring edilmesi vb. Gerekecektir.
Başka bir geliştiricinin kodlama stilinden veya biçimlendirmesinden tamamen mutlu olduğum bir dükkanda hiç bulunmadım (en azından benim gibi değil). Ama okuyabiliyor / anlayabiliyor ve tutarlıysa memnun olacağım. Diğer her şey sözdizimsel şeker üzerindeki şekerdir.
Sorunuzu cevaplamak için: biraz önemli, ama eğer yapmazlarsa dünyanın sonu değil.
Biçimlendirme standartları için, herkesin ne yaptığını takip ediyorum. Her şey için PascalCase kullanıyorlarsa, PascalCase kullanıyorum. Eğer _camelCase kullanıyorlarsa, o zaman _camelCase kullanıyorum. Neden? Çünkü yaptığım yeniden biçimlendirme miktarını ve "iyi görünmesi" için başkalarının yapması gerekeni sınırlıyor. Biçimlendirme standartları genellikle işleri herkes için kolaylaştırır.
Mevcut işimde ilk görevlerimden biri geliştirme grubumuz için bir kodlama standardı oluşturmaktı.
İlk çabam yaklaşık altmış sayfa uzunluğundaydı (Microsoft'un Çerçeve Kılavuzlarının çoğunu içeriyordu). Benden ayrılmam istendi ve bir sonraki çabam on sayfa uzunluğundaydı ve çeşitli iyi kaynaklardan fikirler kullanıyordu. Benden tekrar incelemem istendi ve sonunda üç ya da dört sayfaya indirdim.
Hiç kabul görmedi.
Neden? Çünkü zaten içgüdüsel olarak mantıklı bir kodlama standardını takip eden gerçekten akıllı insanlarla çalışıyorum.
Benim açımdan, Microsoft'un genel kabul görmüş yönergelerini takip ediyorum ve diğerlerinin yaygın olarak kullanılan stillerini taklit ediyorum (Javascript ve jQuery, her ikisi de süslü ayraç dili olmasına rağmen C # 'dan farklı biçimlendirilmiş ). Ayrıca zaman zaman kuralları çiğniyorum, bunu yaparken kodu daha okunabilir hale getireceğim.
Bunun temelini sizin yerinize yapan IDE kullanıyorsanız (örneğin, Visual Studio), IDE'nin bir şey yapmasına izin verin ve IDE'nin bir şey yapmasına izin verdiğiniz sürece değiştirmenize bakmak zor görünüyorsa, otomatik biçimlendiren bir sonraki kişi zaten onu öldürecek.
Bir kişi için en okunabilir olanı tüm insanlar için olmayacaktır.
Bu tür bir IDE kullanmıyorsanız, bir tane alın. Bunu 10 dakikadan fazla düşünmek bile IMHO kaynak israfıdır.
Kodun hızlı bir şekilde anlaşılmasına yardımcı olmak için sözü edilmeyen bir fayda olduğunu düşünüyorum. Kod biçimlendirmesi bir projeye ve tüm geliştiricilere ne kadar benzer olursa, kodla o kadar kolay (ve bilinçaltında) çalışabilirsiniz.
Uzun zamandır basit hatalarla bile uğraşmaya çalıştıktan sonra küçük geliştiriciler bana geldi. Kod formatımızı onlarla uygulamak için birkaç dakika geçtikten sonra, daha önce kaçırdıkları hatayı hızlı bir şekilde görebildiler.
Okunabilirlik kesinlikle önemlidir. Kod biçimi standartlarınız iyi düşünülmüşse ve düzgün bir şekilde kullanılıyorsa, kodu okuyabilmenin ve kodu daha hızlı anlayabilmenin ötesine geçebileceğinizi görebilirsiniz.
Kodlama formatlarımızı geliştirirken veya güncellerken kullandığım bir dizi kılavuz Gestalt Gruplama İlkeleri - http://en.wikipedia.org/wiki/Gestalt_psychology#Gestalt_laws_of_grouping
Doğrudan bir sonuç / örnek olarak kod biçimlendirmemiz, herhangi bir blok kodun (if, anahtar vb.) Bir sonraki satırda açık ayraç içermesini gerektirir, böylece kapanış ayracıyla aynı hizaya gelir:
if(true)
{
}
Simetri İlkesi ile zihniniz açık ve kapanış ayraçlarını görecek ve kod bloğunu doğal olarak daha hızlı algılayabilecektir.
After taking a few minutes to apply our code format with them, they were quickly able to see the bug that they had missed before.Bunun nedeni, kod biçiminizin hatayı görmelerine yardımcı olması değildir. Çünkü kodu yeniden biçimlendirme görevi onları daha önce gözden kaçırdıkları koda dikkatle bakmaya zorladı.
Hangi dili veya aracı kullanırsanız kullanın, bir şeyler bulun. IDE'nizi yapılandırın ve yapılandırma dosyasını kontrol edin.
Herkes projeyi kontrol ettiğinde, aynı biçimlendirme stillerini kullanır. Tarzın ne olduğu önemli değil, sadece tutarlı. Boşluk v. Sekmeleri ve kıvırcık parantezlerin hangi çizgi üzerinde devam ettiği konusunda kendi tercihlerim var. Ama kendi tercihlerimden daha fazla, sadece belirli bir kaynak kodu dosyasının kendisiyle aynı fikirde olduğunu umuyorum. Bir biçim savaşından kaynaklanan bir karmakarışık olmaktan çok daha okunabilir hale getirir.
Şimdiye kadar karşılaştığım en kötü şey hiçbir kodlama standardı kullanmamak. Ve bazı kod bloğunu daha okunabilir hale getirmeniz yasaktır çünkü farklı araçları bozar ... Değişiklikleri uygulamak için yamaları kullandığımızdan (değişiklik / hata düzeltme isteği -> düzeltme / değiştirme -> yama -> yama "güvenilir" kişi tarafından uygulanır -> taahhüt) oldukça komik görünümlü kaynak kodu (okunabilirlik açısından) alabilirsiniz. En azından iki harf değişkeni (-.
En komik şey, herkesin bunu değiştirmemiz gerektiğini kabul etmesi. Birkaç yeniden biçimlendirme denemesi bile vardı (taahhütte otomatiktir), ancak tek bir küçük itsy bitsy biçimlendirme seçeneği eksik olduğu için - her şey bitti. Görüş ... [/ rant]
Yönergeler kod kalitesini artırmaya yardımcı olur:
yazar açısından: birçok kural hataların girişini azaltmayı amaçlamaktadır. Örneğin, if()veya for(;;)yapıların tek bir komutla değil, bir blokla takip edilmesi gerektiğini belirten bir kural , ilk kodlayıcının amacını açık hale getirir ve sonraki kodlayıcıların bunu sürdürmesine yardımcı olur.
okuyucu bakış açısından: mutabık kalınan yönergeleri izleyen kod, çeşitli stillere sahip koddan daha verimli bir şekilde incelenir. İnceleyen, olası hataları nerede arayacağınızı daha az çabayla daha iyi bilir.
Bir takımın yapması ya da yapmaması gereken şey için evrensel bir standart yoktur. Bazı takımların katı kurallara uyması gerekir, bazıları buna uymaz.
Mesele şu ki, bir ekip olarak birlikte çalışmalı ve ekibiniz için neyin en iyi olduğuna karar vermelisiniz . Kodun okunması kolay olmalıdır, çünkü büyüklük sıraları yazıldığından daha fazla okunur. Ekibinizin okunabilir kod oluşturmak için rehberliğe ihtiyacı varsa, bir kodlama standardına sadık kalın. Eğer yapmazsan, yapma.
Tüm söylenenler, çoğu takımın değişkenleri, işlevleri ve sınıfları, pozisyon parantezlerini vb. Adlandırmak için standart bir yol üzerinde anlaşmaktan fayda sağlayacağını düşünüyorum. Takım bu kadar basit bir şey üzerinde anlaşamazsa, nasıl bir araya gelip gerçekten önemli kararlar almayı bekleyebilirler? Ayrıca, ekibiniz sonsuza dek aynı insanlardan oluşmayacak - insanlar ayrılıyor, yeni insanlar işe alınıyor. Yeni insanların kod tabanını bulması ne kadar kolay olursa, kodun kalitesini düşürmeden ekibe daha hızlı katkıda bulunabilirler.