Yeniden biçimlendirme ve sürüm kontrolü

Kod biçimlendirme önemlidir. Girinti bile önemlidir . Tutarlılık küçük iyileştirmelerden daha önemlidir. Ancak, projeler genellikle 1. günden itibaren açık, eksiksiz, doğrulanabilir ve uygulamalı bir stil kılavuzuna sahip değildir ve önemli gelişmeler her gün gelebilir. Belki onu bulursun

SELECT id, name, address
FROM persons JOIN addresses ON persons.id = addresses.person_id;

daha iyi yazılmış olabilir

SELECT persons.id,
       persons.name,
       addresses.address
  FROM persons
  JOIN addresses ON persons.id = addresses.person_id;

sorguya daha fazla sütun eklemeye çalışırken. Belki de bu, kodunuzdaki dört sorgunun en karmaşık olanı veya binlerce arasında önemsiz bir sorgu. Geçiş ne kadar zor olursa olsun, buna değer olduğuna siz karar verin. Ancak , büyük biçimlendirme değişikliklerinde kod değişikliklerini nasıl izlersiniz? Sadece pes edip "tekrar başladığımız nokta budur" diyebilir ya da tüm depo tarihindeki tüm sorguları yeniden biçimlendirebilirsiniz.

Git gibi dağıtılmış bir sürüm kontrol sistemi kullanıyorsanız, şimdiye kadarki ilk taahhüdünüze geri dönebilir ve oradan o anki duruma dönüştürebilirsiniz. Fakat bu çok fazla iş ve devam ederken herkesin işi duraklatması (ya da her birleşmenin anası için hazır olması) gerekir. Tüm sonuçları en iyi şekilde veren geçmişi değiştirmenin daha iyi bir yolu var mı :

• Tüm taahhütlerde aynı stil
• Minimum birleştirme işi

?

Açıklığa kavuşturmak için bu, projeye başlarken en iyi uygulamalarla ilgili değil, daha çok büyük bir yeniden düzenlemenin Good Thing ™ olarak kabul edilmesine rağmen ne yapılması gerektiğine rağmen ne yapılmalı? Sürümlerinizin her zaman aynı şekilde çalışmasını sağlamak için tek yol buysa, geçmişi asla yeniden yazmak mükemmel değildir, peki ya temiz bir yeniden yazmanın geliştirici faydaları ne olacak? Özellikle, yeniden yazılan sürümün tam olarak aynı şekilde çalışmasını sağlamak için yöntemleriniz (testler, sözdizimi tanımları veya derlemeden sonra aynı bir ikili dosya) varsa?

Yeniden biçimlendirmeyi ayrı taahhütler halinde yapın. Bu, tarihe en az düzeyde müdahale edecektir ve bir bakışta hangi taahhütlerin sadece yeniden biçimlendiğini ve hangilerinin gerçekten kodu değiştirdiğini görebilmelisiniz. Eğrilebilir git blameve benzer olabilir , ancak yalnızca reformat bir taahhüdüne işaret ederse, bundan önceki önceki değişikliği beklemek oldukça açıktır.

VCS tarihini yeniden yazmayın: bu VCS ilkelerine aykırıdır.

Biçimlendirmeyi düzeltmeyi otomatikleştirmeyi denemeyin: gerçek sorunu değil, (= kodlama standartlarına uymayan geliştiriciler) belirtileri tedavi eder.

Kodlama standardını tanımlayın ve ortak bir belgede en iyi uygulamaları biçimlendirin ve tüm geliştiricilerin aynı fikirde olmasını sağlayın.

Git'ten bahsediyorsunuz, ki bu harika, çünkü dağıtılmış. Bir DVCS ile kapı bekçisi iş akışı aracılığıyla en iyi uygulamaları zorlamak çok kolaydır . Toplayıcılar , ortak kurallara uymayan birleştirme tekliflerini reddetti (= Git'teki istekleri geri çek). Ayrıca , koyu harflerle, reddetmek istemem , aksi halde ihlaldeki kodlayıcı kurallara uymaya ve aynı hataları tekrarlamaya zahmet etmeyecektir.

Bu teknik benim için iyi çalışıyor. Kodlayıcılar çalışmalarının birleştirilmesini istiyor, bu yüzden başlangıçtaki birkaç hatadan sonra kuralları izlemeye başlıyorlar.

Mevcut kod tabanını sabitlemeye göre ... Bunu aşamalı olarak, belki de modüle göre modüle veya projeniz için mantıklı kılmanızı öneririm. Her adımda dikkatlice test edin. Aptalca gelebilir, ancak sadece biçimlendirme gibi önemsiz değişikliklerde bile hatalar olur, bu nedenle yoldaki bazı küçük darbelere hazırlıklı olun.

Asıl sorunuzun cevabı "Yapmazsınız" dır. Mantıktaki değişiklikleri bir şekilde biçimlendirilmiş koddan, büyük bir biçimlendirme değişikliğinden ve kodun yeni biçimde biçimlendirilmesinden sonraki değişikliklerden izleyebilecek hiçbir güncel SCM aracı olmadığını biliyorum. Ve bunu biliyorsunuz, bir kod parçasında geçmişi kaybetmek iyi değil.

Buna göre, ilk cümlenizle biraz çelişeceğim. Kod biçimlendirme o kadar önemli değil . Güzel, güzel, ama bunun için burada değiliz. İki uzay girintiler ile birisinin eski cehennemi garip K & F varyantı kodu içine terk edildiğini olduğunu herkes kadar iyi anlıyorum biçimlendirme aslında oluyor 's şey olmadıkça ne anlama için bir engel değildir ... (1) berbat, ama son derece patolojik. Ve bu durumda, yine de kodu değiştirmekte zorlanacaksınız ve onu rahatsız etmemelisiniz.

Bu nedenle, yeniden biçimlendirmek için KURULAN kodda değişiklik yapmak için değmez. Değişken isimlerini değiştirmek, uzun işlevleri parçalamak, içeriği değiştiren tüm bu iyi refactoring maddeleri, evet, ancak SADECE yeniden biçimlendirmeyi değil.

1) - Bir süredir Windows Pano Görüntüleyicisine sahip oldum. Her şey bir, 150k, C modülü idi. Farklı insanların kullandığı bir yer buldum, sanırım birbirlerinin otuz çizgisinde beş farklı ayraç stili. Fakat işlerin bu kısmı ÇALIŞTI. On yıl boyunca bu kod öbeğinin bir çıktısını taşıdım, ama bunu dürtmedim, çünkü tarih önemliydi ve bu kod, tümü yaşayan en az üç kaynak ağacındaydı (Windows 3.x, NT, gelecek 95). farklı binalarda.

Ancak, büyük biçimlendirme değişikliklerinde kod değişikliklerini nasıl izlersiniz?

Biçimlendirme değişiklikleri olan kod değişiklikleri; onlara, kodunuzda herhangi bir değişiklik yapacak gibi davranın. Önemli bir proje üzerinde çalışmış olan herkes muhtemelen bazı kodları yeniden düzenlemeye karar verdiğinde ortaya çıkan hataları ve diğer sorunları görmüş olacaktır.

Fakat bu çok fazla iş ve devam ederken herkesin işi duraklatması (ya da her birleşmenin anası için hazır olması) gerekir.

Neden her şeyi aynı anda yeniden biçimlendirmek zorundasınız? Özellikle yeniden biçimlendirme kodun anlamını değiştirmezse, dosyaları ayrı ayrı yeniden biçimlendirebilir ve ilerledikçe bunları kontrol edebilirsiniz. Daha iyisi, ekibinizdeki herkesin bir stil üzerinde hemfikir olmalarını isteyin (aksi halde yine de yeniden biçimlendirmenin bir anlamı yoktur) ve hepsinin diğer çalışmaları sırasında yeniden biçimlendirmeye özen göstermelerini sağlayın. Bir süre sonra, kodun çoğunu projenin geri kalanını bozacak şekilde ele almış olacaksınız.

Bunun için gördüğüm uygulanabilir iki yaklaşım var.

1. Kanca üzerinde reform kodu

Başlangıçta, gönderdikten sonra kodu değiştirmek saç dökülmesine rağmen, yeniden biçimlendirme prosedürünüz (örneğin astyle ) kodu zarar vermezse, güvenli bir işlemdir. Zamanla, tüm takım sonunda tüm kodların aynı göründüğünü takdir edecektir. Açıkçası, kapsamlı birim / otomatik testlere sahip olmak hiçbir şeyin bozulmamasını sağlayacaktır.

2. Tüm kodların bir defalık yeniden biçimlendirilmesi

Bu benim deneyimimde daha tehlikelidir ve büyük patlamada izleme sorunlarını zorlaştırır, ancak mümkündür. Tüm testleri daha sonra yapmak çok önemlidir. Kodlama stili için, farklılıkların çoğu boşlukların - girinti veya yeni satırların kullanımı etrafında döner. İyi bir birleştirme aracına tüm boşluk farklarını göz ardı etmemesi söylenmelidir, bu nedenle bu birleşmelerde yardımcı olacaktır.