Esistono linee guida su quanti parametri deve accettare una funzione?

Ho notato che alcune funzioni con cui lavoro hanno 6 o più parametri, mentre nella maggior parte delle librerie che uso è raro trovare una funzione che richiede più di 3.

Spesso molti di questi parametri extra sono opzioni binarie per modificare il comportamento della funzione. Penso che alcune di queste funzioni con parametri enumerati debbano probabilmente essere riformulate. C'è una linea guida per quale numero è troppi?

Non ho mai visto una linea guida, ma nella mia esperienza una funzione che accetta più di tre o quattro parametri indica uno dei due problemi:

1. La funzione sta facendo troppo. Dovrebbe essere suddiviso in diverse funzioni più piccole, ognuna con un set di parametri più piccolo.
2. C'è un altro oggetto nascosto dentro. Potrebbe essere necessario creare un altro oggetto o struttura dati che includa questi parametri. Vedere questo articolo sul modello Oggetto parametro per ulteriori informazioni.

È difficile dire cosa stai guardando senza ulteriori informazioni. È probabile che il refactoring che devi fare sia dividere la funzione in funzioni più piccole che vengono chiamate dal genitore a seconda di quei flag che sono attualmente passati alla funzione.

In questo modo si possono ottenere dei buoni guadagni:

• Rende il tuo codice più facile da leggere. Personalmente trovo molto più semplice leggere un "elenco di regole" composto da una ifstruttura che chiama molti metodi con nomi descrittivi rispetto a una struttura che fa tutto in un unico metodo.
• È più unità testabile. Hai suddiviso il tuo problema in diverse attività più piccole che sono individualmente molto semplici. La raccolta di test unitari sarebbe quindi composta da una suite di test comportamentali che controlla i percorsi attraverso il metodo master e una raccolta di test più piccoli per ogni singola procedura.

Secondo "Clean Code: A Handbook of Agile Software Craftsrafts", zero è l'ideale, uno o due sono accettabili, tre in casi speciali e quattro o più, mai!

Le parole dell'autore:

Il numero ideale di argomenti per una funzione è zero (niladic). Ne segue uno (monadico), seguito da vicino da due (diadico). Tre argomenti (triadici) dovrebbero essere evitati ove possibile. Più di tre (poliadici) richiedono una giustificazione molto speciale, e quindi non dovrebbero essere usati comunque.

In questo libro c'è un capitolo che parla solo di funzioni in cui i parametri sono ampiamente discussi, quindi penso che questo libro possa essere una buona guida di quanti parametri hai bisogno.

Secondo la mia opinione personale, un parametro è migliore di nessuno perché penso che sia più chiaro cosa sta succedendo.

Ad esempio, a mio avviso, la seconda scelta è migliore perché è più chiaro ciò che il metodo sta elaborando:

LangDetector detector = new LangDetector(someText);
//lots of lines
String language = detector.detectLanguage();

vs.

LangDetector detector = new LangDetector();
//lots of lines
String language = detector.detectLanguage(someText);

Su molti parametri, questo può essere un segno che alcune variabili possono essere raggruppate in un singolo oggetto o, in questo caso, molti booleani possono rappresentare che la funzione / metodo sta facendo più di una cosa, e in questo caso, è meglio riformattare ognuno di questi comportamenti in una funzione diversa.

Se le classi di dominio nell'applicazione sono progettate correttamente, il numero di parametri che passiamo in una funzione verrà automaticamente ridotto - perché le classi sanno come fare il loro lavoro e hanno abbastanza dati per fare il loro lavoro.

Ad esempio, supponi di avere una classe manager che chiede a una classe di terza elementare di completare i compiti.

Se modelli correttamente,

3rdGradeClass.finishHomework(int lessonId) {
    result = students.assignHomework(lessonId, dueDate);
    teacher.verifyHomeWork(result);
}

Questo è semplice

Se non hai il modello corretto, il metodo sarà così

Manager.finishHomework(grade, students, lessonId, teacher, ...) {
    // This is not good.
}

Il modello corretto riduce sempre i parametri delle funzioni tra le chiamate del metodo poiché le funzioni corrette sono delegate alle proprie classi (responsabilità singola) e dispongono di dati sufficienti per svolgere il proprio lavoro.

Ogni volta che vedo aumentare il numero di parametri, controllo il mio modello per vedere se ho progettato correttamente il mio modello di applicazione.

Vi sono tuttavia alcune eccezioni: quando avrò bisogno di creare un oggetto di trasferimento o oggetti di configurazione, userò un modello di generatore per produrre piccoli oggetti costruiti prima di costruire un grande oggetto di configurazione.

Un aspetto che le altre risposte non accettano è la prestazione.

Se si sta programmando in un linguaggio di livello sufficientemente basso (C, C ++, assembly) un gran numero di parametri può essere abbastanza dannoso per le prestazioni su alcune architetture, specialmente se la funzione viene chiamata un gran numero di volte.

Quando una chiamata di funzione è fatto in ARM per esempio, i primi quattro argomenti sono collocati nei registri r0di r3e restanti argomenti devono essere spinto sulla pila. Mantenere il numero di argomenti inferiore a cinque può fare la differenza per le funzioni critiche.

Per le funzioni che vengono chiamate estremamente spesso, anche il fatto che il programma deve impostare gli argomenti prima di ogni chiamata può influire sulle prestazioni ( r0per r3può sovrascrivere la funzione chiamata e dovrà essere sostituita prima della chiamata) in modo a tal riguardo zero argomenti sono i migliori.

Aggiornare:

KjMag porta in primo piano l'interessante argomento dell'inline. Inline in qualche modo lo mitigherà poiché consentirà al compilatore di eseguire le stesse ottimizzazioni che potresti fare se scrivessi in puro assembly. In altre parole, il compilatore può vedere quali parametri e variabili sono utilizzati dalla funzione chiamata e può ottimizzare l'utilizzo del registro in modo da ridurre al minimo lo stack read / write.

Tuttavia, ci sono alcuni problemi con l'allineamento.

1. Inline fa crescere il file binario compilato poiché lo stesso codice viene duplicato in forma binaria se viene chiamato da più posizioni. Questo è dannoso quando si tratta dell'utilizzo della cache I.
2. I compilatori di solito consentono solo l'allineamento fino a un certo livello (3 fasi IIRC?). Immagina di chiamare una funzione incorporata da una funzione incorporata da una funzione incorporata. La crescita binaria esploderebbe se inlinefosse considerata obbligatoria in tutti i casi.
3. Ci sono molti compilatori che ignoreranno completamente inlineo ti daranno effettivamente errori quando lo incontrano.

Quando l'elenco dei parametri aumenta a più di cinque, prendere in considerazione la definizione di una struttura o di un oggetto "contesto".

Questa è fondamentalmente solo una struttura che contiene tutti i parametri opzionali con alcune impostazioni predefinite sensibili.

Nel mondo procedurale C dovrebbe fare una struttura semplice. In Java, C ++ sarà sufficiente un semplice oggetto. Non scherzare con getter o setter perché il solo scopo dell'oggetto è di mantenere valori "pubblici" da impostare.

No, non esiste una linea guida standard

Ma ci sono alcune tecniche che possono rendere più sopportabile una funzione con molti parametri.

Puoi usare un parametro list-if-args (args *) o un parametro del dizionario di args (kwargs **)

Ad esempio, in Python:

// Example definition
def example_function(normalParam, args*, kwargs**):
  for i in args:
    print 'args' + i + ': ' + args[i] 
  for key in kwargs:
    print 'keyword: %s: %s' % (key, kwargs[key])
  somevar = kwargs.get('somevar','found')
  missingvar = kwargs.get('somevar','missing')
  print somevar
  print missingvar

// Example usage

    example_function('normal parameter', 'args1', args2, 
                      somevar='value', missingvar='novalue')

Uscite:

args1
args2
somevar:value
someothervar:novalue
value
missing

Oppure potresti usare la sintassi della definizione letterale dell'oggetto

Ad esempio, ecco una chiamata jQuery JavaScript per avviare una richiesta GET AJAX:

$.ajax({
  type: 'GET',
  url: 'http://someurl.com/feed',
  data: data,
  success: success(),
  error: error(),
  complete: complete(),
  dataType: 'jsonp'
});

Se dai un'occhiata alla classe ajax di jQuery ci sono molte (circa 30) più proprietà che possono essere impostate; principalmente perché le comunicazioni Ajax sono molto complesse. Fortunatamente, la sintassi letterale dell'oggetto semplifica la vita.

C # intellisense fornisce una documentazione attiva dei parametri, quindi non è raro vedere disposizioni molto complesse di metodi sovraccarichi.

I linguaggi tipizzati dinamicamente come python / javascript non hanno tale capacità, quindi è molto più comune vedere argomenti di parole chiave e definizioni letterali di oggetti.

Preferisco definizioni letterali di oggetti ( anche in C # ) per la gestione di metodi complessi perché puoi vedere esplicitamente quali proprietà vengono impostate quando un oggetto viene istanziato. Dovrai fare un po 'più di lavoro per gestire gli argomenti predefiniti, ma a lungo andare il tuo codice sarà molto più leggibile. Con le definizioni letterali di oggetti puoi interrompere la tua dipendenza dalla documentazione per capire cosa sta facendo il tuo codice a prima vista.

IMHO, i metodi sovraccarichi sono altamente sopravvalutati.

Nota: se ricordo bene il controllo dell'accesso in sola lettura dovrebbe funzionare per i costruttori letterali di oggetti in C #. Sostanzialmente funzionano come l'impostazione delle proprietà nel costruttore.

Se non hai mai scritto alcun codice non banale in un linguaggio basato su javaScript tipicamente dinamicamente (python) e / o funzionale / prototipo, ti consiglio vivamente di provarlo. Può essere un'esperienza illuminante.

Può essere spaventoso prima di tutto fare affidamento sui parametri per l'approccio end-all, be-all all'inizializzazione della funzione / metodo, ma imparerai a fare molto di più con il tuo codice senza dover aggiungere complessità inutili.

Aggiornare:

Probabilmente avrei dovuto fornire esempi per dimostrare l'uso in un linguaggio tipicamente statico, ma attualmente non sto pensando in un contesto tipicamente statico. Fondamentalmente, ho fatto troppo lavoro in un contesto tipizzato in modo dinamico per tornare all'improvviso.

Quello che non so è oggetto sintassi definizione letterale è completamente possibile in lingue staticamente tipizzati (almeno in C # e Java), perché li ho usato prima. Nei linguaggi tipicamente statici sono chiamati "inizializzatori di oggetti". Ecco alcuni link per mostrare il loro uso in Java e C # .

Personalmente, più di 2 è dove si attiva l'allarme odore di codice. Quando si considerano le funzioni come operazioni (ovvero una traduzione da input a output), non è raro che vengano utilizzati più di 2 parametri in un'operazione. Le procedure (ovvero una serie di passaggi per raggiungere un obiettivo) richiedono più input e talvolta sono l'approccio migliore, ma nella maggior parte delle lingue in questi giorni non dovrebbe essere la norma.

Ma ancora una volta, questa è la linea guida piuttosto che una regola. Ho spesso funzioni che accettano più di due parametri a causa di circostanze insolite o facilità d'uso.

Proprio come dice Evan Plaice, sono un grande fan del semplice passaggio di array associativi (o struttura di dati comparabili della tua lingua) in funzioni ogni volta che è possibile.

Pertanto, anziché (ad esempio) questo:

<?php

createBlogPost('the title', 'the summary', 'the author', 'the date of publication, 'the keywords', 'the category', 'etc');

?>

Andare per:

<?php

// create a hash of post data
$post_data = array(
  'title'    => 'the title',
  'summary'  => 'the summary',
  'author'   => 'the author',
  'pubdate'  => 'the publication date',
  'keywords' => 'the keywords',
  'category' => 'the category',
  'etc'      => 'etc',
);

// and pass it to the appropriate function
createBlogPost($post_data);

?>

Wordpress fa un sacco di cose in questo modo e penso che funzioni bene. (Sebbene il mio codice di esempio sopra sia immaginario e non sia esso stesso un esempio di Wordpress.)

Questa tecnica ti consente di trasferire facilmente molti dati nelle tue funzioni, ma ti libera dal dover ricordare l'ordine in cui ciascuno deve essere passato.

Apprezzerai anche questa tecnica quando arriverà il momento di refactoring - invece di dover potenzialmente cambiare l'ordine degli argomenti di una funzione (come quando ti rendi conto che devi passare Yet Another Argument), non devi cambiare il parametro delle tue funzioni elenco a tutti.

Questo non solo ti evita di dover riscrivere la definizione della tua funzione, ma ti risparmia di dover cambiare l'ordine degli argomenti ogni volta che la funzione viene invocata. È una vittoria enorme.

Una risposta precedente menzionava un autore affidabile che affermava che meno parametri hanno le vostre funzioni, meglio state facendo. La risposta non ha spiegato perché, ma i libri lo spiegano, e qui ci sono due dei motivi più convincenti per cui è necessario adottare questa filosofia e con la quale sono personalmente d'accordo:

• I parametri appartengono a un livello di astrazione diverso da quello della funzione. Questo significa che il lettore del tuo codice dovrà pensare alla natura e allo scopo dei parametri delle tue funzioni: questo pensiero è "di livello inferiore" rispetto a quello del nome e dello scopo delle loro corrispondenti funzioni.

• Il secondo motivo per avere il minor numero possibile di parametri per una funzione è il test: ad esempio, se si dispone di una funzione con 10 parametri, pensare a quante combinazioni di parametri è necessario coprire tutti i casi di test per, ad esempio, un'unità test. Meno parametri = meno test.

Per fornire un po 'più di contesto attorno al consiglio per il numero ideale di argomenti di funzione pari a zero nel "Clean Code: A Handbook of Agile Software Craftsrafts" di Robert Martin, l'autore afferma quanto segue come uno dei suoi punti:

Gli argomenti sono difficili. Prendono molto potere concettuale. Ecco perché mi sono liberato di quasi tutti dall'esempio. Considera, ad esempio, StringBufferl'esempio. Avremmo potuto trasmetterlo come argomento anziché trasformarlo in una variabile di istanza, ma i nostri lettori avrebbero dovuto interpretarlo ogni volta che lo vedevano. Quando leggi la storia raccontata dal modulo, includeSetupPage() è più facile da capire di includeSetupPageInto(newPageContent). L'argomento è a un diverso livello di astrazione che il nome della funzione e ti costringe a conoscere un dettaglio (in altre parole, StringBuffer) che non è particolarmente importante a quel punto.

Per il suo includeSetupPage()esempio sopra, ecco un piccolo frammento del suo "codice pulito" refactored alla fine del capitolo:

// *** NOTE: Commments are mine, not the author's ***
//
// Java example
public class SetupTeardownIncluder {
    private StringBuffer newPageContent;

    // [...] (skipped over 4 other instance variables and many very small functions)

    // this is the zero-argument function in the example,
    // which calls a method that eventually uses the StringBuffer instance variable
    private void includeSetupPage() throws Exception {
        include("SetUp", "-setup");
    }

    private void include(String pageName, String arg) throws Exception {
        WikiPage inheritedPage = findInheritedPage(pageName);
        if (inheritedPage != null) {
            String pagePathName = getPathNameForPage(inheritedPage);
            buildIncludeDirective(pagePathName, arg);
        }
    }

    private void buildIncludeDirective(String pagePathName, String arg) {
        newPageContent
            .append("\n!include ")
            .append(arg)
            .append(" .")
            .append(pagePathName)
            .append("\n");
    }
}

La "scuola di pensiero" dell'autore sostiene piccole classi, un numero basso (idealmente 0) di argomenti di funzioni e funzioni molto piccole. Anche se non sono pienamente d'accordo con lui, l'ho trovato stimolante e sento che vale la pena prendere in considerazione l'idea di argomenti con funzione zero come ideale. Inoltre, tieni presente che anche il suo piccolo frammento di codice sopra ha funzioni di argomento diverse da zero, quindi penso che dipenda dal contesto.

(E come altri hanno sottolineato, sostiene anche che più argomenti rendono più difficile dal punto di vista del test. Ma qui ho principalmente voluto evidenziare l'esempio sopra e la sua logica per argomenti con funzione zero.)

Idealmente zero. Uno o due sono ok, tre in alcuni casi.
Quattro o più di solito è una cattiva pratica.

Oltre ai singoli principi di responsabilità che altri hanno notato, puoi anche pensarci dai test e dal debug delle prospettive.

Se esiste un parametro, conoscerne i valori, testarli e trovare errori con essi è 'relativamente semplice in quanto esiste un solo fattore. Man mano che aumenti i fattori, la complessità totale aumenta rapidamente. Per un esempio astratto:

Considera un programma "cosa indossare in questo tempo". Considera cosa potrebbe fare con un input: la temperatura. Come puoi immaginare, i risultati di cosa indossare sono piuttosto semplici in base a quell'unico fattore. Ora considera cosa potrebbe / potrebbe / dovrebbe fare il programma se viene effettivamente superato temperatura, umidità, punto di rugiada, precipitazioni, ecc. Ora immagina quanto sarebbe difficile eseguire il debug se fornisse la risposta "sbagliata" a qualcosa.