Bir işlev ne zaman çok uzundur? [kapalı]

35 satır, 55 satır, 100 satır, 300 satır? Ne zaman parçalamaya başlamalısın? Soruyorum çünkü 60 satırlık bir fonksiyonum var (yorumlar dahil) ve onu parçalamayı düşünüyorum.

long_function(){ ... }

içine:

small_function_1(){...}
small_function_2(){...}
small_function_3(){...}

Fonksiyonlar, long_function dışında kullanılmayacaktır, daha küçük işlevler yapmak daha fazla işlev çağrısı vb. Anlamına gelir.

Bir işlevi ne zaman daha küçük parçalara ayırırsınız? Neden?

1. Yöntemler tek bir mantıklı şey yapmalıdır (işlevselliği düşünün)
2. Yöntemi tek bir cümleyle açıklayabilmelisin
3. Ekranınızın yüksekliğine sığmalıdır
4. Gereksiz ek yüklerden kaçının (bariz olana işaret eden yorumlar ...)
5. Küçük mantıksal işlevler için birim testi daha kolaydır
6. İşlevin bir kısmının diğer sınıflar veya yöntemler tarafından yeniden kullanılıp kullanılamayacağını kontrol edin
7. Sınıflar arası aşırı bağlamadan kaçının
8. Derinlemesine iç içe geçmiş denetim yapılarından kaçının

Cevaplar için herkese teşekkürler , listeyi düzenleyin ve doğru cevaba oy verin, onu seçeceğim;)

Şimdi bu fikirleri göz önünde bulundurarak yeniden düzenleme yapıyorum :)

Bunun için gerçekten zor ve hızlı kurallar yok. Genellikle yöntemlerimin sadece "tek bir şey yapmasını" severim. Yani, verileri kapıyor, sonra bu verilerle bir şeyler yapıyor ve sonra diske yazıyorsa, kapma ve yazma işlemlerini ayrı yöntemlere bölerim, böylece "ana" yöntemim sadece "bir şeyler yapma" yı içerir.

Yine de "bir şeyler yapmak" hala birkaç satır olabilir, bu yüzden birkaç satırın kullanılacak doğru ölçüm olduğundan emin değilim :)

Düzenleme: Bu, geçen hafta iş yerinde postaladığım tek satırlık bir koddur (bir noktayı kanıtlamak için .. bu alışkanlık yaptığım bir şey değil :)) - Yöntemimde bu kötü çocuklardan kesinlikle 50-60 tane istemem : D

return level4 != null ? GetResources().Where(r => (r.Level2 == (int)level2) && (r.Level3 == (int)level3) && (r.Level4 == (int)level4)).ToList() : level3 != null ? GetResources().Where(r => (r.Level2 == (int)level2) && (r.Level3 == (int)level3)).ToList() : level2 != null ? GetResources().Where(r => (r.Level2 == (int)level2)).ToList() : GetAllResourceList();

Aşağıda, bir işlevin çok uzun olduğunu gösterebilecek kırmızı bayrakların bir listesi (belirli bir sıra olmadan) verilmiştir:

1. Derinlemesine iç içe geçmiş kontrol yapıları : örneğin, karmaşık koşullara sahip iç içe geçmiş if ifadeleriyle 3 seviye derinliğinde veya sadece 2 seviye derininde for-loop'lar.

2. Çok fazla durum tanımlayıcı parametre : Durum tanımlayıcı parametre ile, işlev aracılığıyla belirli bir yürütme yolunu garanti eden bir işlev parametresini kastediyorum. Bu tür parametrelerden çok fazla aldığınızda, yürütme yollarının birleşimsel bir patlamasına sahip olursunuz (bu genellikle # 1 ile birlikte olur).

3. Diğer yöntemlerde yinelenen mantık : kötü kod yeniden kullanımı, monolitik prosedür koduna büyük bir katkıda bulunur. Bu tür mantık çoğaltmalarının çoğu çok ince olabilir, ancak yeniden faktörlendirildiğinde, sonuç çok daha zarif bir tasarım olabilir.

4. Sınıflar arası aşırı birleştirme : Bu uygun kapsülleme eksikliği, işlevlerin diğer sınıfların yakın özellikleriyle ilgilenmesine ve dolayısıyla onları uzatmasına neden olur.

5. Gereksiz ek yük : Açık, derinlemesine iç içe geçmiş sınıflara, özel iç içe geçmiş sınıf değişkenleri için gereksiz alıcılara ve ayarlayıcılara ve alışılmadık derecede uzun işlev / değişken adlarına işaret eden yorumların tümü, sonuçta uzunluklarını artıracak ilgili işlevler içinde sözdizimsel gürültü oluşturabilir.

6. Devasa geliştirici sınıfı ekranınız onu sergileyecek kadar büyük değil : Aslında, bugünün ekranları yeterince büyük ki, yüksekliğine yakın herhangi bir yerde bulunan bir işlev muhtemelen çok uzun. Ancak, daha büyükse , bu bir sorun olan bir tüten silahtır.

7. Hemen işlevin amacını belirleyemez : aslında kez Dahası, bunu tek bir cümleyle bu amaca özetlemek veya muazzam bir baş ağrısı var ne olamazsa, amacına belirlemek, bu bir ipucu olmalıdır.

Sonuç olarak, monolitik işlevlerin geniş kapsamlı sonuçları olabilir ve genellikle büyük tasarım eksikliklerinin bir belirtisidir. Okumak için mutlak bir zevk veren bir kodla karşılaştığımda , zarafeti hemen belli oluyor. Ve tahmin edin ne oldu: işlevler genellikle çok kısadır.

Bence bu sayfadaki "tek bir şey yap" mantrasına büyük bir uyarı var. Bazen tek bir şey yapmak birçok değişkeni karıştırır. Daha küçük işlevler uzun parametre listelerine sahipse, uzun bir işlevi daha küçük işlevlere bölmeyin. Bunu yapmak, yalnızca tek bir işlevi, gerçek bireysel değeri olmayan bir dizi yüksek düzeyde bağlı işleve dönüştürür.

Bir işlev yalnızca tek bir şey yapmalıdır. Bir işlevde çok sayıda küçük şey yapıyorsanız, her küçük şeyi bir işlev yapın ve bu işlevleri uzun işlevden çağırın.

Gerçekten yapmak istemediğiniz şey, uzun işlevinizin her 10 satırını kopyalayıp kısa işlevlere yapıştırmaktır (örneğinizin önerdiği gibi).

Bir işlevin yalnızca bir şeyi yapması gerektiğine katılıyorum, ancak bu hangi düzeyde bir şeydir?

60 satırınız bir şeyi başarıyorsa (programınızın perspektifinden) ve bu 60 satırı oluşturan parçalar başka hiçbir şey tarafından kullanılmayacaksa, 60 satır iyidir.

Kendi başına duran somut parçalara ayırmadığınız sürece, parçalamanın gerçek bir faydası yoktur. Kullanılacak metrik kod satırları değil işlevselliktir.

Yazarların tek bir şeyi aşırı bir düzeye çıkardığı ve sonunda yaptığı tek şey, birinin bir işleve / yönteme el bombası atmış ve onu düzinelerce bağlantısız parçaya havaya uçurmuş gibi görünmesini sağlamak olduğu birçok program üzerinde çalıştım. takip etmesi zor.

Bu işlevin parçalarını çıkarırken, herhangi bir gereksiz ek yük ekleyip eklemeyeceğinizi ve büyük miktarlarda veri iletmekten kaçınmayı da göz önünde bulundurmanız gerekir.

Bence kilit nokta, bu uzun işlevde yeniden kullanılabilirliği aramak ve bu parçaları çıkarmak. Elinizde kalan, 10, 20 veya 60 satır uzunluğunda olsun, işlevdir.

60 satır büyüktür ancak bir işlev için çok uzun değildir. Bir düzenleyicide bir ekrana sığarsa, hepsini aynı anda görebilirsiniz. Gerçekten işlevlerin ne yaptığına bağlı.

Neden bir işlevi parçalayabilirim:

• Bu çok uzun
• Kodu parçalayarak ve yeni işlev için anlamlı isimler kullanarak kodu daha sürdürülebilir hale getirir.
• İşlev uyumlu değil
• İşlevin bazı bölümleri kendi başlarına kullanışlıdır.
• İşlev için anlamlı bir ad bulmak zor olduğunda (Muhtemelen çok fazla yapıyor)

Kişisel buluşsal yöntemim, kaydırmadan her şeyi göremezsem çok uzun olmasıdır.

Size yaklaşık ekran boyutu (bu yüzden gidin büyük bir pivot geniş ekran alın ve çevirin) ... :-)

Şaka bir yana, işlev başına bir mantıksal şey.

Ve olumlu olan şey, birim testinin 1 şey yapan küçük mantıksal işlevlerle gerçekten çok daha kolay yapılmasıdır. Pek çok şey yapan büyük işlevlerin doğrulanması daha zordur!

/ Johan

Genel kural: Bir işlev, kodun geri kalanından biraz ayrılmış bir şey yapan kod blokları içeriyorsa, onu ayrı bir işleve koyun. Misal:

function build_address_list_for_zip($zip) {

    $query = "SELECT * FROM ADDRESS WHERE zip = $zip";
    $results = perform_query($query);
    $addresses = array();
    while ($address = fetch_query_result($results)) {
        $addresses[] = $address;
    }

    // now create a nice looking list of
    // addresses for the user
    return $html_content;
}

çok daha hoş:

function fetch_addresses_for_zip($zip) {
    $query = "SELECT * FROM ADDRESS WHERE zip = $zip";
    $results = perform_query($query);
    $addresses = array();
    while ($address = fetch_query_result($results)) {
        $addresses[] = $address;
    }
    return $addresses;
}

function build_address_list_for_zip($zip) {

    $addresses = fetch_addresses_for_zip($zip);

    // now create a nice looking list of
    // addresses for the user
    return $html_content;
}

Bu yaklaşımın iki avantajı vardır:

1. Belirli bir posta kodu için adresleri almanız gerektiğinde, hazır olan işlevi kullanabilirsiniz.

2. İşlevi build_address_list_for_zip()tekrar okumanız gerektiğinde, ilk kod bloğunun ne yapacağını bilirsiniz (belirli bir posta kodu için adresleri getirir, en azından işlev adından türetebileceğiniz şey budur). Sorgu kodunu satır içinde bırakacak olsaydınız, önce bu kodu analiz etmeniz gerekir.

[Öte yandan (bunu size işkence altında bile söylemiştim): PHP optimizasyonu hakkında çok şey okursanız, işlevlerin sayısını olabildiğince küçük tutma fikrini elde edebilirsiniz, çünkü işlev çağrısı çok, PHP'de çok pahalıdır. Hiçbir zaman kıyaslama yapmadığım için bunu bilmiyorum. Böyle bir durumda, uygulamanız çok "performansa duyarlı" ise, sorunuzun yanıtlarından hiçbirini takip etmemeniz daha iyi olur ;-)]

McCabe'nin siklomatiğine bir göz atın, burada kodunu bir grafiğe böldü, "Grafikteki her düğüm, programdaki akışın sıralı olduğu ve yayların programda alınan dallara karşılık geldiği bir kod bloğuna karşılık gelir. "

Şimdi kodunuzun hiçbir işlevi / yöntemi olmadığını hayal edin; grafik biçiminde sadece büyük bir kod yayılımı.

Bu yayılmayı yöntemlere bölmek istiyorsunuz. Bunu yaptığınızda, her yöntemde belirli sayıda blok olacağını düşünün. Her yöntemin yalnızca bir bloğu diğer tüm yöntemlere görünür olacaktır: ilk blok (bir yönteme yalnızca bir noktada atlayabileceğinizi varsayıyoruz: ilk blok). Her bir yöntemdeki diğer tüm bloklar, bu yöntem içinde gizlenmiş bilgiler olacaktır, ancak bir yöntem içindeki her blok, potansiyel olarak o yöntem içindeki başka herhangi bir bloğa atlayabilir.

Yöntemlerinizin yöntem başına blok sayısı açısından hangi boyutta olması gerektiğini belirlemek için kendinize sorabileceğiniz bir soru şudur: Tüm bloklar arasındaki maksimum potansiyel bağımlılık sayısını (MPE) en aza indirmek için kaç yönteme ihtiyacım var?

Bu cevap bir denklemle verilir. Eğer r, sistemin MPE'sini en aza indiren yöntemlerin sayısı ve n, sistemdeki blok sayısı ise, denklem: r = sqrt (n)

Ve bunun yöntem başına blok sayısını, ayrıca sqrt (n) olarak verdiği gösterilebilir.

Sadece yeniden faktörleme uğruna yeniden faktörlemeye başlayabileceğinizi ve bu da kodu ilk başta olduğundan daha okunamaz hale getirebileceğinizi unutmayın.

Eski bir meslektaşım, bir işlevin / yöntemin yalnızca 4 satır kod içermesi gerektiğine dair tuhaf bir kurala sahipti! Buna o kadar katı bir şekilde bağlı kalmaya çalıştı ki, yöntem isimleri çoğu kez tekrarlı ve anlamsız hale geldi, ayrıca çağrılar derinlemesine iç içe ve kafa karıştırıcı hale geldi.

Yani benim mantram şu hale geldi: eğer kod parçası için düzgün bir işlev / yöntem adı düşünemiyorsanız, yeniden faktörlendiriyorsunuz, zahmet etmeyin.

Genelde bir işlevi parçalamamın ana nedeni, ya parçalarının ya da parçalarının aynı zamanda yazdığım başka bir yakın işlevin bileşenleri olması, böylece ortak bölümlerin hesaba katılmasıdır. Ayrıca, başka bir sınıftan çok sayıda alan veya özellik kullanıyorsa, ilgili parçanın toptan kaldırılması ve mümkünse diğer sınıfa taşınması için iyi bir şans vardır.

En üstte bir açıklama olan bir kod bloğunuz varsa, bunu bir işlevin içine çekmeyi, işlev ve bağımsız değişken adlarının amacını göstermesini ve açıklamayı kodun mantığı için ayırmayı düşünün.

Orada başka yerlerde işe yarayacak hiçbir parça olmadığından emin misin? Bu ne tür bir işlevdir?

Bana göre cevap şu: çok fazla şey yaptığında. İşleviniz yalnızca işlevin adından beklediğiniz eylemleri gerçekleştirmelidir. Dikkate alınması gereken başka bir şey de, işlevlerinizin bazı bölümlerini diğerlerinde yeniden kullanmak isteyip istemediğinizdir; bu durumda onu bölmek faydalı olabilir.

Genellikle bir sonraki kod bloğunu açıklayan yorumlar koyma ihtiyacıyla işlevleri ayırırım. Daha önce yorumlara eklenenler şimdi yeni işlev adına giriyor. Bu zor bir kural değil, ama (benim için) güzel bir kural. Kendi adına kod konuşmayı yorum gerektiren birinden daha çok seviyorum (yorumların genellikle yalan söylediğini öğrendim)

Bu kısmen bir zevk meselesi, ancak bunu nasıl belirlediğim, işlevleri kabaca yalnızca bir seferde ekranıma sığacak kadar (en fazla) tutmaya çalışıyorum. Bunun nedeni, her şeyi aynı anda görebiliyorsan, neler olduğunu anlamanın daha kolay olmasıdır.

Kodladığımda, bu, uzun işlevler yazmanın, ardından diğer işlevler tarafından yeniden kullanılabilecek bitleri çıkarmak için yeniden düzenlemenin ve ilerledikçe ayrık görevler yapan küçük işlevlerin yazılmasının bir karışımı.

Bunun doğru ya da yanlış cevabı olduğunu bilmiyorum (örneğin, maks. Olarak 67 satıra karar verebilirsiniz, ancak birkaç tane daha eklemenin mantıklı olduğu zamanlar olabilir).

Bu konu hakkında kapsamlı araştırmalar yapılmıştır, en az hatayı istiyorsanız, kodunuz çok uzun olmamalıdır. Ama aynı zamanda çok kısa da olmamalı.

Ekranınıza bir yöntemin sığması gerektiği konusunda hemfikir değilim, ancak bir sayfadan daha fazla aşağı kaydırıyorsanız, o zaman yöntem çok uzundur.

Daha fazla tartışma için Nesne Yönelimli Yazılım için En Uygun Sınıf Boyutuna bakın .

Daha önce 500 satır işlevi yazmıştım, ancak bunlar yalnızca mesajların kodunu çözmek ve yanıtlamak için büyük anahtar ifadeleriydi. Tek bir iletinin kodu, tek bir eğer-öyleyse-yoksa daha karmaşık hale geldiğinde, onu çıkardım.

Özünde, fonksiyon 500 satır olmasına rağmen, bağımsız olarak muhafaza edilen bölgelerin ortalaması 5 satırdı.

Normalde kod yazmak için test odaklı bir yaklaşım kullanırım. Bu yaklaşımda, işlev boyutu genellikle testlerinizin ayrıntı düzeyi ile ilgilidir.

Testiniz yeterince odaklanmışsa, testi geçmek için küçük odaklı bir işlev yazmanıza yol açacaktır.

Bu aynı zamanda diğer yönde de çalışır. Etkili bir şekilde test etmek için işlevlerin yeterince küçük olması gerekir. Bu nedenle, eski kodla çalışırken, farklı bölümlerini test etmek için daha büyük işlevleri parçaladığımı sıklıkla görüyorum.

Genelde kendime "bu işlevin sorumluluğu nedir" diye soruyorum ve sorumluluğu net ve öz bir cümle içinde ifade edemiyorsam ve bunu küçük odaklı bir teste çeviremiyorsam, işlevin çok büyük olup olmadığını merak ediyorum.

Üçten fazla dalı varsa, bu genellikle dallanma mantığını farklı yöntemlerde kapsüllemek için bir işlevin veya yöntemin parçalanması gerektiği anlamına gelir.

Her for döngüsü, if ifadesi vb. Bu durumda çağırma yönteminde bir dal olarak görülmez.

Java kodu için Cobertura (ve eminim diğer diller için başka araçlar da vardır), her işlev için bir işlevdeki if, vb. Sayısını hesaplar ve "ortalama döngüsel karmaşıklık" için toplar.

Bir işlevin / yöntemin yalnızca üç dalı varsa, bu metrikte üç tane alacaktır ki bu çok iyidir.

Bazen, yani kullanıcı girdisini doğrulamak için bu yönergeye uymak zordur. Bununla birlikte, şubeleri farklı yöntemlere koymak, yalnızca geliştirme ve bakıma değil, aynı zamanda teste de yardımcı olur, çünkü dallanmayı gerçekleştiren yöntemlerin girdileri, bu dalları kapsamak için test senaryolarına hangi girdilerin eklenmesi gerektiğini görmek için kolayca analiz edilebilir. kaplı değildi.

Tüm dallar tek bir yöntemin içinde olsaydı, girdilerin yöntemin başlangıcından itibaren izlenmesi gerekirdi, bu da test edilebilirliği engeller.

Bu konuda pek çok cevap bulacağınızdan şüpheleniyorum.

Muhtemelen, işlev içinde gerçekleştirilen mantıksal görevlere dayanarak onu ayırırdım. Size kısa hikayeniz bir romana dönüşüyor gibi görünüyorsa, farklı adımlar bulmanızı ve çıkarmanızı öneririm.

Örneğin, bir tür dize girdisini işleyen ve bir dize sonucu döndüren bir işleviniz varsa, dizenizi parçalara ayırma mantığına, fazladan karakterler ekleme mantığına ve onu yerleştirme mantığına göre işlevi bölebilirsiniz. hepsi biçimlendirilmiş bir sonuç olarak yeniden bir arada.

Kısacası, kodunuzu temiz ve okunması kolay kılan ne olursa olsun (bu, yalnızca işlevinizin iyi bir yorum yapmasını sağlamak veya onu parçalamakla) en iyi yaklaşımdır.

Bir şeyi yaptığınızı varsayarak , uzunluk şunlara bağlı olacaktır:

• ne yapıyorsun
• hangi dili kullanıyorsun
• Kodda kaç tane soyutlama seviyesi ile uğraşmanız gerekiyor

60 satır çok uzun olabilir veya doğru olabilir. Yine de çok uzun olabileceğinden şüpheleniyorum.

Bir şey (ve bu şey işlev adından anlaşılır olmalıdır), ancak ne olursa olsun bir ekran dolusu koddan fazlası olamaz. Yazı tipi boyutunuzu artırmaktan çekinmeyin. Ve şüpheniz varsa, onu iki veya daha fazla işleve göre yeniden düzenleyin.

Bob Amca'dan bir tweet'in ruhunu bir süre önce uzattığımızda, iki kod satırı arasına boş bir satır koyma ihtiyacı duyduğunuzda bir işlevin çok uzadığını biliyorsunuz. Buradaki fikir, kodu ayırmak için boş bir satıra ihtiyacınız varsa, sorumluluğu ve kapsamı bu noktada ayrılıyor.

Benim fikrim, eğer çok uzun olup olmadığını kendime sormak zorunda kalırsam, muhtemelen çok uzun olacaktır. Bu alanda daha küçük işlevler yapmaya yardımcı olur, çünkü uygulamanın yaşam döngüsünün ilerleyen dönemlerinde yardımcı olabilir.