Kod formatlayıcıları düzenli aralıklarla bir depoda çalıştırmak kötü bir fikir olabilir mi?

Kodları kontrol eden, üzerinde kod formatlayıcıları çalıştıran ve herhangi bir değişiklik olursa, değişiklikleri yapan ve geri iten bir cron işi yaratmayı düşünüyorum.

Otomatik biçimlendiricileri kullanan çoğu proje, onları bir git kancasına koyar, ancak birkaç saatte bir otomatik olarak yapmak, her bir devin git kancasını takma yükünü ortadan kaldırır.

Herkesi temiz ve iyi biçimlendirilmiş bir kod yazmaya teşvik ediyorum ve belki de yazdıkları kod yeniden biçimlendirildiğinde sistemin otomatik olarak devs yapmasını sağlayabilirim, böylece gelecekte ne yapmaları gerektiğini bilirler.

Kulağa hoş geliyor, ancak robotlara değil kod değişikliklerini yapmaktan sorumlu kişilerin olmasını tercih ederim.

Ayrıca, bu değişikliklerin hiçbir şeyi bozmadığından kesinlikle emin olmak istiyorsunuz. Örneğin, özellikleri ve yöntemleri alfabetik olarak sıralayan bir kural var. Bunun, örneğin WCF sözleşmelerinin WSDL dosyalarındaki veri ve yöntemlerin sıralanması gibi işlevsellik üzerinde etkisi olabilir .

Bunun yerine ekipteki herkesin ekibinizin standardına göre otomatik kod biçimlendirme uygulamasını gerçekten kolaylaştırmaya çalışacağım doğrudan kaynak düzenleyicinizin veya IDE'nizin içinde bulunduğunuz kaynak kod dosyasına (veya seçilen bölümlerine) . Bu, ekip üyelerinize biçimlendirmenin nasıl ve ne zaman gerçekleştiği konusunda daha fazla kontrol sahibi olmalarını sağlar, son formda işlenmeden önce kodu denetlemelerini ve daha önce değil, biçimlendirme yapıldıktan sonra test etmelerini sağlar .

Ekip üyelerinin tümü veya çoğu aynı düzenleyiciyi kullanıyorsa, bu çok zor olmamalıdır. Herkes farklı bir yöntem kullanırsa, yaklaşımınız takım bunu desteklediği sürece en iyi ikinci çözüm olabilir. Ancak, her otomatik kod değişikliğinden sonra yapılan her gece yapılan kurulum ve otomatik testler gibi ek güvenlik önlemleri almanızı öneririm .

Bu kötü bir fikir, sadece insanları düzgün kod yazmaları için cesaretlendirdiği için değil, aynı zamanda reformun VCS'nizde kod değişikliği olarak görüneceği için (umduğunuzu kullanırsınız), kod geliştirme sürecinin tarihsel akışını maskeleyeceği için de kötü bir fikir. Daha da kötüsü, her kod biçimlendirme eyleminin (gerçekten de kodda yapılan her değişiklik) manuel veya otomatik olsa da, hata sağlama olasılığı vardır. Bu nedenle, biçimlendiriciniz şimdi kodunuzda kod incelemeleri, birim testi, entegrasyon testi vb.

Bunun iyi bir fikir olduğuna inanma eğilimindeyim (otomatik olarak kod biçimleyicileri çalıştırmak için), ama bu sadece benim düşüncem.

Onları düzenli aralıklarla çalıştırmayacağım, ancak mümkünse sürüm kontrolü yapmadan önce.

İle Git , bir kanca önceden taahhüt yararlı olacağını yapıyor. Bazı Makefile ile yapılan birçok C veya C ++ projesinde , bazı indenthedefler ekliyorum (uygun şekilde kod biçimlerini çalıştıran indentveya kodlayan astyle) ve katkıda bulunanların make indentdüzenli çalışmasını bekliyorum . Btw, hatta bazı ekleyebilirsinizmake git kancalarının takıldığından emin olmak için kurallar (veya bunları kurmak için).

Fakat gerçekten, teknik olandan daha sosyal bir konudur . Takımınızın temiz ve güzel bir şekilde biçimlendirilmiş bir kod belirlemesini istiyorsunuz ve bu projenizin sosyal bir kuralı. (Her sosyal soruna her zaman teknik bir cevap yoktur).

Sürüm kontrolü çoğunlukla, insan geliştiriciler arasındaki iletişimi sağlamaya yardımcı olan bir araçtır (bundan birkaç ay sonra kendi özünü de dahil). Yazılımınızın VC veya biçimlendirmeye ihtiyacı yoktur, ancak ekibinizin ihtiyacı vardır.

BTW, farklı topluluklar ve farklı programlama dilleri kod formatlama konusunda farklı görüşlere sahiptir. Örneğin, Go yalnızca bir kod formatlama stiline sahiptir, ancak C veya C ++ birçoğuna sahiptir.

Bence bu kötü bir fikir. Yanıtların çoğu, aslında bir çizgi ekleyen kişiyi tespit etmeyi zorlaştırarak ve insanları sadece ne olursa olsun ve format-bot ile başa çıkacak şekilde işlemeye teşvik ettiği için tarihi zorlaştırıyordu .

Daha iyi bir yaklaşım, derleme aracınıza biçimlendirme denetleyicisi eklemektir. (Java'da Checkstyle var ) O zaman, derleme geçerse (biçimlendirme dahil) insanların yalnızca şubelerini ana dalı ile birleştirmelerine izin verin.

İnsanların doğrudan ana şubeye bağlı olmalarına izin verirseniz (örneğin Subversion'da olduğu gibi), o zaman herkesin yalnızca biçimlendirilmiş kod işlemek için disipline sahip olduğundan emin olmanız gerekir (veya bazı kontroller yapıldıktan sonra sunucunun sadece taahhütleri kabul etmesi gerekir) ).

Genel olarak, bunun kötü bir fikir olduğunu düşünüyorum. Prensip olarak bu geçerli bir fikir, ancak gerçekte problemli olabilir. Kod biçimlendiricinin kodunuzu kırması gerçek bir olasılıktır ve geliştiricilerin (muhtemelen haklı) düşmanlıkla yanıt vermesi için yalnızca bir biçimlendirme çalışması gerekir (örn. "Kötü kod biçimlendiriciniz, derlemeyi kapattı, şimdi kapat ! " ).

@ BasileStarynkevitch'in önerisiyle aynı damarda, kod stili hakkında "danışma e-postaları" göndermek için git sunucu tarafı alma kancalarını kullanıyoruz.

Stil ihlalleri içeren bir taahhütte bulunursam, git origin sunucusu bana stil kurallarını ihlal ettiğimi bildiren ve kodumu düzeltmemi öneren bir e-posta gönderir . Bununla birlikte, bunu zorlamaz çünkü ev tarzını kırmak için geçerli nedenler olabilir (örneğin, çizgi uzunluğu sınırını aşan uzun dizeler).

Kod tabanına zarar veren sistemik bir sorunsa, kod incelemelerinde kod stili sorunlarını gündeme getirmenin zamanı gelmiş olabilir. Kötü kod stili, hataları gizleyebilir ve kodu okumayı zorlaştırabilir, bu nedenle geçerli bir kod inceleme sorunu olabilir.

Şeylerin “sosyal problemine” ek olarak, insanları bulduklarında kozmetik ve üslup kusurlarını düzeltmeye teşvik etmek faydalı olabilir. "Kozmetik" standart mesajımız var. Diğer geliştiricilerin bildiği kod stili düzeltmeleri, değişiklik yapmadığını içerir.

@DocBrown'un dediği gibi, başka bir seçenek IDE'nizde kod stilini uygulamaktır. Genel stil hatalarını düzeltmek için Visual Studio ile CodeMaid kullanıyoruz . Kod dosyalarının kaydedilmesi üzerine çalışacaktır, yani kötü stil kodunun asla depoya girmemesi gerekir ... teoride :-).

Evet, bence bu kötü bir fikir. Beni yanlış anlamayın, bunu yapmanın sebebi kulağa harika geliyor ama sonuç yine de korkunç olabilir.

İzlenen bir dal çekerken birleştirme çatışmalarına sahip olacaksınız, en azından bunun böyle olacağından korkuyorum, yine de yanlış olabilirim.

Şu anda işte test etmek istemiyorum ama kendin denemelisin.

Aslında, yakın tarihli bir taahhüdü kontrol edebilirsin. Yeni bir şube aç, küçük bir şey yap, kirazlı bir şeyler yap ya da autocommit ile birleştir.

Sonra betiğinizi çalıştırın, çekin ve sonucunuz korkunç bir birleştirme karışıklığıysa, o zaman kesinlikle bunu gün ışığında yapmamalısınız.

Bunun yerine, potansiyel olarak bir gece binasına veya haftalık bir yapıya yerleştirebilirsiniz.

Ancak bir gece bile kötü bir fikir olabilir.

Her hafta pazartesi bittiği için herhangi bir birleşme çatışması oluşmayacağından emin olduğunuzda haftalık olarak çalıştırabilirsiniz.

Aksi halde, birleşme çatışmalarının yaşanmayacağı tatil sezonunda yılda 1-2 kez çalıştırın.

Ancak çözüm, kod stili için önceliğinize bağlı olabilir.

Git deposunu otomatik olarak oluşturan ve projenin kancalarını ayarlayan bir kurulum betiği hazırlamanın daha iyi olacağını düşünüyorum.

Veya kanca kurulum komut dosyasını, proje içerisindeki aygıtlarınız için bir klasöre dahil edebilir ve onu git'e kontrol edebilirsiniz.

Bahsetmediğim bir şey, bazen bir şeyi bir dizi kurala göre biçimlendirmemek için meşru sebeplerin olduğu gerçeğidir. Bazen, kodun açıklığı, zamanın% 99'unun mantıklı olduğu belirli bir kılavuza aykırı olarak iyileştirilir. İnsanların bu çağrıyı yapması gerekir. Bu gibi durumlarda, otomatik kod biçimlendirme işleri daha az okunabilir hale getirir.

Bu korkunç bir fikir.

Geliştirici iş arkadaşlarımdan biri kaynak dosyalarında gereksiz değişiklikler yaptıysa, kod incelemesini geçemezdi. Sadece hayatı herkes için zorlaştırıyor. Değişmesi gereken kodu değiştirin, başka bir şey yok. Anlamsız değişiklikler, hatalara yol açabilecek birleştirme çatışmalarına ve sadece anlamsız çalışmalara yol açar.

Düzenli olarak bunu yapmak istiyorsanız, bu sadece korkunç.

Ve sonra kod formatlayıcının ne tür değişiklikler yaptığı sorusu var. Editörümde otomatik biçimlendirme kullanıyorum, oldukça iyi çalışıyor ve otomatik biçimlendirme mükemmel olmadığında işleri geliştirebilirim. Bunun ötesine geçen bir kod biçimlendirici kullanırsanız, kodu geliştirmeyeceksiniz, daha kötü hale getireceksiniz.

Ve sonra sosyal problem var. Herkesi kod stilini kullanmaya zorlamak isteyen insanlar var ve daha esnek insanlar var. Bunun gibi bir şey, tarzını başkalarına zorlamak isteyen "grammer-nazi" (imla kasıtlı) geliştiricisi tarafından önerilebilir. Bir boşluk bekleyin ve esnek, normalde kolay giden geliştiricilerin ayaklarını yere koymalarını bekleyin.

Kullandığınız VCS'den bahsetmiyorsunuz, ancak başka bir seçeneğe bağlı olarak sunucu tarafında bir kancaya sahip olmak. Git gibi bir VCS bunu destekliyor. Biçimlendirilen sürümdeki biçimlendiriciyi çalıştıran çift taraflı bir kanca takabilir ve ardından biçimlendirilmiş dosyayı ittirilen sürümle karşılaştırabilir. Eğer farklılarsa, geliştirici doğru formatı kullanmadı ve sunucu zorlamayı reddetti. Bu, dev'lerinizi yalnızca istenen biçimlendirme koduna basmaya zorlar, böylece baştan itibaren temiz kod yazmaya teşvik eder, doğru biçimlendirilmiş kodu test etmekten sorumludur ve dev'lerinizi istemci tarafı manuel olarak kurmak zorunda kalmaz kancası.

Daha temiz bir kod formatı ve git tarihini anlamak için daha kesin ve daha kolay olan bir takas. Projenizin doğasına ve ne olup bittiğini anlamak için git tarihine ne sıklıkta daldığınız veya suçladığınıza bağlı. Yeni bir şey üzerinde çalışıyorsanız ve geriye dönük uyumluluğu korumak zorunda değilseniz, tarih genellikle önemli bir rol oynamaz.

Bu fikir diğer bazı cevaplara benzer, ancak önerilerimi yorumlayamıyorum.

Seçeneklerden biri, taahhüt işlemine başlamadan önce kod biçimlendiricisini işlenecek kodda çalıştıran taahhüt işlevine bir takma ad (veya kanca veya herhangi bir şekilde) ayarlamaktır.

2 (veya daha fazla) sonuç verebilir:

1) Kullanıcıya önerilen değişiklikleri gösterin ve değişiklikleri uygulamak ve taahhüt etmek için onaylarını isteyin.

2) Önerilen değişiklikleri dikkate almayın ve orijinal kodu uygulayın.

Ayrıca, seçenek 1'de önerilen değişiklikleri düzenleme yeteneği gibi, bu seçeneklere daha fazla esneklik de ekleyebilirsiniz. Başka bir fikir (bu kodlama standartlarını ne kadar zorlamak istediğinize bağlı olarak) sistemin ne zaman bir tür rapor göndermesini sağlamaktır. seçenek 2 seçili.

Bu, geliştiricilerin gereksinimlerine uygun esneklik sağlamasına rağmen, istediğiniz gibi tüm kodları otomatik olarak denetlemenin iyi bir dengesi olabilir. Ayrıca, seçeneğin diğer cevaplarda belirtildiği gibi biçimlendirme farklılıklarıyla 'otomatik reddetme' seçeneğine de izin verir. 'Otomatik biçimlendirme düzeltmelerini gözden geçirip onayladım; taahhütte bulunma seçeneği, her geliştiricinin çalışması için kişisel sorumluluğu devam ettiriyor ve VCS ile uğraşmıyor.

Depoda yapmayacağım ama araç destekliyorsa tasarrufta yapacağım. Tutulma birdir ve buna ek olarak sıralama da dahil olmak üzere kod temizleme işlemini yapardım.

Güzel olan kısım, projenin bir parçası olması, böylece her geliştirici kendi projesi için alacaktır.

Ek bir avantaj olarak, bir şeyler etrafta zıplamayacağından, birleştirmeler önemli ölçüde basitleştirilecektir.

Kod incelemeleri hatalı olanları engelleyecektir.

Yapabileceğim başka bir yer de yapının bir parçası. Benim durumumda öyle ki, maven derlemeleri XML'i yeniden biçimlendirecek ve pom dosyalarını temizleyecek ve kodu yeniden biçimlendirecek.

Bu şekilde geliştiriciler itmeye hazır olduklarında, çekme istekleri için hepsi temizlenir.