Çoğunlukla, bu kişisel bir tercih, ancak dikkate alınması gereken bazı şeyler var.
Muhtemel Hatalar
O eklenti için parantez unutmadan kaynaklanan hata Ben kadarıyla, nadir iddia edilebilse de görülen bu onlar do gerçekleşmesi bazen (ünlü unutmamak IOS git başarısız hata). Bu yüzden kod stilinizi düşünürken bunun bir faktör olması gerektiğini düşünüyorum (bazı araçlar yanıltıcı girintiler konusunda uyarır , bu yüzden takım zincirinize de bağlıdır) .
Geçerli Kod ( bir hata olabilir gibi okur )
Hatta Projenizi varsayarak bu tür hatalar muzdarip değil kod okurken, onlar gibi görünmek kod bazı bloklarını görebilirsiniz olabilir zihinsel döngüleri bazı alarak ancak değildir - böcekler.
İle başlayalım:
if (foo)
bar();
Bir geliştirici yararlı bir yorum ekler.
if (foo)
// At this point we know foo is valid.
bar();
Daha sonra bir geliştirici üzerinde genişler.
if (foo)
// At this point we know foo is valid.
// This never fails but is too slow even for debug, so keep disabled.
// assert(is_valid(foo));
bar();
Veya iç içe geçmiş bir blok ekler:
if (foo)
while (i--) {
bar(i);
baz(i);
}
Veya bir makro kullanır:
if (foo)
SOME_MACRO();
“... Makrolar birden çok kod satırı tanımlayabildiğinden, makro do {...} while (0)birden çok satır için kullanıyor mu?
Yukarıdaki örneklerin tümü geçerli koddur, ancak kod bloğundaki içerik ne kadar fazla olursa, hata olmadığından emin olmak için o kadar fazla okumanız gerekir.
Belki kod stiliniz çok satırlı blokların bir ayraç gerektirdiğini tanımlar (ne olursa olsun, kod olmasalar bile) , ancak bu tür yorumların üretim koduna eklendiğini gördüm. Bunu okuduğunuzda, bu satırları en son kim düzenlediyse bir ayraç eklemeyi unuttuğuna dair küçük bir şüphe var, bazen kontrol edilme gereğinin (özellikle kodun bu alanındaki bir hatayı araştırırken) beklendiği gibi çalıştığını düşünüyorum .
Diff Gürültü
Tekli çizgiler için diş teli kullanmanın pratik bir nedeni, farklı sesleri azaltmaktır .
Değişen:
if (foo)
bar();
Kime:
if (foo) {
bar();
baz();
}
... koşullu çizginin değişmiş olarak bir fark olarak görünmesine neden olur, bu da bazı küçük fakat gereksiz ek yükler ekler.
- Satırlar kod incelemelerinde değiştiğini gösterir, eğer farklı araçlarınız kelime tabanına sahipse, yalnızca küme ayracının değiştiğini kolayca görebilirsiniz, ancak satırın hiç değişip değişmediğini kontrol etmek daha uzun sürer.
Tüm araçlar kelime temelli farklılaşmayı desteklemiyor, diff (svn, git, hg ... etc) tüm satır değişmiş gibi gösterilecektir, süslü araçlarda bile, bazen düz bir çizgiye hızlıca bakmanız gerekebilir. neyin değiştiğini görmek için temelli fark.
- ek açıklama araçları (örneğin
git blame), satırın değiştirildiğini göstererek, satırın orijinini izlemeyi gerçek değişikliği bulmak için daha fazla adım haline getirir .
Bu ikisi de küçüktür ve kod gözden geçirme veya izlemede ne kadar zaman harcadığınıza ve değiştirilen kod satırlarına bağlı kalmanıza bağlıdır.
Farkında fazladan satır değişikliklerinin olması daha somut bir rahatsızlıktır; kodda değişiklik yapma ihtimalinin yüksek olması, birleşme ve el ile çözülmesi gereken çatışmalara neden olur .
Bunun bir istisnası var {, kendi satırında olan kod tabanları için - bu bir sorun değil.
Diff gürültü bu tarzda yazarsanız argüman tutmaz:
if (foo)
{
bar();
baz();
}
Ancak bu, bu kadar yaygın bir kongre değildir; bu nedenle, esas olarak bütünlüğüne cevabın eklenmesi (projelerin bu stili kullanması gerektiğini önermeyen) .
