Bir Takımda Çakışan Java Stilleri

6 haftalık bir süreye sahip bir Java geliştirme ekibinin üyesiyim. Bu, çok hızlı bir şekilde iyi bir kod yazmayı gerektirir. Ancak geliştirme ekibimizin farklı kodlama stilleri vardır. İsim sözleşmelerinden soyutlama yöntemlerine kadar her şey ekibimiz arasında farklılık gösterir. Java için "standartlar" dikte eden herhangi bir belge bilen var mı?

Açıklığa kavuşturmak için, örneğin değişkenler ve işlevler için uygun adlandırma kuralını dikte edecek bir organizasyon olup olmadığını merak ediyordum. Bu kadar kısa bir süre için birbirimizin kodunu anlamaya çalışmak için zaman harcayamayacağımız kadar önemli.

Böyle bir organizasyon var: Sun / Oracle'ın kendisi. Belgeye Java Programlama Dili için Kod Kuralları denir ve ihtiyacınız olan kuralların çoğunu açıklar. Sadece herkesin okumayı ve tavsiyelerini takip etmesini isteyin.

Gerçekten Andres'in cevabını etiketliyorum ve düzgün bir şekilde java kodunu biçimlendiren yönlere odaklanıyorum.

Eclipse kullanıyorsanız, Java biçimlendiricisini otomatik olarak Java standardına biçimlendirecek şekilde ayarlayabilirsiniz. Eclipse formatlayıcı ayrıca satır başına karakterler (yani yeni bir satıra geçmeden önce satır başına kaç karakter) ve diğerleri gibi başka yardımcı ayarlara sahiptir. Satır başına karakterlerin standartlaştırılması , farklı geliştiriciler tarafından yazılan kodun, yalnızca boşluk ve satır kesmeleri arasında çok fazla farklılığa sahip olmadan fark edilmesini kolaylaştırır .

Son olarak, Eclipse ile, istediğiniz tüm ayarları ayarladıktan sonra, biçimlendiricinizi ekibin her üyesi tarafından alınabilecek bir dosya olarak dışa aktarın. Eclipse kullanıyorsanız, sizin için otomatik olarak biçimlendireceği ve kod düzenleyeceği tüm seçenekleri tam olarak keşfetmenizi ve ardından ayarları tüm ekiple paylaşmanızı şiddetle tavsiye ederim.

Diğer büyük java IDE'lerin (IntelliJ ve Netbeans) biçim ayarlarını vermek için benzer bir özelliğe sahip olduğunu varsayabilirim.

Bu [farklı kodlama stilleri], birbirlerinin kodlarını anlamaya çalışmak için zaman harcayamayacağımız kısa bir süre kadar önemli.

Aslında. Bu çok önemli değil.

Danışman olarak 30 yıl sonra, birçok müşteriden çok sayıda kod okudum . Her müşterinin (ve genellikle bir müşterinin organizasyonu içinde) farklı stiller olduğunu not etmek önemlidir.

Çok fazla stil okuduktan sonra bunu öğrendim.

Stil Önemli Değil

Lütfen her zaman işe yarayan kod yazmaya ve her zaman işe yaradığını kanıtlayan birim testleri yazmaya odaklanın.

Çalışma kodunu gönderdikten sonra, düzeltmek için hatalar ve yüklemek için geliştirmeler yaptıysanız onu giydirebilirsiniz.

Mükemmel bir evrensel standart seçme konusunda endişelenmeyin. All you need olan sizin takım kabul etmek bir o standart ve sopa. İsterseniz kendiniz yapın, ancak tutarlı olun.

Tutarlılık işbirliğini geliştirir, işbirliği kodu geliştirir.

Gerçek tutarlılık yardımcı olmasa bile, ekibinizin bir anlaşmaya varmak için birlikte çalışması iyi bir şeydir. Kodlama kuralları kadar basit bir şeyi kabul edememeleri, yüzeyin altında gizlenen daha büyük ekip çalışması sorunları olabileceğini söylüyor.

Yukarıda bahsedilen Sun Java CC sadece 13 yaşında değil ve bazı kuralları eski (satır başına 80 karakter gibi) değil, aynı zamanda en genel olanlar (sınıflar için deve gövdesi, blok başlıkları hariç) adlandırma kurallarını tanımlamıyor statik son değişkenler ve benzerleri için).

DAO'lar, EJB'ler, varlıklar, ne kullanırsanız kullanın, farklı sınıf türleri için kendi standartlarınızı tanımlamanız gerekir . Sun Java CC genişletme amaçlı soyut bir temel sınıf gibidir :)

Burada başkaları tarafından belirtildiği gibi, Java için birkaç popüler 'stil kılavuzundan' birini çevrimiçi olarak arayabilir ve takımdaki herkesi bunlara bağlı kalmaya ikna edebilirsiniz. Favori IDE'nizdeki bazı kod denetleme araçları, bunu yapmadığınızda size hatırlatmanıza yardımcı olabilir.

Bununla birlikte, bazen siyaset söz konusudur. Bir zamanlar takımdaki en üst düzey geliştiricinin, birisinin standartlaştırılması gerektiğini söyledikten sonra bile bunu yapmaya devam ettiği bir durumdayım. Böyle bir durumda, kod stilini gözlemlemek ve onu takip etmek daha iyi olabilir, çünkü muhtemelen kod tabanı ve gereksinimleri hakkında en fazla bilgiye sahiptir ve zor olsa bile ayak parmaklarına basmak için zaman kaybetmek istemeyebilirsiniz. Bu durumda geri kalanımızın yaptığı budur ve isteksizce izlerim.

Bu yüzden durumunuzu da dikkate almak önemlidir.

Bob Amca "Temiz Kod" kitabında daha modern ve güncel bir kodlama tarzı gösteriyor. Maalesef öğe listesi içermiyor. Okumalısın. Kendisine, sözleşmelerini görmek için kodunu okumak zorunda olduğunu söylüyor. Bob Amca şüphesiz bir tür kurumdur. Kitap yine de mükemmel bir okuma, bu yüzden şimdi okumak için çok geç olsa bile, en kısa zamanda okuyun.

Kodda asıl önemli olan düşük siklomatik karmaşıklık, küçük kapsam, yüksek uyum ve anlamlı tanımlayıcıların seçilmesidir. Bunlar göz önüne alındığında, kodun kavranması kolaylaşır ve bu kod iyidir.

Spartan Programlamaya bakmanızı öneririm .

Çoğu kodlama standardı, kötü yazılmış kodun nasıl güzel görünmesini sağlar ve "kodlama stili" hakkındaki tartışmaların çoğu biçimlendirme ile ilgilidir. Kod biçimlendirme, kodunuzun yapısını görsel olarak temsil etmektir. Önemsiz ve otomatikleştirilebilir ve kodlama stiliyle neredeyse hiçbir şey yapmaz, çünkü kodlama stili kod yapısını nasıl temsil ettiğinizle değil, kodu nasıl yapılandırdığınızla ilgilidir.
Gerçekten de kötü tasarım etrafında çalışmak için bir kesmek olmasına rağmen, isimlendirme sözleşmeleri hakkında birçok dini savaşlar da var. Bir ad, ne anlama geldiğini söylüyorsa iyidir. Kapsamlarınız ne kadar küçük ve net olursa, böyle bir isim seçmek o kadar kolay olur.