Fonctions sur une ligne appelées une seule fois

Considérez une fonction sans paramètre ( edit: pas nécessairement) qui exécute une seule ligne de code et qui n’est appelée qu’une fois dans le programme (bien qu’il ne soit pas impossible que cela soit nécessaire à nouveau).

Il pourrait effectuer une requête, vérifier certaines valeurs, faire quelque chose impliquant regex ... rien d'obscur ou "hacky".

La raison en serait d'éviter les évaluations difficilement lisibles:

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

où getCondition()est la fonction d'une ligne.

Ma question est simplement: est-ce une bonne pratique? Cela me semble bien mais je ne sais pas pour le long terme ...

Cela dépend de cette ligne. Si la ligne est lisible et concise par elle-même, la fonction peut ne pas être nécessaire. Exemple simpliste:

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

OTOH, si la fonction donne un bon nom à une ligne de code contenant par exemple une expression complexe et difficile à lire, elle est parfaitement justifiée (pour moi). Exemple élaboré (divisé en plusieurs lignes pour la lisibilité ici):

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

Oui, cela peut être utilisé pour satisfaire les meilleures pratiques. Par exemple, il est préférable de faire travailler une fonction clairement nommée, même si elle ne comporte qu'une ligne, plutôt que d'avoir cette ligne de code dans une fonction plus grande et d'avoir besoin d'un commentaire d'une ligne expliquant ce qu'elle fait. En outre, les lignes de code voisines doivent effectuer des tâches au même niveau d'abstraction. Un contre-exemple serait quelque chose comme

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

Dans ce cas, il est définitivement préférable de déplacer la ligne médiane dans une fonction nommée de manière sensée.

Je pense que dans de nombreux cas, une telle fonction est un bon style, mais vous pouvez envisager une variable booléenne locale comme alternative, dans les cas où vous n'avez pas besoin d'utiliser cette condition ailleurs, par exemple:

bool someConditionSatisfied = [complex expression];

Cela donnera un indice au lecteur de code et évitera l’introduction d’une nouvelle fonction.

En plus de la réponse de Peter , si cette condition doit éventuellement être mise à jour ultérieurement, encapsulez-la de la manière que vous proposez de ne disposer que d'un seul point de montage.

Suivant l'exemple de Peter, si cela

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

devient ceci

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

Vous effectuez une édition unique et elle est mise à jour universellement. Maintenabilité sage, c'est un plus.

En ce qui concerne les performances, la plupart des compilateurs optimiseurs suppriment néanmoins l’appel de fonction et insèrent le petit bloc de code en ligne. Optimiser quelque chose comme ceci peut en fait réduire la taille du bloc (en supprimant les instructions nécessaires pour l'appel de fonction, le retour, etc.). Il est donc prudent de le faire même dans des conditions qui pourraient autrement empêcher l'inlining.

En plus de la lisibilité (ou en complément de celle-ci), cela permet d’écrire des fonctions au niveau d’abstraction approprié.

Ça dépend. Parfois, il est préférable d'encapsuler une expression dans une fonction / méthode, même s'il ne s'agit que d'une ligne. Si c'est compliqué à lire ou si vous en avez besoin à plusieurs endroits, je considère cela comme une bonne pratique. À long terme, il est plus facile à maintenir, car vous avez introduit un point de changement unique et une meilleure lisibilité .

Cependant, parfois, c'est juste quelque chose dont vous n'avez pas besoin. De toute façon, quand l’expression est facile à lire et / ou apparaît juste à la même place, ne l’emballez pas.

Je pense que si vous n'en avez que quelques-uns, c'est correct, mais le problème se pose lorsqu'il y en a beaucoup dans votre code. Et lorsque le compilateur ou l'interpréteur s'exécute (selon la langue utilisée), cette fonction est enregistrée en mémoire. Alors disons que vous en avez 3, je ne pense pas que l'ordinateur le remarquera, mais si vous commencez à avoir une centaine de ces petites choses, le système doit alors enregistrer des fonctions en mémoire qui ne sont appelées qu'une fois et ne sont pas détruites.

J'ai récemment effectué cette opération dans une application que je refacturais, afin d'expliciter le sens réel du code sans commentaires:

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

    CheckInputs();

    if(HaveError())
        return;

    ...
}

Déplacer cette ligne dans une méthode bien nommée rend votre code plus facile à lire. Beaucoup d'autres ont déjà mentionné cela ("code auto-documenté"). L’autre avantage de l’intégrer dans une méthode est qu’elle facilite le test unitaire. Une fois isolé dans sa propre méthode et testé dans l'unité, vous pouvez être sûr que si / quand un bogue est trouvé, il ne le sera pas dans cette méthode.

Il y a déjà beaucoup de bonnes réponses, mais il y a un cas particulier qui mérite d'être mentionné .

Si votre déclaration d' une ligne nécessite un commentaire et que vous êtes en mesure d'identifier clairement (ce qui signifie: nommez) son objectif, envisagez d'extraire une fonction tout en améliorant le commentaire dans la documentation de l'API. De cette façon, l'appel de fonction est plus facile à comprendre et à comprendre.

Il est intéressant de noter que la même chose peut être faite s’il n’ya actuellement rien à faire, mais un commentaire rappelant les extensions nécessaires (dans un avenir très proche ¹⁾ ), alors ceci:

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

pourrait aussi bien changé en cette

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

¹⁾ vous devriez être vraiment sûr de cela (voir principe de YAGNI )

Si le langage le prend en charge, j'utilise généralement des fonctions anonymes étiquetées pour accomplir cela.

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 c'est un bon compromis car il vous donne l'avantage de la lisibilité de ne pas avoir l'expression compliquée encombrant la ifcondition tout en évitant d'encombrer l'espace de noms global / package avec de petites étiquettes à jeter. Cela a l'avantage supplémentaire que la fonction "définition" est exacte là où elle est utilisée, ce qui facilite la modification et la lecture de la définition.

Il ne doit pas s'agir uniquement de fonctions de prédicats. J'aime aussi insérer de petites fonctions comme celle-ci dans la chaudière (cela fonctionne particulièrement bien pour la génération de listes pythoniques sans encombrer la syntaxe des crochets). Par exemple, l’exemple suivant trop simplifié lorsqu’on travaille avec 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]