Однорядкові функції, які викликаються лише один раз

Розглянемо функцію без параметрів ( редагувати: не обов’язково) функцію, яка виконує єдиний рядок коду, і викликається лише один раз у програмі (хоча це неможливо, що вона буде потрібна знову в майбутньому).

Він міг би виконати запит, перевірити деякі значення, зробити щось, що стосується регулярного виразів ... нічого незрозумілого або "хакі".

Обґрунтуванням цього слід було б уникати важкочитаних оцінок:

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

де getCondition()однолінійна функція.

Моє запитання просто: чи це хороша практика? Мені це здається нормальним, але я довго не знаю ...

Залежить від цього одного рядка. Якщо рядок є читабельним і стислим сам по собі, функція може не знадобитися. Спрощений приклад:

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

OTOH, якщо функція дає гарну назву рядку коду, що містить, наприклад, складний, важко читається вираз, це цілком виправдано (для мене). Надуманий приклад (тут розбито на кілька рядків для читабельності):

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

Так, це можна використовувати для задоволення передового досвіду. Наприклад, краще, щоб чітко названа функція виконувала певну роботу, навіть якщо вона лише одна строка, ніж мати цей рядок коду в більшій функції, і потрібен однорядковий коментар з поясненням того, що він робить. Також сусідні рядки коду повинні виконувати завдання на одному рівні абстракції. Контрприклад - це щось подібне

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

У цьому випадку, безумовно, краще перенести середню лінію в розважливу функцію.

Я думаю, що у багатьох випадках така функція є гарним стилем, але ви можете розглядати локальну булеву змінну як альтернативу у випадках, коли вам не потрібно використовувати цю умову десь в інших місцях, наприклад:

bool someConditionSatisfied = [complex expression];

Це дасть підказку для зчитування коду та вбереже від введення нової функції.

На додаток до відповіді Петра , якщо цю умову, можливо, потрібно буде оновити в якийсь момент у майбутньому, зробивши її інкапсульованою так, як ви пропонуєте, у вас буде лише одна точка редагування.

Слідуючи прикладу Петра, якщо це

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

стає цим

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

Ви робите одну редакцію, і вона оновлюється повсюдно. Мудрість ремонту, це плюс.

Найбільш оптимізуючи компілятори, які оптимізують ефективність, видалять функціональний виклик і все одно вбудовують невеликий блок коду. Оптимізація чогось подібного може насправді зменшити розмір блоку (видаливши вказівки, необхідні для виклику функції, повернення тощо), тому це звичайно безпечно робити навіть в умовах, які в іншому випадку можуть перешкоджати вкладенню.

Крім читабельності (або доповнення до неї) це дозволяє записувати функції на належному рівні абстракції.

Це залежить. Іноді вираз краще інкапсулювати у функції / методі, навіть якщо це лише один рядок. Якщо читати складно або вам це потрібно в декількох місцях, то я вважаю це хорошою практикою. У довгостроковій перспективі це простіше в обслуговуванні, оскільки ви внесли єдину точку зміни та кращу читаність .

Однак іноді це просто щось, що вам не потрібно. Коли вираз легко прочитати в будь-якому випадку та / або просто з’являється в одному місці, тоді не загортайте його.

Я думаю, якщо у вас їх є лише кілька, то це добре, але проблема виникає, коли їх у вашому коді багато. І коли компілятор працює або інтерпітер (залежно від мови, якою ви користуєтесь), він переходить до цієї функції в пам'яті. Тож скажемо, що у вас є 3 з них, я не думаю, що комп'ютер помітить, але якщо ви почнете мати 100 з цих дрібниць, то система повинна реєструвати функції в пам'яті, які викликаються лише один раз, а потім не знищуються.

Я точно це зробив нещодавно у програмі, яку я переробляв, щоб явно визначити власне значення коду, не коментуючи:

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

    CheckInputs();

    if(HaveError())
        return;

    ...
}

Переміщення цього рядка у добре названий метод полегшує читання вашого коду. Багато інших вже згадували про це ("код самодокументування"). Інша перевага переходу його до методу полягає в тому, що це полегшує тестування одиниці. Коли це виділено у власний метод та перевірено блок, ви можете бути впевнені, що якщо / коли буде виявлена ​​помилка, її не буде у цьому методі.

Хороших відповідей уже багато, але є особливий випадок, який варто згадати .

Якщо ваш однорядковий оператор потребує коментаря , і ви зможете чітко визначити (що означає: ім'я) його призначення, розгляньте можливість вилучення функції при вдосконаленні коментаря в API doc. Таким чином ви полегшите швидше і зрозуміти виклик функції.

Цікаво, що те ж саме можна зробити, якщо наразі нічого не робити, але коментар, що нагадує про необхідні розширення (у найближчому майбутньому ¹⁾ ), тож це,

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

міг також змінитися в цьому

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

¹⁾ ви повинні бути впевнені в цьому (див. Принцип YAGNI )

Якщо мова підтримує це, я зазвичай використовую анонімні функції для цього.

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...

ІМХО - це хороший компроміс, оскільки він дає перевагу для читабельності, коли складний вираз не засмічує ifумову, уникаючи захаращування простору імен глобального / пакету невеликими мітками, що викидають. Додатковою перевагою є те, що функція "визначення" знаходиться саме там, де її використовується, що дозволяє легко змінювати та читати визначення.

Це не повинні бути лише предикатними функціями. Мені подобається включати неодноразову плиту котла в такі маленькі функції (Це особливо добре працює для генерації пітонічного списку, не захаращуючи синтаксис дужок). Наприклад, наступний спрощений приклад під час роботи з PIL в python

#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]