Sizin için bir yöntemin ideal uzunluğu nedir? [kapalı]

Nesneye yönelik programlamada elbette bir yöntemin maksimum uzunluğu konusunda kesin bir kural yoktur, ancak yine de bu iki alıntıyı birbiriyle çelişen buldum, bu yüzden ne düşündüğünüzü duymak istiyorum.

Gelen Temizlik Kodu: Çevik Yazılım El Sanatları isimli Elkitabı Robert Martin diyor ki:

Fonksiyonların ilk kuralı, küçük olmaları gerektiğidir. Fonksiyonların ikinci kuralı, bundan daha küçük olmalarıdır. İşlevler 100 satır uzunluğunda olmamalıdır. İşlevler 20 satır uzunluğunda olmamalıdır.

Kent Beck'ten gördüğü Java kodundan bir örnek veriyor:

Programındaki her fonksiyon sadece iki, üç veya dört satır uzunluğundaydı. Her biri şeffaf bir şekilde açıktı. Her biri bir hikaye anlattı. Ve her biri sizi bir sonraki sıraya götürdü. Fonksiyonların bu kadar kısa olmalı!

Kulağa çok hoş geliyor, ancak diğer taraftan, Code Complete'de Steve McConnell çok farklı bir şey söylüyor:

Rutin organik olarak 100-200 çizgiye kadar büyümesine izin verilmelidir, onlarca yıllık kanıtlar, bu tür rutinlerin daha fazla hataya meyilli olmadığını ve kısa rutinlerden kaynaklandığını söylüyor.

Ve 65 satır ya da daha uzun süren rutinlerin daha ucuz olduğunu söyleyen bir çalışmaya atıfta bulunuyor.

Öyleyse, konu hakkında farklı görüşler varken, sizin için işlevsel bir en iyi uygulama var mı?

İşlevler normalde kısa olmalıdır, 5-15 satır arasında, Java veya C # kodlama yaparken kişisel "kural kuralı" olur. Bu, birkaç nedenden dolayı iyi bir boyuttur:

• Kaydırmadan ekranınıza kolayca uyar
• Kafanızda tutabileceğiniz kavramsal boyut hakkında
• Bir işlevi kendi başına istemek için yeterince anlamlı (bağımsız, anlamlı bir mantık parçası olarak)
• 5 satırdan küçük bir işlev, belki de kodu çok fazla kırdığınızı gösterir (işlevler arasında gezinmeniz gerekirse okuma, anlama zorlaştırır). Ya öyle ya da sizin özel durumlarınızı / hata işlemlerinizi unutuyorsunuz!

Ancak, her zaman kuraldan ayrılmanın geçerli istisnaları / nedenleri olacağından, mutlak bir kural belirlemenin faydası olduğunu sanmıyorum:

• Bir tür döküm gerçekleştiren tek satırlık erişim işlevi bazı durumlarda açıkça kabul edilebilir.
• Açıkça 5 satırdan azına ihtiyaç duyan bazı çok kısa ama kullanışlı işlevler (örneğin, bilinmeyen kullanıcı tarafından bahsedildiği şekilde takas). Çok da önemli değil, birkaç 3 satır işlevi kod tabanınıza zarar vermez.
• Tek bir büyük anahtar ifadesi olan 100 satırlık bir işlev, ne yapıldığı açıkça belliyse kabul edilebilir. Bu kod, farklı durumları tanımlamak için çok fazla satır gerektirse bile kavramsal olarak çok basit olabilir. Bazen bunun ayrı sınıflara yeniden yansıtılması ve kalıtım / polimorfizm kullanılarak uygulanması önerilmektedir, ancak IMHO bu konuya çok fazla yaklaşıyor - 40 tane yeni sınıftan sadece 40 büyük sınıf anahtar ifadesiyle ilgilenmeyi tercih ederim. Onları oluşturmak için bir 40 yönlü anahtar deyimi.
• Karmaşık bir işlev, farklı işlevler arasında parametre olarak iletildiğinde çok karışık olacak birçok durum değişkenine sahip olabilir. Bu durumda, her şeyi tek bir büyük işlevde tutarsanız, kodun daha basit ve daha kolay olduğunu iddia edebilir (her ne kadar doğru bir şekilde işaret ediyor olsa da, bunun her iki mantığı da içine alacak bir sınıfa dönüşmek için aday olabilir) ve devlet).
• Bazen daha küçük veya daha büyük fonksiyonların performans avantajları olabilir (belki Frank'in bahsettiği gibi satır içi veya JIT sebeplerinden dolayı). Bu, yüksek oranda uygulamaya bağımlıdır, ancak bir fark yaratabilir - kıyaslama yaptığınızdan emin olun!

Bu yüzden, temel olarak, sağduyu kullanın , çoğu durumda küçük işlev boyutlarına sadık kalın, ancak alışılmadık derecede büyük bir işlev yapmak için gerçekten iyi bir nedeniniz varsa, bu konuda dogmatik olmayın.

Doğru LOC numarası ile ilgili katı bir kural olmadığını söylediklerinde, diğerlerinin yorumlarına katılıyorum, ancak geçmişte incelediğimiz projelere bakıp yukarıdaki her işlevi tanımladığımızda bahse girerim, 150 kod satırı diyelim. Tahmin ediyorum ki, bu fonksiyonların 10'undan 9'unun SRP'yi (ve ayrıca büyük olasılıkla OCP'yi) kırdığı, çok fazla yerel değişkene, çok fazla kontrol akışına sahip olduğu ve genellikle okunması ve bakımı zor olduğu konusunda fikir birliğine varacağımızı tahmin ediyorum.

Dolayısıyla, LOC hatalı kodun doğrudan bir göstergesi olmasa da, belirli bir işlevin daha iyi yazılmış olabileceği kesinlikle iyi bir dolaylı göstergedir.

Takımımda liderlik pozisyonuna düştüm ve her ne sebeple olursa olsun insanlar beni dinliyor gibi görünüyor. Genel olarak üzerinde durduğum şey, takıma mutlak bir sınır olmasa da, herhangi bir fonksiyonun 50 satırdan daha fazla kod satırının kod incelemesi sırasında en az bir kırmızı bayrak getirmesi gerektiğini, böylece ikinci bir bakalım ve tekrar değerlendirmemiz gerektiğini söylemek. karmaşıklık ve SRP / OCP ihlalleri için. İkinci bakıştan sonra, onu yalnız bırakabiliriz veya değiştirebiliriz, ama en azından insanların bu şeyler hakkında düşünmesini sağlar.

Kodlama ilkeleriyle hiç ilgilenmeyen bir projeye girdim. Kodun içine baktığımda, bazen 6000'den fazla kod satırı ve 10'dan daha az yöntem içeren sınıfları bulurum. Hataları düzeltmeniz gerektiğinde bu bir korku senaryosudur.

Bir yöntemin maksimumda ne kadar büyük olması gerektiğine dair genel bir kural bazen çok iyi değildir. Robert C. Martin (Bob Amca) tarafından verilen kuralı seviyorum: "Yöntemler küçük, küçükten küçük olmalı". Bu kuralı her zaman kullanmaya çalışıyorum. Yöntemimin sadece bir şeyi ve başka bir şey yapmadığını netleştirerek yöntemleri basit ve küçük tutmaya çalışıyorum.

Satır sayısı ile ilgili değil, SRP ile ilgili. Bu ilkeye göre, yönteminiz tek bir şey yapmalı.

Eğer yönteminiz bunu VE VE VE VE VEYA VEYA = = yaparsa muhtemelen çok şey yapıyordur. Bu yönteme bakmayı ve analiz etmeyi deneyin: "burada bu verileri alıyorum, sıralıyorum ve ihtiyaç duyduğum elemanları alıyorum" ve "burada bu elemanları işliyorum" ve "burada sonuç elde etmek için sonunda bunları birleştiriyorum". Bu "bloklar" diğer yöntemlere göre düzeltilmelidir.

Eğer sadece SRP’yi izlerseniz, yönteminizin çoğu küçük ve net bir şekilde olacaktır.

"Bu yöntem> 20 satırdır bu yüzden yanlış" demek doğru değildir. Olabilir bir göstergesi şey olduğunu olabilir artık, bu yöntemle yanlış.

Bir yöntemde 400 hat anahtarına sahip olabilirsiniz (genellikle telekomda gerçekleşir) ve bu yine de tek bir sorumluluktur ve tamamen uygundur.

Bu ciddiyetle, bu soruya kesin bir cevap verilememesine bağlıdır , çünkü çalıştığınız dil önemli, bu cevapta belirtilen beş ila onbeşinci satır C # veya Java için işe yarayabilir, ancak diğer dillerde çalışmak için çok fazla. Benzer şekilde, üzerinde çalıştığınız alana bağlı olarak, kod ayar değerlerini büyük bir veri yapısında yazarken kendinizi bulabilirsiniz. Bazı veri yapılarında, ayarlamanız gereken onlarca öğeye sahip olabilirsiniz, sadece fonksiyonunuz uzun sürdüğü için fonksiyonları ayırmak için işleri parçalara mı ayırmalısınız?

Diğerlerinin de belirttiği gibi, en iyi kural, bir işlevin tek bir görevi yerine getiren tek bir mantıksal varlık olması gerektiğidir. İşlevlerin n satırından daha uzun olamayacağını söyleyen ejderha kurallarını zorlamaya çalışırsanız ve bu değeri çok küçük yaparsanız, geliştiricilerin kuralı aşmak için fantezi püf noktaları kullanmaya çalışırken kodunuzu okumak zorlaşacaktır. Aynı şekilde, çok yüksek ayarlarsanız sorun olmaz ve tembellik olsa da kötü koda neden olabilir. En iyi seçeneğiniz, işlevlerin tek bir görevi yerine getirdiğinden emin olmak için kod incelemeleri yapmak ve bunu bu konuda bırakmaktır.

Bence burada bir problem, bir fonksiyonun uzunluğunun karmaşıklığı hakkında hiçbir şey söylemediğidir. LOC (Kod Satırı) herhangi bir şeyi ölçmek için kötü bir araçtır.

Bir yöntem aşırı karmaşık olmamalıdır, ancak uzun bir yöntemin kolayca korunabileceği senaryolar vardır. Aşağıdaki örneğin, yöntemlere bölünemeyeceğini, sadece yöntemlerin sürdürülebilirliği değiştirmeyeceğini söylemediğini unutmayın.

örneğin, gelen veriler için bir işleyicide büyük bir switch ifadesi ve daha sonra vaka başına basit kod bulunabilir. Böyle bir kodum var - bir yayından gelen verileri yönetiyor. 70 (!) Sayısal olarak kodlanmış işleyicileri. Şimdi, biri "sabitleri kullan" diyecek - evet, API bunları sağlamadığı sürece ve ben burada "kaynağa" yakın durmayı seviyorum. Yöntemler? Tabii ki - ne yazık ki hepsi aynı 2 dev yapıdaki verilerle ilgileniyor. Belki daha fazla yönteme (okunabilirlik) sahip olma dışında onları ayırmanın faydası yok. Kod kendinden karmaşık değildir - bir alana bağlı olarak bir anahtar. Sonra her durumun, x veri unsurlarını ayrıştırıp yayınlayan bir bloğu vardır. Bakım kabusu yok. "Bir alanın veri olup olmadığını belirleyen bir koşul varsa (pField = pFields [x], eğer pField-> IsSet () {blabla}) - her alan için hemen hemen aynı.

Bunu, iç içe geçmiş bir döngü ve çok sayıda gerçek anahtarlama ifadesi içeren çok daha küçük bir rutinle değiştirin ve dev bir yöntem, bir küçükten daha bakımı kolay olabilir.

Öyleyse, üzgünüm, LOC ile başlamak için iyi bir ölçüm değil. Bir şey varsa, karmaşıklık / karar noktaları kullanılmalıdır.

Sadece başka bir alıntı yapalım.

İnsanların okuması için programlar yazılmalı ve sadece makinelerin çalışması için bu arada

- Harold Abelson

Bu kuralı takip ederek 100-200’e büyüyen fonksiyonların kullanılması çok mümkün

1970'den beri bu çılgın raketten biri ya da başka biri oldum.

Tüm bu zamanlarda, bir an içinde anlayacağım iki istisna dışında, ASLA iyi tasarlanmış bir "yordam" görmedim (yöntem, prosedür, işlev, alt yordam, ne olursa olsun), birden fazla basılı sayfa olması GEREKLİ yaklaşık 60 satır) uzun. Büyük çoğunluğu 10-20 sıra sırasına göre biraz kısaydı.

Bununla birlikte, görünüşe göre modülerleşmeyi hiç duymamış kişiler tarafından yazılmış bir “bilinç akışı” kodu görmüştüm.

Bu iki istisna çok özel durumlardı. Bunlardan biri aslında bir araya topladığım bir istisna durumudur: büyük çirkin anahtar ifadeleri olarak uygulanan büyük sonlu durumlu otomatlar, çünkü genellikle bunları uygulamak için daha temiz bir yol yoktur. Bu şeyler genellikle otomatik test ekipmanlarında görülür ve test edilen cihazdan veri kayıtlarını ayrıştırır.

Diğeri ise, CDC 6600 FORTRAN IV'te yazılmış olan Matuszek-Reynolds-McGehearty-Cohen STARTRK oyunundaki foton torpido rutiniydi. Komut satırını ayrıştırmak, daha sonra her bir torpilin uçuşunu simüle etmek, pertürbasyonlarla, torpido ile vurabildiği her şey arasındaki etkileşimi kontrol etmek zorunda kaldı ve oh bu arada, zincirleri üzerinde 8-yollu bağlantı yapmak için tekrarlama simülasyonu yaptı. diğer yıldızların yanında olan bir yıldıza torpil atmaktan kaçındı.

Uzun bir yöntem bulursam - bu yöntemin düzgün bir şekilde test edilmediğini veya çoğu zaman hiç birim test yapmadığını iddia edebilirim. TDD yapmaya başlarsanız, asla 25 farklı sorumluluk ve 5 iç içe döngü içeren 100 satır yöntemi oluşturmazsınız. Testler sizi sürekli olarak kirliliğinizi yeniden yansıtmaya zorlar ve amcamın Bob temiz kodunu yazar.

Yöntemin uzunluğu hakkında kesin kural yoktur, ancak aşağıdaki kurallar yararlı olmuştur:

1. İşlevin birincil amacı, dönüş değerini bulmaktır. Varlığının başka bir nedeni yok. Bu sebep dolduktan sonra, başka bir kod eklenmemelidir. Bu mutlaka işlevleri küçük tutar. Diğer işlevleri çağırmak, yalnızca dönüş değerini bulmayı kolaylaştırırsa yapılmalıdır.
2. Öte yandan, arayüzler küçük olmalıdır. Bunun anlamı, ya çok sayıda sınıfa sahip olmanız ya da büyük işlevlere sahip olmanızdır - önemli bir şey yapacak kadar kodunuz olduğunda, ikisinden biri gerçekleşecektir. Büyük programlar her ikisine de sahip olabilir.

Yazarlar "işlev" ve "rutin" ile aynı şeyi mi ifade ediyor? Genelde "işlev" derken, değeri döndürmeyen bir alt yordam / işlem anlamına gelir ve bunu yapmayan (ve tek bir ifadeye dönüşen) "yordam" anlamına gelir. Bu gerçek dünyada SE boyunca yaygın bir ayrım değildir, ancak kullanıcı metinlerinde gördüm.

Her iki durumda da, buna doğru bir cevap yok. Biri veya diğeri için tercih (eğer bir tercih varsa), diller, projeler ve organizasyonlar arasında çok farklı olmasını beklediğim bir şeydir; tıpkı tüm kod kurallarında olduğu gibi.

Ekleyeceğim tek şey, "uzun işlemlerin kısa işlemlerden daha fazla hataya meyilli olmadığı" iddiasının kesinlikle doğru olmamasıdır. Daha fazla kodun daha fazla potansiyel hata alanına eşit olması gerçeğine ek olarak, kodların bölümlere ayrılmasının hataları hem kaçınılması hem de bulunmasının daha kolay hale getireceği açıktır. Aksi halde, kodu parçalara ayırmak için hiçbir neden olmaz, tekrarı saklarsınız. Ancak bu, yalnızca söz konusu bölümlerin gerçek kodu okumadan veya izlemeden bir işlem çağrısının sonuçlarını belirleyebilecek kadar iyi bir şekilde belgelenmesi durumunda (kod alanları arasındaki somut bağımlılıktan ziyade şartnamelere göre tasarlanan) doğru olabilir.

Ek olarak, daha uzun işlemlerin iyi sonuç vermesini istiyorsanız, onları desteklemek için daha katı kod kuralları kabul etmek isteyebilirsiniz. Bir işlemin ortasında bir iade ifadesinin atılması, kısa bir işlem için iyi olabilir, ancak daha uzun işlemlerde bu, koşullu olan ancak hızlı bir okuma için açıkça koşulsuz olmayan büyük bir kod bölümü oluşturabilir (yalnızca bir örnek için).

Bu yüzden, hangi tarzın böcekle dolu bir kabus olma ihtimalinin daha düşük olduğunu, kodunuzun geri kalanında hangi sözleşmelere uyduğunuza bağlı olduğunu düşünüyorum. :)

IMHO, işlevinizi okumak için kaydırma çubuğunu kullanmak zorunda değilsiniz. Kaydırma çubuğunu hareket ettirmeniz gerektiğinde, işlevin nasıl çalıştığını anlamak biraz zaman alır.

Buna göre, takım çalışmanızın genel programlama ortamına bağlıdır (ekran çözünürlüğü, editör, yazı tipi boyutu vb.). 80'lerde, 25 satır ve 80 sütundu. Şimdi editörümde yaklaşık 50 satır gösteriyorum. Ekranımı ikiye böldüğümden, zaman zaman iki dosyayı görüntülemek için görüntülediğim sütun sayısı değişmedi.

Kısacası, iş arkadaşlarınızın kurulumuna bağlıdır.

TomTom'un cevabını düşünüyorum ben bu konuda nasıl hissettiğini yakın geldi.

Gittikçe daha fazla şey kendimi çizgilerden ziyade döngüsel karmaşıklığa devam ediyor.

Ben normalde, yöntemde birden fazla kontrol yapısını hedeflemiyorum, ancak çok boyutlu bir diziyi işlemek için gereken birçok döngü dışında.

Bazen kendimi şalter davalarına tek satırlık koyarken buluyorum çünkü bazı nedenlerden dolayı bunlar yardım etmekten ziyade engelleri ayıran durumlar olma eğilimindedir.

Bu sınıra karşı koruma mantığı saymadığımı unutmayın.

OOP'ta her şey nesneye itilir ve bu özellikler vardır:

1. Polimorfizm
2. Soyutlama
3. miras

Bu kurallara uyduğunuzda yöntemleriniz genellikle küçüktür ancak küçük veya çok küçük (örneğin 2-3 satır) kurallar için herhangi bir kural yoktur. Küçük yöntemin bir faydası (küçük birim, örneğin yöntem veya işlev):

1. daha iyi okunabilir
2. daha iyi tutmak
3. sabit hata daha iyi
4. daha iyi değişir