Hangi noktada / aralıkta bir kod dosyası çok büyük?

Çok sayıda 2-3k satırı dosyası buluyorum ve bu kadar büyük olması gerektiği gibi bir his yok.

Kaynak kod dosyasını nesnel olarak "çok büyük" olarak adlandırmak için iyi bir ölçüt nedir?

İdeal bir model olarak aşağıdaki kriterleri kullanıyorum (Martin Beckett'in önerdiğine benzer bir gerekçeyle, yani mantıksal yapı ve kod satırları açısından düşünmek için):

Kural 1

Dosya başına bir sınıf (C ++: bir sınıf -> bir başlık ve bir uygulama dosyası).

Kural 2

Yedi, beynimizin aynı anda gözlemleyebileceği, kafanın karışmadan gözlemleyebileceği maddelerin sayısı olarak kabul edilir. 7'nin üstünde gördüklerimize genel bir bakış atmakta zorlanıyoruz. Bu nedenle: Her sınıf 7-10'dan fazla yönteme sahip olmamalıdır. 10'dan fazla yönteme sahip bir sınıf muhtemelen çok karmaşık ve onu ayırmaya çalışmalısınız. Bölünmek çok etkili bir yöntemdir, çünkü bir sınıfı böldüğünüzde, her bir sınıfın karmaşıklığını en az 2 kat azaltırsınız.

Kural 3

Bir veya iki ekrana sığmayan bir yöntem gövdesi çok büyük (bir ekran / editör penceresinin yaklaşık 50 satır olduğunu varsayıyorum). İdeal olarak, tüm yöntemi tek bir pencerede görebilirsiniz. Durum böyle değilse, gizlenen yöntemin bir bölümünü unutmadan, sadece biraz yukarı ve aşağı kaydırmanız gerekir. Bu nedenle, tüm yöntem gövdesini okumak için birden fazla ekranı yukarı ya da aşağı kaydırmanız gerekirse, yönteminiz muhtemelen çok büyüktür ve genel bakışı kolayca kaybedebilirsiniz.

Yine, özel yardım yöntemlerini kullanarak yöntemleri bölmek, yöntem karmaşıklığını çok hızlı bir şekilde azaltabilir (her bölmede karmaşıklık en azından yarıya iner). Çok fazla özel yardım yöntemi tanıtırsanız, bunları toplamak için ayrı bir sınıf oluşturmayı düşünebilirsiniz (halka açık olanlardan daha fazla özel yönteminiz varsa, belki de ikinci bir sınıf ana sınıfınızın içinde saklanıyordur).

Bu çok kaba tahminleri bir araya getirmek:

• Kaynak dosya başına en fazla bir sınıf.
• Sınıf başına en fazla 10 kamu yöntemi.
• Sınıf başına en fazla 10 özel yöntem.
• Yöntem başına en fazla 100 satır.

Bu yüzden 2000'den fazla satırdan oluşan bir kaynak dosya muhtemelen çok büyük ve çok dağınık olmaya başlıyor.

Bu gerçekten çok zor bir tahmin ve bu kriterleri sistematik olarak takip etmiyorum (özellikle uygun yeniden yapılandırma yapmak için her zaman yeterli zaman olmadığı için). Ayrıca, Martin Beckett'in önerdiği gibi, bir sınıfın geniş bir metodlar topluluğu olduğu durumlar vardır ve sadece sınıfı daha küçük hale getirmek için onları yapay bir şekilde bölmenin bir anlamı yoktur.

Her neyse, benim deneyimlerime göre, yukarıdaki parametrelerden birine uyulmadığında bir dosya okunamaya başlar (örn. Altı ekranı kapsayan bir 300 satır yöntemi gövdesi veya 5000 satır kod içeren bir kaynak dosyası).

Hayır - kod satırlarında değil. Sürücü mantıksal gruplama yapmalıdır. Örneğin büyük bir dosyada birden fazla sınıf olmamalıdır.

Birkaç yüz yöntemle meşru bir şekilde (3B modelleme demek imkansız değil) bir sınıfınız olsaydı, bunu keyfi dosyalara bölmek daha az kolay olurdu. Hafızanın azalması ve işlemcilerin yavaşlaması ile bunu yapmak zorundaydık - ve sürekli olarak işlev tanımını arayan bir acıydı.

İçindeki kod erişilemez hale geldiğinde. yani: sadece aradığınız yöntem / sınıf / işlev (ve düzenlemek / hata ayıklamak zorunda) veya orada olup olmadığını ve eğer öyleyse nerede olduğunu söyleyerek kodu izleyerek söyleyemezsiniz.

IDE / Editör seçiminiz ve özellikleriniz, bu üst sınırın gerçek miktarını etkileyecektir. Kod katlama , fonksiyon / metot listeleme ve arama edecek ertelemek anı bu gelişme senaryosu hediyeler.

Ama olduğu zaman, onu bölme zamanı.

Alternatif bir görünüm: Dosya boyutunu nasıl sınırlayacağınızı soruyorsunuz. Bence büyük kod dosyalarını çok problemli kılan birçok faktör var. Bazen kod dosyası çok büyük ancak içeriği de kümelenmiş ve son derece temiz bir koddur, böylece boyut önemli bir soruna neden olmaz. Yüksek LOC'a rağmen okunabilen çok sayıda dosya gördüm.

LOC metrikine girmek yerine, bu büyük dosyalarda kodun ne sıklıkla bozulduğunu anlamak için geçmiş verilerini kullanmayı düşünürdüm. Genelde bunun nedeni, geliştiricilerin aynı dosyadaki ilgili diğer yerleri kontrol etmek ve yeterli bir anlayış olmadan "hızlı düzeltme" zihniyetiyle değişiklik yapmak için sabırsız olmalarıdır.

En büyük tehlike kopyala-yapıştır kodunun varlığıdır. Kopyala-yapıştır kodlaması doğal olarak LOC büyümesini de hızlandırır. Kopya yapıştırmayı ortadan kaldırmak, LOC'yi sihirli sayının altında tutmaktan daha da önemsiz olduğunu düşünüyorum. Saf kopyalamanın yanı sıra büyük dosyalarda ikinci bir tehlike daha var: Örtüşen işlevsellik. Dosya büyüdükçe, zaten aynı dosyanın başka bir bölümünde bulunan bir snippet'i yeniden uygulamalısınız.

Böylelikle, daha büyük dosyalar için hata düzeltme oranı (hata düzeltme işleminin tüm taahhütleri yerine getirme oranı) düşük olduğu sürece , durum tolere edilebilir. Lütfen git logbunu deneyin ve taahhütlerin kaç tanesinin hatalarla ilgili olduğunu gözden geçirin. Veya otomatik olarak analiz edip görselleştirebilecek bir araç kullanın, örneğin Softagram .

Bunu düşün Metaphor. Kod uzunluğu söz konusu olduğunda, aşağıdakileri göz önünde bulundurmamız gerektiğini düşünüyorum:

The Cat in The Hat (50 pp.)

ve

Lord of The Rings (1,178 pp.)

Yanlış bir şey yok Lord of the Rings. Muhteşem bir kitap. The Cat in the HatAynı zamanda harika bir kitap. Her ikisi de 5 yaşındakiler tarafından anlaşılabilir, ancak yalnızca biri içerik nedeniyle daha uygundur.

Benim açımdan kod yazabildiğimiz zaman 5 yaşına gelmemiz gerekir. Cyclomatic Complexitygeliştiricilerin kod oluştururken göz önünde bulundurmaları gereken önemli bir kavramdır. İşlevselliği geliştirmek ve mümkün olduğu kadar tekrar kullanılabilirliği kodlamak için kitaplıkları kullanmak ve oluşturmak. Bu şekilde kodumuz, yazdıklarımızdan daha fazla ses konuşabilir.

Çoğumuz derleme kodu yazmıyoruz . Ancak kodumuzun kökü montajdır. 10000 hat derlemesini aramak, doğru yapıldığında 10000 hat python'dan daha zordur.

Ancak bazı işler 500 ila 1000 satır yazmayı gerektirir. Kodlu hedefimiz 300 satırlık temiz kod yazmak olmalıdır.

Geliştiriciler olarak "Yüzüklerin Efendisi" yazmak istiyoruz. Bir hata alıp, "Şapkalı Kedi" yazmayı dileyelim. Kodlamayı bir ego ölçüsü yapmayın. Sadece işleri basit bir şekilde çalıştırın.

Geliştiriciler kodu belgelemek istemiyor, (kişisel olarak belgelenmiş kodu seviyorum, o kadar bencil değilim). Bu yüzden sadece anlayabileceğiniz / okuyabileceğiniz bir kod yazmayın. Cat in the HatKod yaz

Hepimiz senin JRR Tolken olduğunu biliyoruz (kafanda). Unutmayın ki hatasız kod ile kanıtlayacak bir şeyiniz yok.

Metafor için başka bir sebep.

Okuyucunun serveti yaymasını fazla önemsemeyin. Bir grup insanla çalışıyorsanız ve hepsinin aynı büyük dosyayı değiştirmesi gerekiyorsa, muhtemelen kendinizi gitbirleştirme cehenneme sokacaksınız.

Herkes yeniden doğmayı sever.

-> Hiç kimse dedi!

TL; DR Okunabilirliğe odaklanın. Kodunuzu yayınlayın ve yardımcı olarak mümkün olduğunca çok sayıda satır ve dosya üzerine taşıyın. 8 veya 9 sınıfı tek bir dosyaya atmayın, kodun okunmasını zorlaştırır ve bakımını zorlaştırır. Büyük bir durum kodunuz veya döngünüz varsa, dil destekliyorsa bunları Lambdas olarak değiştirmeyi düşünün. Yardımcı programlar, kod okunabilirliğini artırmak için harika bir yol olarak düşünülmelidir. Ağır iç içe geçmekten kaçının.