Va bene avere un metodo per restituire diversi tipi in base a un parametro?

5

Sto cercando un riferimento per gli stili di codifica puliti che posso passare a un membro del team.

In particolare, la regola secondo cui un metodo non dovrebbe cambiare il suo tipo di ritorno in base a un parametro di input. Se hai bisogno di output diversi, usa un metodo diverso.

Esempio:

$invoice_items = getInvoiceItems();
$total         = getInvoiceItems( TRUE );

Per me, questo è uno stile di codifica errato (e non sto nemmeno parlando di un parametro il cui significato non può essere determinato dal codice chiamante).

L'esempio sopra dovrebbe essere in realtà:

$total = totalInvoiceItems();

... dove totalInvoiceItems() potrebbe chiamare getInvoiceItems() per ottenere gli elementi di cui ha bisogno di totalizzare.

Dove troverei un riferimento a questo (e probabilmente ad altre importanti regole di stile di codifica)?

    
posta RickMeasham 16.04.2013 - 07:18
fonte

2 risposte

14

Come ha detto Eric, la bandiera booleana come selettore di comportamento è un segnale rivelatore che qualcosa non va nel contratto della funzione.

Ragioni, perché questo è un problema

  • Il contratto di funzione è inutilmente complicato. È facile spiegare il contratto di una funzione che restituisce semplicemente tutti gli articoli della fattura, così come è facile spiegare una funzione che prende un elenco di articoli della fattura e restituisce la somma dei loro importi di pagamento. È molto più complicato spiegare la versione del parametro booleano opzionale.

  • Il nome della funzione non ti dice cosa fa la funzione. getInvoiceItems sembra che dovrebbe darmi alcuni elementi, non un valore di somma. Analogamente, la suddivisione in due funzioni ti dà qualcosa come sumOfInvoiceItems($items) , che è di nuovo autoesplicativo.

  • L'implementazione della funzione stessa è inutilmente complicata. Più semplice è una funzione, più facile è capire, spiegare, verificare ... Le funzioni più complesse sono migliori per attirare bug, quindi è semplice è meglio.

Riferimenti

  • Il riferimento principale al codice pulito è naturalmente il libro con lo stesso nome di Uncle Bob . Troverete ragionamenti più dettagliati per mantenere le vostre funzioni brevi e semplici con contratti puliti e nominarli bene.

  • Anche se solitamente viene applicato alle classi, invece delle funzioni, è possibile applicare anche il principio di responsabilità singola a una funzione. Ma comunque, l'SRP deriva anche dallo zio Bob, quindi immagino che il vero riferimento sia solo lo zio Bob.

risposta data 16.04.2013 - 07:38
fonte
5

Le funzioni dovrebbero comportarsi in modo coerente. C'è una seconda funzione nascosta comunque in funzioni con un parametro booleano.

Se all'interno della funzione c'è un ramo con due comportamenti per lo più diversi, perché non renderlo due funzioni e magari considerare il codice comune in un terzo? C'è una carenza di dichiaratori di funzioni?

    
risposta data 16.04.2013 - 07:25
fonte

Leggi altre domande sui tag