Funzioni su una riga chiamate una sola volta

Considera una funzione senza parametri ( modifica: non necessariamente) che esegue una singola riga di codice e viene chiamata una sola volta nel programma (anche se non è impossibile che sia necessario di nuovo in futuro).

Potrebbe eseguire una query, controllare alcuni valori, fare qualcosa che coinvolge regex ... qualcosa di oscuro o "hacky".

La logica alla base di ciò sarebbe quella di evitare valutazioni difficilmente leggibili:

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

dov'è getCondition()la funzione di una riga.

La mia domanda è semplicemente: è una buona pratica? Mi sembra a posto ma non so a lungo termine ...

Dipende da quella riga. Se la riga è leggibile e concisa da sola, la funzione potrebbe non essere necessaria. Esempio semplicistico:

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

OTOH, se la funzione dà un buon nome a una riga di codice contenente ad esempio un'espressione complessa e difficile da leggere, è perfettamente giustificata (per me). Esempio contrastato (suddiviso in più righe per leggibilità qui):

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

Sì, questo può essere usato per soddisfare le migliori pratiche. Ad esempio, è meglio avere una funzione con un nome chiaro che faccia un po 'di lavoro, anche se è lunga solo una riga, piuttosto che avere quella riga di codice all'interno di una funzione più grande e avere bisogno di un commento di una riga che spieghi cosa fa. Inoltre, le righe di codice vicine dovrebbero eseguire attività allo stesso livello di astrazione. Un controesempio sarebbe qualcosa di simile

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

In questo caso è sicuramente meglio spostare la linea mediana in una funzione chiamata con un nome ragionevole.

Penso che in molti casi tale funzione sia di buon stile, ma potresti considerare una variabile booleana locale come alternativa nei casi in cui non è necessario utilizzare questa condizione da qualche parte in altri luoghi, ad esempio:

bool someConditionSatisfied = [complex expression];

Questo darà un suggerimento al lettore di codice e salverà dall'introduzione di una nuova funzione.

Oltre alla risposta di Peter , se in futuro potrebbe essere necessario aggiornare tale condizione, facendola incapsulare nel modo in cui suggerisci che avresti un solo punto di modifica.

Seguendo l'esempio di Pietro, se questo

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

diventa questo

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

Fai una singola modifica e viene aggiornata universalmente. Manutenibilità, questo è un vantaggio.

Per quanto riguarda le prestazioni, i compilatori più ottimizzanti rimuoveranno la chiamata di funzione e incorporeranno comunque il piccolo blocco di codice. L'ottimizzazione di qualcosa del genere può effettivamente ridurre la dimensione del blocco (eliminando le istruzioni necessarie per la chiamata di funzione, ritorno, ecc.), Pertanto è normalmente sicuro farlo anche in condizioni che potrebbero altrimenti impedire l'allineamento.

Oltre alla leggibilità (o in complemento di ciò), ciò consente di scrivere funzioni al giusto livello di astrazione.

Dipende. A volte è meglio incapsulare un'espressione in una funzione / metodo, anche se è solo una riga. Se è complicato da leggere o ne hai bisogno in più punti, allora lo considero una buona pratica. A lungo termine è più facile da mantenere, poiché hai introdotto un unico punto di cambiamento e una migliore leggibilità .

Tuttavia, a volte è solo qualcosa che non ti serve. Quando l'espressione è comunque facile da leggere e / o appare solo in un punto, non avvolgerla.

Penso che se ne hai solo alcuni, allora va bene, ma il problema si presenta quando ce ne sono molti nel tuo codice. E quando il compilatore viene eseguito o l'interpitor (a seconda della lingua utilizzata), andrà a quella funzione in memoria. Quindi supponiamo che tu ne abbia 3 che non credo che il computer noterà, ma se inizi a avere centinaia di quelle piccole cose, il sistema deve registrare le funzioni in memoria che vengono chiamate solo una volta e quindi non distrutte.

Ho fatto esattamente questa cosa di recente in un'applicazione che ho eseguito il refactoring, per rendere esplicito il significato reale del codice senza commenti:

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

    CheckInputs();

    if(HaveError())
        return;

    ...
}

Lo spostamento di quella riga in un metodo ben definito semplifica la lettura del codice. Molti altri lo hanno già menzionato ("codice auto-documentante"). L'altro vantaggio di spostarlo in un metodo è che semplifica il test unitario. Quando è isolato nel suo metodo e testato l'unità, puoi essere sicuro che se / quando viene trovato un bug, non sarà in questo metodo.

Ci sono già molte buone risposte, ma c'è un caso speciale degno di nota .

Se la tua dichiarazione di una riga necessita di un commento e sei in grado di identificare chiaramente (il che significa: nome) il suo scopo, considera di estrarre una funzione migliorando il commento nel documento API. In questo modo si rende la chiamata di funzione più semplice e veloce da capire.

È interessante notare che lo stesso può essere fatto se al momento non c'è nulla da fare, ma un commento che ricorda le espansioni necessarie (nel prossimo futuro ¹⁾ ), quindi questo,

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

potrebbe anche essere cambiato in questo

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

¹⁾ dovresti esserne veramente sicuro (vedi il principio YAGNI )

Se la lingua lo supporta, di solito uso funzioni anonime etichettate per farlo.

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 questo è un buon compromesso perché ti dà il vantaggio della leggibilità di non avere l'espressione complicata che ingombra la ifcondizione evitando allo stesso tempo di ingombrare lo spazio dei nomi globale / pacchetto con piccole etichette usa e getta. Ha l'ulteriore vantaggio che la funzione "definizione" è proprio dove viene utilizzata, facilitando la modifica e la lettura della definizione.

Non devono essere solo funzioni predicate. Mi piace racchiudere il ripetuto boiler-plate anche in piccole funzioni come questa (Funziona particolarmente bene per la generazione di liste pythonic senza ingombrare la sintassi della parentesi). Ad esempio, il seguente esempio semplificato quando si lavora con PIL in 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]