Soru İyi uygulama sınıfı satır sayısı [kapalı]


Bu sorunun doğru bir cevabı olmadığını biliyorum, sadece fikirlerinizi soruyorum.

Binlerce kod içeren HUGE sınıf dosyaları oluşturmanın iyi bir uygulama olmadığını biliyorum, çünkü bu programın korunması zor ve genellikle program mantığınızı gözden geçirmeniz gerektiği anlamına geliyor.

Sizce, bir sınıf için ortalama bir satır sayısı, Java'da diyelim ki (dil seçiminin bununla ilgili bir şey yapıp yapmadığını bilmiyorum, ama sadece ...)


16
2017-07-06 13:04


Menşei


İyi uygulama, oturma-on-saat-saat sayısı ??? - Abdulsattar Mohammed
İlgili soru: stackoverflow.com/questions/2222831/when-is-a-class-too-long - sleske


Cevaplar:


Evet, dil ile ilgisi olduğunu söyleyebilirim, çünkü sadece bazı diller diğerlerinden daha ayrıntılıdır.

Genel olarak, şu temel kuralları kullanırım:

  • <300 satır: iyi
  • 300 - 500 satır: makul
  • 500 - 1000 satır: belki tamam, ama refactoring planlayın
  • > 1000 satır: kesinlikle refactor

Tabii ki, gerçekten kodun niteliğine ve karmaşıklığına daha çok LOC'den daha fazla bağlıdır, ama bunları makul buldum.


28
2017-07-06 13:09





Genel olarak, hatların sayısı sorun değildir - biraz daha iyi bir metrik, kamu yöntemlerinin sayısıdır. Fakat doğru bir şekil yok. Örneğin, bir yardımcı dize sınıfı yüzlerce yöntemi doğru bir şekilde kullanabilirken, bir iş düzeyi sınıfının yalnızca bir çifti olabilir.

LOC, siklizik ve diğer karmaşıklık ölçümleriyle ilgileniyorsanız, Kaynak İzleyiciden http://www.campwoodsw.comücretsiz, Java & C ++ gibi büyük dillerle çalışır ve hepsi harikadır.


16
2017-07-06 13:10



Ayrıca tavsiye ederim sonar.codehaus.org hem satır sayısı hem de karmaşıklık için. - Mercer Traieste


Eric Raymond'un "Unix Programlama Sanatı" dan

Teorik olmayan terimlerle, Hatton'un ampirik sonuçları, olası kusur yoğunluğunu en aza indirgeyen 200 ve 400 mantıksal kod satırları arasında, diğer tüm faktörler (programcı becerisi gibi) eşittir. Bu boyut, kullanılan dilden bağımsızdır - bu kitapta yer alan en güçlü dil ve araçlarla programlamak için verilen tavsiyeleri kuvvetlendiren bir gözlem. Ancak bu sayıları tam anlamıyla almayı unutmayın. Kod satırlarının sayılmasına yönelik yöntemler, analistin mantıksal bir çizgiyi ne düşündüğüne ve diğer önyargılara (yorumların çıkarılıp çıkarılmadığına) göre önemli ölçüde farklılık gösterir. Hatton'un kendisi, mantıksal ve fiziksel çizgiler arasında 2x'lik bir dönüşüm kuralı olarak, 400-800 fiziksel hattın optimal bir menzilini önerdiğini öne sürüyor.

Dan alınan İşte


9
2017-07-06 13:12





Gibi bir şey ölçmek daha iyi cyclomatic karmaşıklık ve bunu bir ölçü olarak kullanın. Hatta yapı betiğinize / ant dosyasına / etc'ye yapıştırabilirsiniz.

Standartlaştırılmış kod formatıyla bile, kod satırlarının sınıfın gerçek karmaşıklığından kopması çok kolaydır.

Düzenleme: Gör bu soru Cyclomatic karmaşıklık araçlarının bir listesi için.


8
2017-07-06 13:24



Bu cevabı sevdim. Hızlı bir google arama ile bunu Java'da ölçen bir araç buldum. PMD denir pmd.sourceforge.net - Savvas Dalkitsis
İlginç bir araç; Onu görmemiştim. İdeal olarak IDE'imle entegre olacaktı ama ... ah, iyi. - Alex Feinman
bir komut satırı sözdizimine sahip olduğundan, bir sarıcı oluşturmanın bu kadar zor olmadığından eminim. - Savvas Dalkitsis
Cyclomatic karmaşıklığı karmaşıklığı ölçmek için resmi bir yoldur ve aynı zamanda kullanımı gerçekten kolaydır. Bu cevabı sevdim. - Abel Morelos


Yöntemlere odaklanıyorum ve onları 20 satır kodun altında tutmaya çalışıyorum. Sınıf uzunluğu genel olarak tek sorumluluk ilkesi tarafından belirlenir. Ama bunun mutlak bir ölçü olmadığına inanıyorum çünkü bu, soyutlama seviyesine bağlı, dolayısıyla 300 ila 500 satır arasında bir yerde yeni bir sorumluluk ya da çıkarma için bir soyutlama için kodun üzerinden bakmaya başladım.


5
2017-07-06 13:11





Sadece şarj edildiği görevi yapacak kadar küçük.

Sadece şarj edildiği görevi yapacak kadar büyük.

Ne fazla ne az.


4
2017-07-06 13:16





Tecrübemde 1000'den fazla metin satırı olan herhangi bir kaynak dosyada ayrılmaya başlayacağım. İdeal olarak, yöntemler mümkünse tek bir ekrana sığmalıdır.

Son zamanlarda, yardımcı olmayan yorumları kaldırmanın bununla büyük ölçüde yardımcı olabileceğini fark ettim. Yorum yapıyorum uzak 20 yıl önce programlamaya ilk başladığım zamandan çok daha idareli.


2
2017-07-06 13:56





Kısa cevap: 250'den az satır.

Kısa cevap: Mu.

Daha uzun cevap: Kod okunabilir ve özlü mü? Sınıfın tek sorumluluğu var mı? Kod kendini tekrarlıyor mu?


1
2017-07-06 13:26





Benim için sorun, LOC değil. Baktığım şey birkaç faktör. İlk olarak, If-Else-If ifadelerini kontrol ediyorum. Eğer birçoğu aynı şartlara sahipse veya benzer kodlar çalıştırılıyorsa, bunu yeniden düzenlemeyi denerim. Sonra yöntemleri ve değişkenlerime bakıyorum. Herhangi bir sınıfta, bu sınıfın bir birincil işlevi ve yalnızca bu işlevi olmalıdır. Farklı bir alan için değişkenleri ve yöntemleri varsa, bunları kendi sınıflarına koymayı düşünün. Her iki durumda da, LOC'yi iki nedenden dolayı saymaktan kaçının:

1) Kötü bir metrik. LOC'u sayarsanız, sadece uzun satırları değil, aynı zamanda boşlukları olan ve aynı oldukları gibi yorumlar için kullanılan satırları sayıyorsunuz demektir. Bunu önleyebilirsiniz, ancak aynı zamanda, hala küçük çizgiler ve uzun çizgiler eşit olarak sayıyorsunuz.

2) Yanıltıcıdır. Okunabilirlik tamamen LOC'nin bir işlevi değildir. Bir sınıf mükemmel bir şekilde okunabilir, ancak ihlal ettiği bir LOC sayınız varsa, kendinizi olabildiğince fazla çizgi çekmek için sıkı bir şekilde çalışacaksınız. Hatta kodu okunabilir hale getirebilirsiniz. LOC'yi değişkenler atamak ve bunları bir yöntem çağrısında kullanmak isterseniz, bu değişkenlerin ödevlerini doğrudan yöntem çağrısında aramaktan daha okunabilir. 1 satır okunamayan kod içine yoğunlaştırmak için 5 satır okunabilir kodun olması daha iyidir.

Bunun yerine, kod derinliğine ve çizgi uzunluğuna bakacağım. Bunlar daha iyi metriklerdir çünkü size iki şey söylerler. İlk olarak, iç içe derinlik, eğer mantığın yeniden yapılandırılması gerekiyorsa size söyler. Eğer bakarsanız, 2'den fazla derinlemesine ifadeler veya döngüler varsa, refactoring'i ciddi olarak düşünün. Birden fazla yuvalama düzeyiniz varsa, yeniden değerlendirme yapmayı düşünün. İkincisi, bir çizgi uzunsa, genellikle çok okunamaz. Bu satırı birkaç okunabilir hatta ayırmayı deneyin. Bu, sahip olduğunuz LOC sınırınızı bozabilir, ancak okunabilirliği artırır.


1
2017-07-06 14:10