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

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

Он может выполнить запрос, проверить некоторые значения, сделать что-то с использованием регулярных выражений ... что-то неясное или «хакерское».

Основанием для этого было бы избежать трудно читаемых оценок:

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 из них, я не думаю, что компьютер заметит, но если вы начнете иметь сотни из этих мелких вещей, то система должна зарегистрировать функции в памяти, которые вызываются только один раз, а затем не уничтожаются.

Я сделал это точно недавно в приложении, которое я рефакторинг, чтобы сделать явный смысл кода без комментариев:

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

    CheckInputs();

    if(HaveError())
        return;

    ...
}

Перемещение этой строки в метод с именем с именем облегчает чтение вашего кода. Многие другие уже упоминали это («самодокументируемый код»). Другое преимущество переноса его в метод состоит в том, что он облегчает юнит-тестирование. Когда он изолирован в своем собственном методе и проверен модулем, вы можете быть уверены, что если / когда будет обнаружена ошибка, его не будет в этом методе.

Хороших ответов уже много, но стоит упомянуть особый случай .

Если ваш однострочный оператор нуждается в комментарии , и вы можете четко определить (что означает: имя) его назначение, рассмотрите возможность извлечения функции при расширении комментария в документ API. Таким образом, вы сделаете вызов функции быстрее и понятнее.

Интересно, что то же самое можно сделать, если в настоящее время делать нечего, кроме комментария, напоминающего о необходимых расширениях (в ближайшем будущем ¹⁾ ), так что это,

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

может также измениться в этом

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

¹⁾ вы должны быть действительно уверены в этом (см. Принцип ЯГНИ )

Если язык поддерживает это, я обычно использую помеченные анонимные функции для достижения этой цели.

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условие, избегая загромождения пространства имен global / package с маленькими одноразовыми метками. Дополнительным преимуществом является то, что функция «определение» находится там, где она используется, что упрощает изменение и чтение определения.

Это не только предикатные функции. Мне также нравится заключать повторяющиеся шаблоны в небольшие функции, подобные этой (это особенно хорошо работает для генерации списка pythonic без загромождения синтаксиса скобок). Например, следующий упрощенный пример при работе с 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]