Bir işlev çok kısa olabilir mi?

Ne zaman kendimi aynı mantığı bir defadan fazla yazıyorsam, genellikle bir fonksiyona yapıyorum, bu yüzden uygulamamda bu mantığı sürdürmek için tek bir yer var. Yan etki, bazen aşağıdakiler gibi bir veya iki satır işleviyle bitmemdir:

function conditionMet(){
   return x == condition;
}

VEYA

function runCallback(callback){
   if($.isFunction(callback))
     callback();
}

Bu tembel mi yoksa kötü bir uygulama mı? Sadece soruyorum çünkü bu daha fazla sayıda fonksiyonun sonuçlanmasına neden olarak çok küçük bir mantık parçasını gerektirir.

Hehe, ah, Bay Brown, tanıştığım tüm geliştiricileri işlevlerini bu kadar küçük tutmaya ikna edebilseydim, inan bana, yazılım dünyası daha iyi bir yer olurdu!

1) Kod okunabilirliği on kat artar.

2) Okunabilirlik nedeniyle kodunuzun sürecini anlamak çok kolay.

3) KURU - Kendini Tekrar Etme - Buna çok iyi uyuyorsun!

4) Test Edilebilir. Küçük fonksiyonlar, test etmek için çok sık gördüğümüz 200 hat yönteminden milyonlarca kez daha kolaydır.

Oh ve performans açısından "fonksiyon atlaması" için endişelenmeyin. "Release" sürümleri ve derleyici optimizasyonları bizim için çok iyi bir şekilde ilgileniyor ve performans, sistem tasarımında başka bir yerde zamanın% 99'u.

Bu tembel midir? - Tam tersi!

Bu kötü bir uygulama mı? - Kesinlikle hayır. Katran toplarından veya bu kadar yaygın olan "Tanrı Nesneleri" nden bu şekilde yöntemlerin çekilmesi daha iyidir.

İyi çalışmaya devam edin, meslektaşım;)

Yeniden yapılandırılmış bir yöntemin şu durumlarda çok kısa olduğunu söyleyebilirim:

• İlkel bir işlemi çoğaltır, yöntem yapmaktan başka bir amaç için değil:

Ör:

boolean isNotValue() {
   return !isValue();
}

veya...

• Kod yalnızca bir kez kullanılır ve amacı bir bakışta anlaşılması kolaydır.

Ör:

void showDialog() {
    Dialog singleUseDialog = new ModalDialog();
    configureDialog(singleUseDialog);
    singleUseDialog.show();
}

void configureDialog(Dialog singleUseDialog) {
    singleUseDialog.setDimensions(400, 300);
}

Bu geçerli bir model olabilir, ancak geçersiz kılmak veya bu kodu başka bir yerde tekrar kullanmak istemediğim sürece, bu örnekte configureDialog () yönteminin satır içi olurdum.

Bir işlev çok kısa olabilir mi? Genel olarak hayır.

Aslında bunu sağlamanın tek yolu:

1. Tasarımınızdaki tüm sınıfları buldunuz
2. İşlevlerin sadece bir şeyi yapıyor.

İşlevlerinizi mümkün olduğunca küçük tutmaktır. Ya da başka bir deyişle, daha fazla ayıklamadığınız sürece, fonksiyonlarınızdan fonksiyonları ayıklayın. Ben buna "Sen düşene kadar çıkar" derim.

Bunu açıklamak için: Bir işlev, değişkenlerle iletişim kuran işlevsellik parçalarına sahip bir kapsamdır. Bir sınıf aynı zamanda değişkenlerle iletişim kuran işlevsellik parçalarına sahip bir kapsamdır. Bu yüzden uzun bir işlev her zaman küçük yöntemle bir veya daha fazla sınıfla değiştirilebilir.

Ayrıca, ondan başka bir işlevi çıkarmanıza izin verecek kadar büyük olan bir işlev, tanım gereği birden fazla şey yapıyor . Eğer Yani eğer olabilir başka bir işlev ayıklamak, sen gerektiğini o fonksiyonu ayıklamak.

Bazı insanlar bunun fonksiyonların çoğalmasına yol açacağından endişe ediyor. Haklılar. Olacak. Bu aslında iyi bir şey. Bu iyi çünkü fonksiyonların isimleri var. İyi adlar seçme konusunda dikkatli iseniz, bu işlevler diğer insanları sizin kodunuz üzerinden yönlendiren işaret mesajları olarak işlev görür. Aslında, iyi adlandırılmış ad alanlarının içindeki iyi adlandırılmış sınıfların içindeki iyi adlandırılmış işlevler, okuyucularınızın kaybolmamasını sağlamak için en iyi yollardan biridir.

Cleancoders.com at Clean Code Bölüm III'de bu konuda çok daha fazlası var

Vay, bu cevapların çoğu hiç de yardımcı olmuyor.

Kimliği tanımı olan hiçbir fonksiyon yazılmamalıdır . Diğer bir deyişle, işlev adı yalnızca işlevin İngilizce olarak yazılmış kod bloğuysa, işlev olarak yazmayın.

İşlevinizi conditionMetve bu diğer işlevi göz önünde bulundurun , addOne(paslı JavaScript'im için beni affedin):

function conditionMet() { return x == condition; }

function addOne(x) { return x + 1; }

conditionMetuygun bir kavramsal tanımdır; addOnebir totolojidir . conditionMetiyidir, çünkü conditionMet"koşul bir araya geldi" diyerek neyin gerektirdiğini bilmiyorsunuz , ancak addOneİngilizce okuduysanız neden aptalca olduğunu görebilirsiniz :

"For the condition to be met is for x to equal condition" <-- explanatory! meaningful! useful!

"To add one to x is to take x and add one." <-- wtf!

Hâlâ kutsal olabilecek bir şeyin aşkı için, lütfen, totolojik işlevler yazmayın!

(Ve aynı nedenle, her kod satırı için yorum yazmayın !)

Bir yorum ekleyerek bazı kodun amacının geliştirilebileceğini düşünüyorsanız, o yorumu eklemek yerine, kodu kendi yöntemine çıkartın. Kod ne kadar küçük olursa olsun.

Örneğin, kodunuz şöyle görünecekse:

if x == 1 { ... } // is pixel on?

bunun yerine şunun gibi görünmesini sağlayın:

if pixelOn() { ... }

ile

function pixelOn() { return x == 1; }

Başka bir deyişle, yöntem uzunluğu ile ilgili değil, kendi kendini belgeleyen kodla ilgilidir.

Bence aynen yapmak istediğin şey bu. Şu anda bu işlev yalnızca bir veya iki satır olabilir, ancak zamanla büyüyebilir. Ayrıca daha fazla işlev çağrısı yapmak, işlev çağrıları okumanıza ve içeride neler olduğunu anlamanıza olanak sağlar. Bu, kodunuzu çok daha kuru bir şekilde KURU (Kendinizi Tekrarlama) yapar .

Gördüğüm diğer tüm yazılarla aynı fikirdeyim. Bu iyi bir tarz.

Böyle küçük bir yöntemin ek yükü, optimizer'ın aramayı en iyi duruma getirip kodu sıraya sokabilmesi nedeniyle sıfır olabilir. Bunun gibi basit kod, optimize edicinin en iyi işi yapmasını sağlar.

Netlik ve basitlik için kod yazılmalıdır. Bir yöntemi iki rolden biriyle sınırlamaya çalışıyorum: karar vermek; veya iş yapmak. Bu bir satır yöntemi üretebilir. Bunu ne kadar iyi yaparsam kodumu o kadar iyi bulurum.

Bunun gibi kodlar, iyi kodlama uygulaması olan yüksek uyum ve düşük bağlanma eğilimindedir.

EDIT: Yöntem isimleri üzerine bir not. Yöntemin nasıl yaptığını belirten olmayan bir yöntem adı kullanın. Ben verb_noun (_modifier) ​​iyi bir adlandırma şemasıdır. Bu, Select_Customer_Using_NameIdx yerine Find_Customer_ByName gibi isimler verir. İkinci durum, yöntem değiştirildiği zaman yanlışlığa meyillidir. İlk durumda, Müşteri veritabanı uygulamasının tamamını değiştirebilirsiniz.

Bir kod satırını bir işleve yeniden yerleştirmek aşırı görünüyor. Ver loooooong / comples lines veya expessions gibi istisnai durumlar olabilir, ancak gelecekte fonksiyonun büyüyeceğini bilmediğim sürece bunu yapmam .

ve ilk örneğiniz küresel kullanımdaki ipuçlarını (koddaki diğer konulardan bahsedebilir veya konuşmayabilir), onu daha da yeniden düzenler ve bu iki değişkeni parametre olarak yapardım:

function conditionMet(x, condition){
   return x == condition;
}
....
conditionMet(1,(3-2));
conditionMet("abc","abc");

conditionMetÖrnek olabilir durumu gibi uzun ve tekrarlayan ise yararlı olabilir:

function conditionMet(x, someObject){
   return x == ((someObject.valA + someObject.valB - 15.4) / /*...whole bunch of other stuff...*/);
}

Bunu düşün:

Basit bir çarpışma algılama fonksiyonu:

bool collide(OBJ a, OBJ b)
{
    return(pow(a.x - b.x, 2) + pow(a.y - b.y, 2) <= pow(a.radius + b.radius, 2));
}

Bu "basit" bir liner'i kodunuzda her zaman yazdıysanız, sonunda bir hata yapabilirsiniz. Artı, bunu tekrar tekrar yazmak gerçekten zor olurdu.

Hayır, bu nadiren sorun olur. Şimdi eğer birisi hiçbir işlevin bir işlev satırından daha uzun olması gerektiğini düşünürse (sadece bu kadar basit olabilseydi), bu bir problem olurdu ve bir şekilde tembel olurdu çünkü ne uygun olduğunu düşünmezler.

Çok kısa olduklarını söyleyebilirim ama bu benim öznel görüşüm.

Çünkü:

• Yalnızca bir veya iki kez kullanılırsa, işlev oluşturmak için hiçbir neden yoktur. Defs için atlama emmek. Özellikle şaşırtıcı derecede hızlı VS ve C ++ kodu ile.
• Sınıfa genel bakış Binlerce küçük işleviniz olduğunda, bu beni kızdırıyor. Sınıf tanımlarını görüntüleyebildiğimde ve hızlıca ne yaptığını görebildiğimde zevk alıyorum, SetXToOne, SetYToVector3, MultiplyNumbers, + 100 setters / getters.
• Çoğu projede bu yardımcılar iki cevher çıkarma aşamasından sonra bir kilo alırlar ve daha sonra eski kodlardan kurtulmak için "hepsini ara" -> silersiniz, genellikle ~% 25 +.

Uzun olan işlevler kötüdür, ancak 3 satırdan daha kısa olan ve yalnızca 1 şey yapan işlevler eşit derecede kötü IMHO'dur.

Öyleyse sadece küçük işlevler yazalım derdim:

• 3+ kod satırı
• Ufak tefeklerin kaçırabileceği şeyler var mı (bilmiyorum)
• Ek doğrulama yapar
• En az 3x kullanılır veya kullanılır
• Sık kullanılan arayüzü basitleştirir
• Bir sonraki refactoring sırasında ölü ağırlık olmayacak
• Özel bir anlamı var, örneğin, şablon uzmanlığı veya başka bir şey
• Bazı tecrit işleri yapar - const referansları, değişken parametreleri etkiler, özel üye alımı yapar

Bahse girerim bir sonraki geliştirici (kıdemli) tüm SetXToOne işlevlerinizi hatırlamaktan daha iyisini yapacak. Böylece her iki şekilde de kısa sürede ölü kiloya dönecekler.

Hayır örnek sevmiyorum. 1, bunun genel adı bcause.

conditionMetgenel gibi görünmüyor, bu yüzden belirli bir durum için duruyor? Sevmek

isAdult () = { 
  age >= 18 
}

Bu iyi olurdu. Anlamsal bir fark ise

isAtLeast18 () { age >= 18; } 

benim için iyi olmazdı.

Belki de sıklıkla kullanılır ve daha sonra değişebilir.

getPreferredIcecream () { return List ("banana", "choclate", "vanilla", "walnut") }

de iyi. Birden çok kez kullanarak, sadece tek bir yeri değiştirmeniz gerekir, gerekirse - belki çırpılmış krema yarın mümkün olur.

isXYZ (Foo foo) { foo.x > 15 && foo.y < foo.x * 2 }

atomik değildir ve size güzel bir test fırsatı sunmalıdır.

Bir işlevi geçmeniz gerekiyorsa, elbette, ne istersen onu ilet ve aksi halde aptalca görünen işlevler yaz.

Fakat genel olarak, çok kısa olan fonksiyonlardan çok uzun olan fonksiyonlar görüyorum.

Son söz: Bazı fonksiyonlar sadece uygun görünüyor çünkü çok ayrıntılı yazılmışlar:

function lessThan (a, b) {
  if (a < b) return true else return false; 
}

Görüyorsanız, bunun aynı olduğunu

return (a < b); 

sorun yaşamayacaksın

localLessThan = (a < b); 

onun yerine

localLessThan = lessThan (a, b); 

Kod gibi kod yok!

Basit tutun ve işleri zorlaştırmayın.

Tembel olmak değil, işini yapıyor!

Evet, kısa kod işlevine sahip olmak tamam. “Alıcı”, “ayarlayıcı”, “alıcı” gibi yöntemlerde, önceki cevaplarda belirtildiği gibi çok yaygındır.

Bazen, bu kısa "erişimciler" işlevleri sanaldır, çünkü alt sınıflarda geçersiz kılındığında işlevlerin daha fazla kodu olacaktır.

Çok kısa, iyi, pek çok işlevde, genel veya yöntemlerde işlev görmemenizi istiyorsanız, genellikle doğrudan geri dönüş yerine bir "sonuç" değişkeni (pascal stili) kullanırım, bu hata ayıklayıcı kullanırken çok yardımcı olur.

function int CalculateSomething() {
  int Result = -1;

   // more code, maybe, maybe not

  return Result;
}

Çok kısa asla bir problem değildir. Kısa işlevlerin bazı nedenleri:

Tekrar Kullanılabilirlik

Örneğin, bir set yöntemi gibi bir fonksiyonunuz varsa, parametrelerin geçerli olduğundan emin olmak için bunu iddia edebilirsiniz. Bu kontrol, değişkenin ayarlandığı her yerde yapılmalıdır.

İdame

Gelecekte değişebileceğini düşündüğünüz bazı ifadeleri kullanabilirsiniz. Örneğin, şimdi bir sütunda bir sembol gösterirsiniz, ancak daha sonra başka bir şeye (veya bir bip sesine) dönüşebilir.

tekdüzelik

Örneğin cephe deseni kullanıyorsunuz ve bir fonksiyonun yaptığı tek şey argümanları değiştirmeden fonksiyonu diğerine geçirmek.

Bir kod bölümüne bir ad verdiğinizde, esasen bir ad vermek içindir . Bu, birkaç nedenden dolayı olabilir, ancak önemli olan nokta, programınıza ekleyen anlamlı bir isim verebilmenizdir . "AddOneToCounter" gibi isimler hiçbir şey eklemeyecek, ama conditionMet()olacaktı.

Snippet'in çok kısa veya çok uzun olup olmadığını anlamak için bir kurala ihtiyacınız varsa, snippet için anlamlı bir ad bulmanın ne kadar sürdüğünü göz önünde bulundurun. Makul bir süre içinde yapamıyorsanız, pasaj uygun bir boyutta değildir.

Hayır, ama çok kısa olabilir.

Unutmayın: Kod bir kez yazılır, ancak birçok kez okunur.

Derleyici için kod yazmayın. Kodunuzu korumak zorunda kalacak gelecekteki geliştiriciler için yazın.

Evet canım, İşlev daha küçük ve daha küçük olabilir ve iyi ya da kötü olup, kullandığınız Dile / Çerçeveye bağlıdır.

Bence çoğunlukla Ön Uç Teknolojileri üzerinde çalışıyorum, Küçük İşlevler çoğunlukla yardımcı işlevler olarak kullanılıyor, küçük filtrelerle çalışırken ve uygulamanızda aynı mantığı kullanırken bunları bir sürü gibi kullanmak zorunda kalacaksınız. Uygulamanızın çok ortak bir mantığı varsa, o zaman bir ton küçük işlev gibi olacak.

Ancak ortak bir mantığa sahip olmadığınız bir uygulamada küçük işlevler yapmak zorunda değilsiniz, ancak kodunuzu yönetmeniz ve anlamanızın kolaylaştığı bölümlere bölebilirsiniz.

Genel olarak büyük kodunuzu küçük fonksiyonlara bölmek çok iyi bir yaklaşımdır. Modern çerçevelerde ve dillerde, örneğin, buna mecbur kalacaksınız.

data => initScroll(data)

2017 JavaScript ve Typescript’te adsız bir işlevdir

getMarketSegments() {
 this.marketService.getAllSegments(this.project.id)
  .subscribe(data => this.segments = data, error => console.log(error.toString()));
}

Yukarıdaki kodda 3 İşlev bildirimi ve 2 işlev çağrısı görebilirsiniz. Bu, Typcript 4 ile Açısal 4'te basit bir Servis Çağrısıdır. Gereksinimleriniz olarak düşünebilirsiniz

([] 0)
([x] 1)
([x y] 2)

Yukarıdakiler clojure dilinde 3 isimsiz fonksiyondur. Language

(def hello (fn [] "Hello world"))

Yukarıdakilerden biri, clojure'da işlevsel bir bildiridir

Yani evet FONKSİYONLAR daha küçük olabilir, ancak aşağıdaki gibi işlevleriniz varsa iyi ya da kötü olsun:

incrementNumber(numb) { return ++numb; }

Peki, bunu yapmak iyi bir uygulama değil, peki ya bu işlevi Angular Framework’te yaptığımız gibi bir HTML etiketinde kullanıyorsanız, Angular HTML Şablonlarında Artırma veya Azaltma desteği olmasaydı, o zaman bunun çözümü olurdu. ben mi.

Başka bir örnek alalım

insertInArray(array, newKey) {
 if (!array.includes(newKey)) {
   array.push(newKey);
 }
}

Yukarıdaki örnek, Angular HTML Şablonları içindeki dizilerde oynatırken bir zorunluluktur. Bu yüzden bazen küçük fonksiyonlar yaratmanız gerekebilir

Şu anda verilen neredeyse cevap ile katılmıyorum.

Son zamanlarda, tüm sınıf üyelerini aşağıdaki gibi yazan bir meslektaş buldum:

 void setProperty(int value){ mValue=value; }
 int getProperty() const { return (mValue); }

Bu sporadik durumlarda iyi bir kod olabilir, ancak çok ve çok özelliklere sahip birçok sınıf tanımladığınızda kesinlikle değil. Bununla, yukarıdaki gibi yöntemlerin yazılmayacağını söylemek istemiyorum. Ancak, kodun çoğunu gerçek mantığın "sarmalayıcı" olarak yazmaktan vazgeçerseniz, yanlış bir şey vardır.

Muhtemelen programcı genel mantığı özlüyor, gelecekteki değişikliklerden ve kodu yeniden düzenlemekten korkuyor.

Arayüzün tanımı gerçek bir ihtiyaç; Gerçekten de, basit bir özellik ayarlamanız ve elde etmeniz gerekirse (üyeyi kısaltan çok mantık olmadan) mümkün olacaktır. Ancak, gerçek ihtiyaç farklı bir şekilde analiz edilebiliyorsa, neden daha sezgisel bir arayüz tanımlamıyorsunuz?

Soruyu gerçekten cevaplamak için elbette hayır ve sebep çok açık: İhtiyaç duyduğu şey için yöntem / özellik / ne yöntemi tanımlanmalıdır. Boş bir sanal fonksiyonun bile var olmasının bir nedeni var.