Sadece bir kere çağrılan tek satırlık fonksiyonlar

Tek bir kod satırı gerçekleştiren ve programda yalnızca bir kez çağrılan (gelecekte tekrar gerekli olması imkansız olmasa da) parametresiz ( düzenleme: zorunlu değil) bir işlev düşünün .

Bir sorgulama yapabilir, bazı değerleri kontrol edebilir, regex içeren bir şey yapabilir ... belirsiz olan herhangi bir şey veya "hack" olabilir.

Bunun arkasındaki mantık, zor okunabilen değerlendirmelerden kaçınmak olacaktır:

if (getCondition()) {
    // do stuff
}

getCondition()tek satır işlevi nerede ?

Sorum basit: bu iyi bir uygulama mı? Bana tamam gibi görünüyor ama uzun vadede bilmiyorum ...

Bir hatta bağlı. Satır okunabilir ve özlü ise, fonksiyon gerekmeyebilir. Basit örnek:

void printNewLine() {
  System.out.println();
}

OTOH, işlev, örneğin karmaşık, okunması zor bir ifade içeren bir kod satırına iyi bir ad verirse, mükemmel bir şekilde haklı çıkarıldı (bana). Tartışmalı örnek (burada okunabilirlik için birden fazla satıra bölünmüş):

boolean isTaxPayerEligibleForTaxRefund() {
  return taxPayer.isFemale() 
        && (taxPayer.getNumberOfChildren() > 2 
        || (taxPayer.getAge() > 50 && taxPayer.getEmployer().isNonProfit()));
}

Evet, bu en iyi uygulamaları karşılamak için kullanılabilir. Örneğin, açıkça adlandırılmış bir işlevin bazı işlerini yapması, sadece bir satır olsa bile, daha büyük bir işlev içinde bu kod satırına sahip olmaktan ve ne yaptığını açıklayan tek satırlık bir yorumdan daha iyidir. Ayrıca, komşu kod satırları aynı soyutlama düzeyinde görevleri gerçekleştirmelidir. Bir karşı örnek gibi bir şey olurdu

startIgnition();
petrolFlag |= 0x006A;
engageChoke();

Bu durumda, orta çizgiyi makul şekilde adlandırılmış bir işleve taşımak kesinlikle daha iyidir.

Birçok durumda böyle bir işlevin iyi bir tarz olduğunu düşünüyorum, ancak bu koşulu başka yerlerde kullanmanız gerekmediği durumlarda yerel bir boolean değişkenini alternatif olarak düşünebilirsiniz.

bool someConditionSatisfied = [complex expression];

Bu, kod okuyucusuna bir ipucu verecek ve yeni bir fonksiyon tanıtmaktan tasarruf sağlayacaktır.

Peter'ın cevabına ek olarak , bu koşulun gelecekte bir noktada güncellenmesi gerekebilirse, yalnızca tek bir düzenleme noktasına sahip olmanızı önerdiğiniz şekilde kapatarak.

Peter'ın örneğini takip ediyor, eğer öyleyse

boolean isTaxPayerEligibleForTaxRefund() {
  return taxPayer.isFemale() 
        && (taxPayer.getNumberOfChildren() > 2 
        || (taxPayer.getAge() > 50 && taxPayer.getEmployer().isNonProfit()));
}

bu olur

boolean isTaxPayerEligibleForTaxRefund() {
  return taxPayer.isMutant() 
        && (taxPayer.getNumberOfThumbs() > 2 
        || (taxPayer.getAge() > 123 && taxPayer.getEmployer().isXMan()));
}

Tek bir düzenleme yaparsınız ve evrensel olarak güncellenir. Bakım akıllıca, bu bir artı.

Performans açısından, çoğu optimizasyon derleyici işlev çağrısını kaldıracak ve küçük kod bloğunu yine de satır içi olarak kullanacaktır. Bunun gibi bir şeyi optimize etmek aslında blok boyutunu küçültebilir (işlev çağrısı, dönüş, vb. İçin gerekli talimatları silerek), aksi halde satır içi engellemeyi önleyebilecek koşullarda bile yapmak güvenlidir.

Okunabilirliğe ek olarak (veya tamamlayıcı olarak) bu, fonksiyonların uygun soyutlama düzeyinde yazılmasına izin verir.

Değişir. Bazen bir ifadeyi bir işlev / yöntemde kaplamak, sadece bir satır olsa bile daha iyidir. Okumak karmaşıksa veya birden fazla yerde ihtiyaç duyuyorsan, o zaman bunun iyi bir uygulama olduğunu düşünüyorum. Uzun vadede, tek bir değişim noktası ve daha iyi okunabilirlik sunduğunuz için bakımı daha kolaydır .

Ancak, bazen sadece ihtiyacınız olmayan bir şey. İfade yine de okunması kolaysa ve / veya sadece tek bir yerde göründüğünde, sarmayın.

Bence bunlardan sadece birkaçı varsa sorun değil, ancak kodunuzda bir sürü olduğunda sorun ortaya çıkıyor. Ve derleyici çalıştığında ya da yorumlayıcı (kullandığınız dile bağlı olarak) bellekte bu işleve gidiyor. Öyleyse, 3 tanesine sahip olduğunuzu varsayalım, bilgisayarın farkına varacağını sanmıyorum, ancak bu küçük şeylerden 100'ünü almaya başlarsanız, sistem yalnızca bir kez çağrılan ve daha sonra tahrip edilmeyen fonksiyonları belleğe kaydetmelidir.

Bu son şeyi, yakın zamanda yeniden yapılandıracağım bir uygulamada yaptım, kodun yorumlarının gerçek anlamını açıkça belirtmek için:

protected void PaymentButton_Click(object sender, EventArgs e)
    Func<bool> HaveError = () => lblCreditCardError.Text == string.Empty && lblDisclaimer.Text == string.Empty;

    CheckInputs();

    if(HaveError())
        return;

    ...
}

Bir satırı iyi adlandırılmış bir yönteme taşımak, kodunuzun okunmasını kolaylaştırır. Pek çok kişi bundan (“kendi kendini belgeleyen kod”) bahsetti. Onu bir yönteme taşımanın diğer bir avantajı da ünite testini kolaylaştırmasıdır. Kendi yöntemine göre izole edildiğinde ve ünite test edildiğinde, bir hata bulunursa / bu yöntemde olmayacağından emin olabilirsiniz.

Çok sayıda iyi cevap var, ancak bahsetmeye değer özel bir durum var .

Tek satırlı ifadeniz bir yoruma ihtiyaç duyuyorsa ve amacını açıkça tanımlayabiliyorsanız (yani: ad), yorumu API belgesine eklerken bir işlev çıkarmayı düşünün. Bu sayede fonksiyon çağrısını daha kolay ve anlaşılır hale getirirsiniz.

İlginç bir şekilde, şu anda yapacak bir şey yoksa, aynı şey yapılabilir, ancak gereken genişlemeleri hatırlatan bir yorum (çok yakın gelecekte ¹⁾ ), yani bu,

def sophisticatedHello():
    # todo set up
    say("hello")
    # todo tear down

Bu şekilde de değişmiş olabilir

def sophisticatedHello():
    setUp()
    say("hello")
    tearDown()

^{1) Bundan} gerçekten emin olmalısınız (bakınız YAGNI ilkesi).

Dil destekliyorsa, bunu yapmak için genellikle etiketli isimsiz fonksiyonları kullanırım.

someCondition = lambda p: True if [complicated expression involving p] else False
#I explicitly write the function with a ternary to make it clear this is a a predicate
if (someCondition(p)):
    #do stuff...

IMHO bu iyi bir uzlaşmadır, çünkü ifgenel / paket ad alanını küçük fırlatma etiketleriyle karıştırmadan kaçınırken , karmaşık ifadenin koşulu karıştırmaz olmasının okunabilirlik avantajını sağlar . "Tanım" fonksiyonunun, tanımın değiştirilmesini ve okunmasını kolaylaştığı yerlerde kullanılması doğru değildir.

Sadece yordam işlevleri olmak zorunda değildir. Tekrarlanan kazan plakasını da bunun gibi küçük fonksiyonlarda muhafaza etmeyi seviyorum (Braket sözdizimini karıştırmadan pitonik liste oluşturmak için özellikle iyi çalışıyor). Örneğin, python içinde PIL ile çalışırken aşağıdaki basitleştirilmiş örnek

#goal - I have a list of PIL Image objects and I want them all as grayscale (uint8) numpy arrays
im_2_arr = lambda im: array(im.convert('L')) 
arr_list = [im_2_arr(image) for image in image_list]