Kaç parametre çok fazla? [kapalı]

Rutinlerin parametreleri olabilir, bu haber değildir. İhtiyacınız olabilecek kadar çok parametre tanımlayabilirsiniz, ancak bunların birçoğu rutininizin anlaşılmasını ve bakımını zorlaştıracaktır.

Elbette, yapılandırılmış bir değişkeni geçici bir çözüm olarak kullanabilirsiniz: tüm bu değişkenleri tek bir yapıya koymak ve rutine aktarmak. Aslında, parametre listelerini basitleştirmek için yapıları kullanmak Steve McConnell tarafından Code Complete'te açıklanan tekniklerden biridir . Ama dediği gibi:

Dikkatli programcılar, verileri mantıksal olarak gerekenden daha fazla paketlemekten kaçınırlar.

Bu nedenle, rutininizde çok fazla parametre varsa veya büyük bir parametre listesini gizlemek için bir yapı kullanıyorsanız, muhtemelen yanlış bir şey yapıyorsunuzdur. Yani, bağlantıyı gevşek tutmuyorsunuz.

Sorum şu: Bir parametre listesini ne zaman çok büyük olarak değerlendirebilirim? 5'ten fazla parametrenin çok fazla olduğunu düşünüyorum. Ne düşünüyorsun?

Serbest konuşma için 1. Değişiklik garantisine rağmen düzenlenebilecek bir şey ne kadar müstehcen olarak kabul edilir? Justice Potter Stewart'a göre, "Onu gördüğümde biliyorum." Burada da aynı şey geçerli.

Bunun gibi sert ve hızlı kurallar yapmaktan nefret ediyorum, çünkü cevap sadece projenizin boyutuna ve kapsamına bağlı olarak değişmiyor, aynı zamanda modül seviyesine bile değiştiğini düşünüyorum. Yönteminizin ne yaptığına veya sınıfın neyi temsil etmesi gerektiğine bağlı olarak, 2 argümanın çok fazla olması ve çok fazla eşleşmenin bir belirtisi olması mümkündür.

Soruyu ilk etapta sorarak ve sorunuzu sizin kadar niteleyerek, tüm bunları gerçekten bildiğinizi öneririm. Buradaki en iyi çözüm, sert ve hızlı bir sayıya güvenmemek değil, bunun yerine düşük uyum ve sıkı bağlantıya sahip olduğunuz alanları belirlemek için akranlarınız arasında tasarım incelemelerine ve kod incelemelerine bakmaktır.

İş arkadaşlarınıza çalışmalarınızı göstermekten asla korkmayın. Eğer korkuyorsanız, bu muhtemelen kodunuzla ilgili bir şeylerin yanlış olduğunu ve zaten bildiğinizi gösteren en büyük işarettir .

Bir işlevin yalnızca parametrelerin bazıları yedekli olması durumunda çok fazla parametresi olabilir. Tüm parametreler kullanılıyorsa, işlev doğru sayıda parametreye sahip olmalıdır. Bu sık kullanılan işlevi al:

HWND CreateWindowEx
(
  DWORD dwExStyle,
  LPCTSTR lpClassName,
  LPCTSTR lpWindowName,
  DWORD dwStyle,
  int x,
  int y,
  int nWidth,
  int nHeight,
  HWND hWndParent,
  HMENU hMenu,
  HINSTANCE hInstance,
  LPVOID lpParam
);

Bu 12 parametredir (x, y, w ve h'yi dikdörtgen olarak paketlerseniz 9) ve ayrıca sınıf adından türetilmiş parametreler de vardır. Bunu nasıl azaltabilirsiniz? Sayıyı daha da azaltmak ister misiniz?

Parametre sayısının sizi rahatsız etmesine izin vermeyin, sadece mantıklı ve iyi belgelendiğinden emin olun ve intellisense ^* size yardımcı olsun.

^* Diğer kodlama yardımcıları da mevcuttur!

Gelen Temiz Kanunu , Robert C. Martin konuya dört sayfa ayırdı. İşte öz:

Bir işlev için ideal argüman sayısı sıfırdır (niladik). Sonra bir (monadik) gelir, ardından iki (ikili) gelir. Mümkün olan yerlerde üç argümandan (triadik) kaçınılmalıdır. Üçten fazla (poliamik) çok özel bir gerekçe gerektirir - ve sonra yine de kullanılmamalıdır.

Geçmişte birlikte çalıştığım bazı kodlar, çok fazla parametre iletmekten kaçınmak için küresel değişkenler kullandılar.

Lütfen bunu yapma!

(Genelde.)

İmzadaki parametreleri zihinsel olarak saymaya ve bunları çağrı ile eşleştirmeye başlarsanız, o zaman refactor zamanı!

Tüm cevaplarınız için çok teşekkür ederim:

• Aynı zamanda (benim yaptığım gibi) 5 parametrenin kodun akıl sağlığı için iyi bir sınır olduğunu düşünen insanları bulmak biraz şaşırtıcıydı.

• Genellikle, insanlar 3 ve 4 arasındaki bir sınırın iyi bir kural olduğu konusunda hemfikirdir. İnsanlar genellikle 4'ten fazla şeyi saymakta zorlandıkları için bu mantıklı.

• As Milan noktaları , ortalama insanlar üzerinde bir anda kendi kafasından aşağı yukarı 7 şeyleri tutabilir. Ancak, bir rutini tasarlarken / sürdürürken / çalışırken, parametrelerden daha fazla şeyi aklınızda tutmanız gerektiğini unutamayacağınızı düşünüyorum.

• Bazı insanlar bir rutinin ihtiyaç duyduğu kadar argümana sahip olması gerektiğini düşünür. Kabul ediyorum, ancak sadece birkaç özel durum için (OS API'lerine çağrılar, optimizasyonun önemli olduğu rutinler vb.). Mümkün olduğunca bu çağrıların hemen üstüne bir soyutlama katmanı ekleyerek bu rutinlerin karmaşıklığını gizlemenizi öneririm.

• Nick'in bu konuda bazı ilginç düşünceleri var. Yorumlarını okumak istemiyorsanız, sizin için özetleyeceğim: kısaca, bağlıdır :

  Bunun gibi sert ve hızlı kurallar yapmaktan nefret ediyorum, çünkü cevap sadece projenizin boyutuna ve kapsamına bağlı olarak değişmiyor, aynı zamanda modül seviyesine bile değiştiğini düşünüyorum. Yönteminizin ne yaptığına veya sınıfın neyi temsil etmesi gerektiğine bağlı olarak, 2 argümanın çok fazla olması ve çok fazla eşleşmenin bir belirtisi olması mümkündür.

  Buradaki ahlaki, kodunuzu akranlarınıza göstermekten korkmayın, onlarla tartışın ve "düşük uyum ve sıkı bağlantınızın olduğu alanları belirlemeye çalışın " .

• Son olarak, wnoise'ın Nick'le çok hemfikir olduğunu ve programlama sanatının bu şiirsel vizyonuyla (aşağıdaki yorumlara bakınız) hiciv katkısını sonuçlandırdığını düşünüyorum :

  Programlama mühendislik değildir. Kodun organizasyonu bir sanattır, çünkü herhangi bir zor kural için bağlama çok fazla bağlı olan insan faktörlerine bağlıdır.

Bu cevap bir OO dili varsayar. Birini kullanmıyorsanız - bu cevabı atlayın (bu, başka bir deyişle, dile özgü agnostik bir cevap değildir).

3 veya daha fazla parametre (özellikle de içsel tipler / nesneler) geçiyorsanız, bu "Çok fazla" değildir, ancak yeni bir nesne oluşturma şansınızı kaçırıyor olabilirsiniz.

Birden fazla yönteme geçirilen parametre gruplarına bakın - iki yönteme geçirilen bir grup bile, orada yeni bir nesneye sahip olmanız gerektiğini garanti eder.

Daha sonra işlevselliği yeni nesnenize yeniden yansıtırsınız ve hem kodunuza hem de OO programlama anlayışınıza ne kadar yardımcı olduğuna inanmazsınız.

Görünüşe göre, sadece sayıdan başka başka düşünceler de var, akla gelen bazı şeyler:

1. bir kerelik ayarlara karşı işlevin birincil amacı ile mantıksal ilişki

2. Eğer sadece çevre bayrakları ise, demetleme çok kullanışlı olabilir

Alan Perlis'in iyi bilinen programlama epigramlarından biri (ACM SIGPLAN Notices 17 (9), Eylül 1982'de sayılmıştır), "10 parametreli bir prosedürünüz varsa, muhtemelen bazılarını kaçırmışsınızdır" ifadesini kullanır.

Code Complete'teki Steve McConnell'e göre ,

Rutinin parametre sayısını yaklaşık yedi ile sınırlayın

Benim için, liste IDE'mdeki bir satırı geçtiğinde, o zaman çok fazla bir parametredir. Tüm parametreleri göz temasını kesmeden tek bir satırda görmek istiyorum. Ama bu sadece benim kişisel tercihim.

Genelde 5 ile hemfikirim, ancak daha fazlasına ihtiyacım olan bir durum varsa ve sorunu çözmenin en açık yolu varsa, o zaman daha fazlasını kullanırdım.

Kısa süreli hafızada yedi şey var mı?

1. İşlevin adı
2. İşlevin dönüş değeri
3. Fonksiyonun amacı
4. Parametre 1
5. Parametre 2
6. Parametre 3
7. Parametre 4

En Kötü 5 Kod Parçacıklarında , ikincisi olan "Bu bir kurucu mu?" 37 ⋅ 4 ≈ 150'den fazla parametreye sahiptir:

Burada bir programcı bu yapıcı yazdı [... S] ome evet düşünebilirsiniz onun büyük bir yapıcı ama o tutulma otomatik kod oluşturma araçları [.] NOO, bu yapıcı içinde keşfettiğim, beni yapan küçük bir hata vardı bu kurucunun elle yazıldığı sonucuna varır. (Bu arada, bu sadece kurucunun üst kısmıdır, tamamlanmamıştır).

Gerekenden bir tane daha. Glib olmak istemiyorum, ancak mutlaka birkaç seçeneğe ihtiyaç duyan bazı işlevler var. Örneğin:

void *
mmap(void *addr, size_t len, int prot, int flags, int fildes, off_t offset);

6 argüman vardır ve her biri esastır. Ayrıca, gruplandırmayı haklı çıkarmak için aralarında ortak bir bağlantı yoktur. Belki "struct mmapargs" tanımlayabilirsiniz, ama bu daha kötü olurdu.

Göre Perl İyi Uygulamalar , 3 4 çok fazla olduğunu, tamamdır. Bu sadece bir rehber, ama dükkanımızda buna bağlı kalmaya çalışıyoruz.

5 parametrede kamusal fonksiyonların sınırını kendim çizeceğim

IMHO, uzun parametre listeleri yalnızca koddaki birkaç belirli yerden çağrılması gereken özel / yerel yardımcı işlevlerinde kabul edilebilir. Bu durumlarda, çok fazla durum bilgisini iletmeniz gerekebilir, ancak okunabilirlik endişe verici değildir, çünkü yalnızca siz (veya kodunuzu koruyacak ve modülünüzün temellerini anlaması gereken) ilgilenmek zorundadır bu işlevi çağırır.

Dikkate almanız gereken ilgili bir soru , rutinin ne kadar uyumlu olduğudur . Çok sayıda parametre, rutinin kendisinin çok fazla yapmaya çalıştığını söyleyen bir koku olabilir ve bu nedenle uyum şüphelidir. Zor ve hızlı bir sayıda parametrenin muhtemelen imkansız olduğunu kabul ediyorum, ancak yüksek bir uyum rutininin düşük sayıda parametre anlamına geleceğini tahmin ediyorum.

97 kulağa doğru geliyor.

Daha az ve esnekliğini kaybedersiniz.

Genel bir kural olarak üç parametrede duruyorum. Daha fazla ve bunun yerine bir dizi parametreyi veya bir yapılandırma nesnesini geçirmenin zamanı geldi, bu da gelecekteki parametrelerin API'yi değiştirmeden eklenmesine izin veriyor.

Parametre listesindeki uzunluk kısıtlaması yalnızca bir kısıtlamadır. Kısıtlama, uygulanan şiddet anlamına gelir. Kulağa komik geliyor, ancak programlama yaparken bile şiddetsiz olabilirsiniz. Kodun kuralları dikte etmesine izin verin. Çok sayıda parametreniz varsa, işlev / sınıf yönteminin gövdesinin bunları kullanabilecek kadar büyük olacağı açıktır. Ve büyük kod parçacıkları genellikle yeniden düzenlenebilir ve daha küçük parçalara bölünebilir. Böylece, daha küçük yeniden düzenlenmiş kod parçaları arasında bölündüğünden, birçok parametreye ücretsiz bonus olarak sahip olmanıza karşı çözüm elde edersiniz.

Performans perspektifinden işaret ettiğim bir şey, bir yönteme parametreleri nasıl geçirdiğinize bağlı olarak, her parametrenin kopyalanıp yığına yerleştirilmesi gerektiğinden, değere göre çok sayıda parametrenin geçirilmesi programı yavaşlatır.

Tüm parametreleri kapsamak için tek bir sınıf kullanmak daha iyi sonuç verecektir, çünkü referansla iletilen tek bir parametre zarif ve daha temiz ve daha hızlı olacaktır!

Bana göre 4'ü veya sabit bir sayıyı aşacağınız durumlar olabilir. Dikkat edilecek şeyler olabilir

1. Metodunuz çok fazla şey yapıyor ve yeniden düzenleme yapmanız gerekiyor.
2. Bir koleksiyon veya bazı veri yapıları kullanmayı düşünebilirsiniz.
3. Sınıf tasarımınızı yeniden düşünün, belki bazı şeylerin geçmesine gerek yoktur.

Kullanım kolaylığı veya kod okuma kolaylığı açısından, yöntem imzanızı "kelime sarmak" gerektiğinde, sizi durduracak ve düşünecek bir şey yapmayı düşünüyorum. sonuç yok. Geçmişteki ve günümüzdeki bazı çok iyi kütüphaneler 4-5'ten fazla çocuk arabası kullanıyor.

Temel kuralım, bir aramaya bakmak ve ne yaptığını söylemek için yeterince uzun parametreleri hatırlayabilmem gerektiğidir. Bu yüzden yönteme bakıp bir yöntemin çağrısına geçip hangi parametrenin ne yaptığını hatırlayamıyorsam, o zaman çok fazla var.

Benim için bu yaklaşık 5'e eşit, ama o kadar parlak değilim. Kilometreniz değişebilir.

Parametreleri tutmak için özellikleri olan bir nesne oluşturabilir ve ayarladığınız sınırı aşarsanız bu nesneyi iletebilirsiniz. Martin Fowler'in Yeniden Düzenleme kitabına ve yöntem çağrılarını basitleştirme bölümüne bakın .

Büyük ölçüde içinde çalıştığınız ortama bağlıdır. Örneğin javascript'i ele alalım. Javascript'te parametreleri iletmenin en iyi yolu anahtar / değer çiftlerine sahip nesneler kullanmaktır, bu da pratikte sadece bir parametreniz olduğu anlamına gelir. Diğer sistemlerde tatlı nokta üç veya dörde olacaktır.

Sonunda, hepsi kişisel zevkinize kadar kaynar.

3 ile anlaşacağım tamam, 4 bir rehber olarak çok fazla. 3'ten fazla parametre ile, kaçınılmaz olarak bir görevden daha fazlasını yaparsınız. Birden fazla görev ayrı yöntemlere bölünmelidir.

Bununla birlikte, üzerinde çalıştığım en son projeye baksaydım, istisnalar bol olurdu ve çoğu durumda 3 parametreye ulaşmak zor olurdu.

Bir rutinde 7-10 parametre varsa, onları yeni bir sınıfa paketlemeye bakıyorum, ancak bu sınıf, alıcılar ve ayarlayıcılarla bir grup alandan başka bir şey olmazsa, yeni sınıfın değerleri karıştırmaktan başka bir şey yapması gerekmez. dışarı. Aksi takdirde uzun parametre listesi koymak istiyorum.

Ortalama olarak, insanların bir seferde 7 +/- 2 şeyi başlarında tutabilecekleri bilinen bir gerçektir. Bu prensibi parametrelerle kullanmayı seviyorum. Programcıların ortalamanın üstünde zeki insanlar olduğunu varsayarsak, 10 yaşın üzerindeki her şeyin çok fazla olduğunu söyleyebilirim.

BTW, parametreler herhangi bir şekilde benzerse, bunları bir yapı veya sınıf yerine bir vektör veya listeye koyarım.

Cevabımı işlevin ne sıklıkta çağrıldığına dayandırırım.

Sadece bir kez çağrılan bir init işlevi ise, o zaman kimin umurunda, 10 parm veya daha fazla almasına izin verin.

Çerçeve başına bir sürü kez denirse, bir yapı yapma eğilimindeyim ve sadece daha hızlı olma eğiliminde olduğu için bir işaretçi geçiririm (her seferinde yapıyı yeniden inşa etmediğinizi varsayarsak).

Amazon şöhretinden Jeff Bezos'a göre, iki pizza ile beslenemez :