Funciones de una línea que se llaman solo una vez

Considere una función sin parámetros ( editar: no necesariamente) que realiza una sola línea de código y se llama solo una vez en el programa (aunque no es imposible que se vuelva a necesitar en el futuro).

Podría realizar una consulta, verificar algunos valores, hacer algo relacionado con expresiones regulares ... cualquier cosa oscura o "hacky".

La razón detrás de esto sería evitar evaluaciones difícilmente legibles:

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

¿Dónde getCondition()está la función de una línea?

Mi pregunta es sencilla: ¿es una buena práctica? Me parece bien, pero no sé a largo plazo ...

Depende de esa línea. Si la línea es legible y concisa por sí misma, la función puede no ser necesaria. Ejemplo simplista:

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

OTOH, si la función le da un buen nombre a una línea de código que contiene, por ejemplo, una expresión compleja y difícil de leer, está perfectamente justificada (para mí). Ejemplo contribuido (dividido en varias líneas para facilitar la lectura aquí):

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

Sí, esto puede usarse para satisfacer las mejores prácticas. Por ejemplo, es mejor tener una función claramente nombrada que haga algún trabajo, incluso si es solo una línea de largo, que tener esa línea de código dentro de una función más grande y necesitar un comentario de una línea que explique lo que hace. Además, las líneas de código vecinas deben realizar tareas en el mismo nivel de abstracción. Un contraejemplo sería algo así como

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

En este caso, definitivamente es mejor mover la línea media a una función con un nombre sensato.

Creo que en muchos casos esa función es un buen estilo, pero puede considerar una variable booleana local como alternativa en los casos en que no necesite usar esta condición en otro lugar, por ejemplo:

bool someConditionSatisfied = [complex expression];

Esto le dará una pista al lector de código y evitará la introducción de una nueva función.

Además de la respuesta de Peter , si es posible que esa condición deba actualizarse en algún momento en el futuro, al encapsularla de la forma en que sugiere que solo tendría un único punto de edición.

Siguiendo el ejemplo de Peter, si esto

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

se convierte en esto

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

Realiza una única edición y se actualiza universalmente. Mantenibilidad sabia, esto es una ventaja.

En cuanto al rendimiento, la mayoría de los compiladores de optimización eliminarán la llamada a la función y de todos modos alinearán el bloque de código pequeño. La optimización de algo como esto en realidad puede reducir el tamaño del bloque (eliminando las instrucciones necesarias para la llamada a la función, devolución, etc.), por lo que normalmente es seguro hacerlo incluso en condiciones que de otro modo podrían evitar la inserción.

Además de la legibilidad (o como complemento), esto permite escribir funciones en el nivel adecuado de abstracción.

Depende. A veces es mejor encapsular una expresión en una función / método, incluso si es solo una línea. Si es complicado de leer o lo necesita en varios lugares, entonces lo considero una buena práctica. A largo plazo, es más fácil de mantener, ya que ha introducido un único punto de cambio y una mejor legibilidad .

Sin embargo, a veces es algo que no necesitas. Cuando la expresión sea fácil de leer de todos modos y / o solo aparezca en un lugar, no la envuelva.

Creo que si solo tiene algunos, está bien, pero el problema surge cuando hay muchos en su código. Y cuando se ejecuta el compilador o el interpitor (según el idioma que utilice), va a esa función en la memoria. Digamos que tiene 3 de ellos, no creo que la computadora se dé cuenta, pero si comienza a tener cientos de esas pequeñas cosas, el sistema tiene que registrar funciones en la memoria que solo se llaman una vez y luego no se destruyen.

He hecho esto exactamente recientemente en una aplicación que he estado refactorizando, para hacer explícito el significado real del código sin comentarios:

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

    CheckInputs();

    if(HaveError())
        return;

    ...
}

Mover esa línea a un método bien nombrado hace que su código sea más fácil de leer. Muchos otros ya lo han mencionado ("código autodocumentado"). La otra ventaja de pasarlo a un método es que facilita la prueba unitaria. Cuando se aísla en su propio método y se prueba la unidad, puede estar seguro de que si se encuentra un error, no estará en este método.

Ya hay muchas buenas respuestas, pero hay un caso especial que vale la pena mencionar .

Si su declaración de una línea necesita un comentario , y puede identificar claramente (lo que significa: nombre) su propósito, considere extraer una función mientras mejora el comentario en el documento API. De esta forma, hace que la llamada a la función sea más rápida y fácil de entender.

Curiosamente, se puede hacer lo mismo si actualmente no hay nada que hacer, sino un comentario que recuerde las expansiones necesarias (en un futuro muy cercano ¹⁾ ), así que esto,

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

bien podría cambiar a esto

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

¹⁾ debes estar realmente seguro de esto (ver el principio de YAGNI )

Si el lenguaje lo admite, generalmente uso funciones anónimas etiquetadas para lograr esto.

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

En mi humilde opinión, este es un buen compromiso porque le brinda el beneficio de legibilidad de no tener la expresión complicada que satura la ifcondición mientras evita saturar el espacio de nombres global / paquete con pequeñas etiquetas desechables. Tiene el beneficio adicional de que la función "definición" está justo donde se está utilizando, lo que facilita la modificación y lectura de la definición.

No tiene que ser solo funciones predicadas. También me gusta encapsular la placa de caldera repetida en funciones pequeñas como esta (funciona particularmente bien para la generación de listas pitónicas sin saturar la sintaxis de paréntesis). Por ejemplo, el siguiente ejemplo demasiado simplificado cuando se trabaja con PIL en 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]