Zorunlu Kod Reformatının Avantaj ve Dezavantajları

Şu anda geliştiriciler sürüm denetimi check-in otomatik kod biçimlendirici kullanmaya zorlayan bir yerde çalışıyorum. Geliştiricilerin bunu yapmanın avantajları ve dezavantajları hakkında görüşlerini arıyorum ... geliştiricilere nasıl yardımcı olacağını veya engelleyeceğini düşünüyorsunuz. Özel durumum Java / JSP'leri içeriyor, ancak bence soru herhangi bir dile uygulanabilir.

Bence bunu yapmak çok önemli. İşte nedeni:

• Kaynak denetim farklarınızın sadece gerçek kod değişikliklerini göstermesini sağlar ve boşluk ve diğer önemsiz biçimlendirme seçenekleri nedeniyle "fark gürültüsünü" ortadan kaldırır
• Tüm kodları daha benzer hale getirir, böylece geliştiriciler kod tabanlarını eşleştirmek ve paylaşmak daha rahat olur

Bunu yaparsanız, herkesin tüm kodu kontrol etmesini öneririm, o zaman bir kişi tüm kod tabanı üzerinde bir yeniden biçimlendirme yapar, ardından biçimlendirmek için ayarlanmış bir "dev" değişiklik (herkesin görmezden gelebileceği) vardır, ancak bundan sonra, tüm diffs gerçek kod diffs.

Bunu yavaş yavaş yaparsanız, gerçek kod değişikliklerini biçimlendirme değişiklikleriyle karıştırırsınız ve değişiklikler değişim alanında gereksiz yere dağınık olur.

Buraya kendi cevabımı atacağım çünkü insanlar sadece avantajlar ekliyor gibi görünüyor. Dezavantaj olarak gördüğüm:

• Otomatik biçimlendiriciden 'daha iyi' yapma yeteneğini ortadan kaldırır ... daha temiz biçimlendirmenizi geri alır. Bunun bir örneği sütun tabanlı parametre bildirimleri, nesnelerin ayrık eklemelerinin listeleri, vb. Olabilir.
• Artık büyük yanıltıcı fark değişiklikleri oluşturacağından, değişen stil kurallarına karşı bir direnç yaratıyor.
• Alternatif bir biçimin kodu daha okunabilir hale getireceği herhangi bir 'özel durum' biçimlendirmesi yapma yeteneğini kaldırır.
• Tam olarak ihtiyacınız olan yeniden biçimlendirme özelliklerini destekleyen IDE'leri kullanmaya bağlanır . Başka bir IDE'de ihtiyacınız olan seçeneklerden biri eksikse, en azından bazı sorunlara neden olacaktır.
• Grubunuzla tam olarak aynı biçim kurallarını kullanmadıkça, yazılabilir bir kod deposunun harici bir grupla paylaşılması sorunlu hale gelir (Genellikle her zaman değil, genellikle olacaktır).
• Her zaman biraz farklı bir formatın öngörülen stillerden daha temiz olduğu istisnalar olacaktır. Böylece otomatik dönüştürme, belirli bir kod bloğunun amacını gizleyebilir ve bu da koda bir hata eklemek kadar iyidir.

Basitçe ifade etmek gerekirse, otomatik olmayan bir dizi kural, otomatik kuralların bir minimum ve bir maksimum belirlediği minimum stil / okunabilirlik gereksinimlerini belirler.

VB (belki de sürüm 5) bakarak hatırlıyorum ve bu konuda en sinir bozucu şeylerden birini bulmak zorla benim kodu yeniden biçimlendirmek ve temel biçimlendirme yukarıda ve ötesi şey kaldırmak oldu.

Zorla kod biçimlendirmesinin harika olduğunu düşünüyorum. Bir geliştiricinin, gözleri her yerde zıplamadan tüm kod topluluğunu geçmesine izin verir. Ayrıca bu standardın yerine getirilmesi, acemi geliştiricilerin kötü alışkanlıkları kırmasına yardımcı olur.

Birincil dezavantaj, gerçekten önemli olan özel biçimlendirmeyi kaybetmektir.

Belirli koşullardan biri mevcut ancak yerine getirilmezse başarısız olacak tipik bir akıl sağlığı kontrolü düşünün ...

  if(
      (user.id == TEST_ID)
    ||(
         (user.id == UserID)
       &&( 
             ( user.type == HUMAN_USER && user.name.size() >= MIN_NAME )
           ||( user.type == EMULATION && input.source != SOURCE_INTERNAL ))
       && ( user.email == NULL || emailValidator.isValid(user.email))
       && ( (user.phone == NULL) == (user.type == EMULATION) )

       // several more lines like this.)
    ){ /* handle results */ }

Bu, koşulların mantıksal yapısını izleyen makul girinti sayesinde okunabilir.

Artık otomatik aracınızın farklı koşulların ilgili hatlara mantıksal olarak ayrılması hakkında hiçbir fikri yok. Her bir çizginin 3-4 koşulu bir satırda toplayıp bir sonraki koşulu ikiye bölmesinin bir nedeni yoktur. Ya da her satıra bir karşılaştırma ifadesi olarak böler. Ekranda daha güzel görünebilir, ancak mantık kaybolacaktır.

Dezavantajları olan bir cevap ekledim ve büyük bir avantaj olarak gördüğüm şeyi de atacağım.

Taahhütte otomatik kod yeniden biçimlendirmesi kullandığınızda, tercihlerinizin başkalarına dayatılmasının olağan etkisi olmadan kişisel tercih varyasyonları olasılığını açar. IDE biçim kodunuzu işleme sırasında ortak bir standarda sahip olabilir, ancak başkalarını etkilemeden tercih ettiğiniz biçimde size gösterebilirsiniz.

Bu benim için neredeyse kutsal konvansiyonel kodlama Kutsal Kâse ... ortak bir kod formatının avantajlarını elde edersiniz, ancak yine de kişisel tercihlerin çatışmalar olmadan desteklenmesine izin verirsiniz.

İhtiyaçlarınıza bağlıdır, ancak bazı çelişkiler oldukça yararlıdır, örneğin her if () 'i kıvırcık ayraçlar takip etmelidir, çünkü yeniden düzenleme yapıyorsanız böyle bir yanlışlık elde etmek oldukça kolaydır.

Bu durumu düşünün:

if( x == 0 ) 
   return foo;
//do something else
return bar;

Şimdi if vakasına biraz günlük eklemek istiyorsanız, yanlışlıkla yazabilirsiniz:

if( x == 0 ) 
  log.info("x was 0");
  return foo;
//do something else
return bar;

Ve aniden yönteminiz her zaman geri döner foo.

Düzenleme: Bu otomatik biçimlendirme değil, stil kontrolünde. Bu yanıtı konu dışı da özür dilerim. :)

Şirketteki kodun üniform hale getirilmesine büyük ölçüde yardımcı olur ve bu sayede ürününüz için genellikle daha kolay anlaşılabilir ve daha kolay korunabilen bir yapı üretersiniz.

Eh, avantajları gördüğüm tek olası dezavantajları bir insan gözünün olmaması vb kod standardizasyon, geliştiriciler arasında semantik gibi, herhangi bir kod biçimlendiricisinde aynıdır sonra bazı istisnalar vb eklemek, biçimlendirme
Bu yüzden bir check-in zaman biçimlendiricisi yerine bir IDE biçimlendiriciyi düşünün.

Deneyimlerime göre, bu iyi bir şey. Biri olmadan, kod karşılaştırmaları genellikle boşluk biçimlendirmesi karışıklığını gösterir ve gerçek kod değişikliklerini gizleyebilir. Deneyimlerime göre, birisinin biçimlendirmesiyle uğraşmak, özellikle ekip genelinde tutarlılığın potansiyel faydaları ile ortaya çıktığı günah değildir.