İşlev başına en uygun kod satırı var mı? [kapalı]

18

İşlevler yalnızca kodun çoğaltılmasını en aza indirmek için değil, aynı zamanda okunabilirliği artırmak ve kodun kendi kendini yorumlamasını sağlamak için uzun bir işlevi daha küçük işlevlere bölmek için de kullanılır. Ancak bu kazanç, işlev veya yöntem başına LOC sayısıyla ters orantılı değildir; aksi takdirde hepsi tek bir satır veya iki kod içeren tonlarca fonksiyonumuz olur.

Bu beni meraklandırıyor: İşlev başına en uygun sayıda LOC var mı? Öyleyse, nedir ve diller arasında sapıyor mu?

functions

— gablin
kaynak

6

İyi bir zaman için Mitch McConnell Bölüm 7 Bölüm 4 tarafından Kod Tamamlama Cilt 2'ye bakınız.

— Peter Turner

2

@Peter - Sanırım "Steve McConnell" demek istediniz

— JohnFx

Evet, komik, kitaba bakarken yazardım .... Wasnt Mitch McConnell Pres. Bush'un genel müdürü mü?

— Peter Turner

3

Sayı neredeyse kesinlikle dile göre değişir: 20 satırlı Delphi yöntemiyle mükemmel bir şekilde tamamlanırken, 6 satırlı bir Prolog yan tümcesi görmekten şaşırırdım. Aşağıdaki cevabım kısa yöntemleri teşvik etmek için çevreyi kullanan Smalltalk için.

— Frank Shearar

1

@Peter Turner: Hm ... S1'den S15'e ve I1'den I11'e. Geçici değişkenleri kayıtlarla karıştırıyor gibi görünüyor. ^^

— gablin

33

Satır sayısı yerine, kullanacağım kriterler, her fonksiyonun sadece bir şey yapması ve iyi yapmasıdır.

— grokus
kaynak

Evet, eğer bir iş birimimiz varsa, olan biten şeyden yararlanmak için 50 işlev arasında hareket etmek istemiyorum. Bu metriği kullanarak işlevlerinizi uygun bir şekilde koparırsanız, bunların boyutu doğal olarak makul olmalıdır.

— ChaosPandion

2

@ChaosPandion: ancak çalışma biriminiz muhtemelen daha temel adımlar dizisi olarak ifade edilebilir. İşlevi inceliyorsanız, her bir adımın kodunu değil, adımların sırasını gözden geçireceksiniz.

— Wizard79

2

@Lorenzo - Bu durumda, her adım çalışma birimi haline gelir. Ebeveyn işlevi, çalışma birimlerinin üst düzey bir genel görünümü haline gelir.

— ChaosPandion

1

Evet, bu gerçekten çok doğru. Hm, şu soruyu yeniden ifade edeyim: İşlevler için tek bir şey yapan ve bunu iyi yapan optimal sayıda LOC var mı?

— gablin

@gablin, söylemesi zor ve LOC'lar dile bağlıdır, ancak bu ilkeye bağlı kalırsanız, genellikle makul bir aralıkta kalırsınız, örneğin 1 ~ 50.

— grokus

21

Eski bir başparmak kuralı, bir işlevin kaydırma gerekmeden ekranda tamamen görünür olması gerektiğidir.

Temel fikir, bir seferde tüm işleve bakamıyorsanız, işlevin karmaşık olduğu ve daha temel parçalara bölmeniz gerektiğidir.

Bu kural çok pratik ve kullanışlı olsa da, resmi kural, bir işlevde yalnızca tek bir mantıksal adım atmanız gerektiğidir. Bir işlev yalnızca temel bir iş yapar, işi daha temel parçalara bölebiliyorsanız, işlevin bölünmesi gerekir.

— Wizard79
kaynak

21

Bu ölçüm, ortalama monitör boyutu / çözünürlüğü arttıkça giderek daha işe yaramaz hale gelir.

— Adam Lear

2

Bizim programlama prof sadece geçen gece bu örnek söyledi :)

— cdnicoll

2

@Anna: Peki, monitörüm yüksek çözünürlük, ancak aynı zamanda araç çubuğu / palet / panel sayısı arttı. Ve sonra, şimdi 14 punto yazı tipini kullanabilirim! :)

— Wizard79

4

Bir terminalin 24 x 80 boyutu değişmez.

— alternatif

1

saçmalık, kuralın amacı "her şeyi kaydırmadan görebiliyor musunuz". Büyük bir monitörle, bu kuralı ihlal etmeden işlevinizde daha fazla şey olabilir, bu büyük monitörlerin sadece küçük işlevleri görüntülemesine izin verildiği anlamına gelmez (IDE'nizin sahip olduğu tüm araç çubukları ve özellik pencerelerinde bu muhtemelen hala geçerli: - ))

— gbjbaanb

15

Hiç yok.

Ekranlar büyüyor, yazı tipi boyutları küçülüyor. Başparmak kuralları, insanların farklı büyüklükteki başparmakları olduğunda iyi çalışmaz.

Kısa ve öz olun. Eğer fonksiyonunuz birden fazla şey yaparsa, muhtemelen daha küçük olanlara ayırmak iyi bir fikirdir.

— Josh K
kaynak

Yapabileceğiniz en az şey, cevabımın neden yararlı olmadığını düşündüğümü söylemek .

— Josh K

7

Sanırım birisi h1 etiketini kullanmanızdan rahatsız olmuştu .

— ChaosPandion

@Chaos: Temel cevap bu.

— Josh K

6

Belki biraz fazla inceydim ama niyetim cevabını aşağıya oylamak için geçerli bir neden olmadığını ima etmekti. Senaryoyu kim yaptıysa, bunun için rastgele kişisel bir nedeni vardı. Josh'un korkunç bir isim olduğunu düşünebilirler.

— ChaosPandion

6

Smalltalk, yöntemlerin boyutunu azaltmanın biraz sıra dışı bir yoluna sahiptir. Kod yazarken, Tarayıcı adı verilen bir widget'a yazarsınız. Tarayıcının yatay olarak bölünmüş iki ana bölümü vardır. Kodunuz alt yarıya çıkar.

Varsayılan olarak, bir Tarayıcı çok büyük değildir. Kaydırmaya başlamanız gerekmeden önce 5 veya 6 satırı sığdırabilirsiniz. Kaydırma, elbette, biraz tahriş edicidir.

Yani Smalltalk'te çevre sizi en fazla yaklaşık 6 satır uzunluğunda kısa yöntemler yazmaya “teşvik eder”. (Bu genellikle bol; Smalltalk oldukça kısa bir dildir.)

— Frank Shearar
kaynak

2

Bir yöntemdeki ideal kod satırı sayısı değişkendir. Temel olarak, yalnızca işlevin tanımı bağlamında yapılması gerekenleri yapmak için yeterli kod yazmak istersiniz. Bunu bir tür Tek Sorumluluk İlkesi olarak düşünüyorum , sadece sınıf yerine bir yönteme başvurdum.

Bir yöntemin çok fazla mantığı ve tamamlanması gereken birkaç adımı varsa, yöntemi birkaç ayrı adıma bölmek mantıklıdır. Bu adımların her biri gerektiği gibi yeni yöntemlere çıkarılacaktır.

"aksi takdirde hepsi tek bir satır veya iki kod içeren tonlarca fonksiyonumuz olurdu."

Her yöntem ne kadar azsa, o kadar kolay tanımlanır ve anlaşılması ve yönetilmesi daha kolaydır. İhtiyacınız olursa yüzlerce yönteme sahip olmanın yanlış bir yanı yoktur. Ayrıca doğrultusunda SRP Daha önce bahsettiğim, bu yöntemler daha küçük ve daha yönetilebilir parçalar halinde ayrı alay edildiğinde yeni sınıflar ayıklamak için daha kolay olur.

— S.Robins
kaynak

1

Cevap elbette 42 .

Nota Önemli: Hayır funcion ihlal hiç edebilir SRP veya yüzleşmek zorunda spanisch engizisyon .

Birkaç satır, hatların miktarının nasıl azaltılacağına dair ipuçları:

Bireysel bölümleri işaretleyen yorumlar var mı? Bu bölümler işlevler olmalıdır.
Fabrika / üreticinin dışında if-else zincirleri veya switch deyimleri var mı? Sorumluluklarınızı bölmenize yardımcı olması için tasarımınızın daha iyi tasarım modellerine ihtiyacı olabilir.
İşlevlerinizi test etmek kolay mı? Fonksiyonlarınızı test etmeyi kolaylaştırın, parçalanacaklar.
Karmaşık mı ve sadece bir toprak yok mu (1000 çizgi canavar)? Hurda yeniden düzenleme yapın - bu yeniden düzenleyicidir ve kodların sorumlulukları hakkında eğitim alma ümidiyle bunu kaydetmeyin.

— Johannes
kaynak

1

Nᴏʙᴏᴅʏ İspanyollý bekliyor ... ah bugger, buraya biraz geç kaldým.

— leftaroundabout

0

İşte bazı ipuçları:

Fonksiyonun amacını ve kullanımını açıklayan yorumu yazmakta sorun yaşıyorsanız, çok uzun.
İşlevdeki bir kod bölümünün etkinliğini açıklayan bir yorum yazmak isterseniz, işlev çok uzundur.
Kodu başka bir işlevden yapıştırıyorsanız, her ikisi de çok uzundur (bu kodu ayrı bir işlev olarak çıkarın).
Sınıf veri üyelerini yerel değişkenlerden ayırmak için bir kodlama kuralına ihtiyacınız varsa, işlev çok uzundur ve sınıfın çok fazla üyesi vardır.
Bir işlevi okurken not almanız gerekiyorsa, çok uzun.

Her biri sadece bir veya iki satır uzunluğunda olan 'ton' işlevlere sahip olmak, mutlaka kötü bir şey değildir. Bu küçük fonksiyonların başlangıçta beklediğimden çok daha fazla kullanıldığını gördüm.

— kevin cline
kaynak