Argomenti con nome (parametri) come supporto per la leggibilità

Questo è stato suggerito nello sviluppo di C ++, e Stroustrup ne parla nel suo "Design ed Evolution of C ++", pagine 153 e seguenti. La proposta era ben strutturata e si basava su una precedente esperienza con Ada. Non è stato adottato.

La più grande ragione era che nessuno voleva incoraggiare le funzioni con un gran numero di parametri. Ogni caratteristica aggiuntiva in una lingua costa qualcosa, e non c'era il desiderio di aggiungere una funzionalità per rendere più facile scrivere programmi non validi.

Ha anche sollevato domande su quali fossero i nomi dei parametri canonici, in particolare nella solita intestazione e nella convenzione dei file di codice. Alcune organizzazioni avevano nomi di parametri più lunghi e più descrittivi nel file .h, e più brevi e più facili da digitare i nomi nel file .cpp (i suffissi del file sostitutivo sono desiderati). Richiedere che questi siano gli stessi sarebbe un costo aggiuntivo per la compilazione, e ottenere i nomi mescolati tra i file di origine potrebbe causare bug sottili.

Può anche essere gestito utilizzando oggetti piuttosto che chiamate di funzione. Invece di una chiamata GetWindow con una dozzina di parametri, creare una classe Window con una dozzina di variabili private e aggiungere setter secondo necessità. Concatenando i setter, è possibile scrivere qualcosa come my_window.SetColor(green).SetBorder(true).SetBorderSize(3); . È anche possibile avere diverse funzioni con diversi valori predefiniti che chiamano la funzione che effettivamente fa il lavoro.

Se sei solo preoccupato dell'effetto della documentazione di contentFetcher.DownloadNote(note, manual : true); , puoi sempre scrivere qualcosa come contentFetcher.DownloadNote(note, /* manual */ true); , quindi non è nemmeno molto utile nella documentazione.

Penso che questo sia il problema di rendere il codice errato più leggibile, piuttosto che "best practice".

Avere un metodo (o un appaltatore) che richiede 20 parametri è un "cattivo odore" ed è probabile che sia dovuto a un problema nel progetto. Tuttavia, se sono costretto a lavorare sul codice quando i metodi richiedono molti parametri, il parametro named rende il codice meno difficile da capire.

Quando i metodi hanno solo 1 o 2 parametri ed è chiaro dal nome del metodo qual è il parametro, quindi il parametro named non aggiunge nulla. Questo è il caso ideale per essere dentro

Se tutto il codice su cui lavori è scritto come il libro " codice pulito ", allora ho pochissimo uso per i parametri nominati, tuttavia viviamo nel mondo reale.

Sono d'accordo che aggiungere il nome del parametro lo rende più leggibile. Tuttavia, la maggior parte dei libri che ho letto sembrano considerare gli switch booleani come una cattiva pratica. A volte faccio questo:

public Content DownloadNote(Note note)
{
    return downloadNote(note, manual: false);
}

public Content DownloadNoteManually(Note note)
{
    return downloadNote(note, manual: true);
}

Questo ti dà maggiore flessibilità quando implementi la tua API. Ti permette anche di controllare il caso in cui hai più switch booleani, ma non tutti possono essere attivi contemporaneamente.

Sono un grande sostenitore dei parametri con nome in situazioni in cui i tipi e la semantica non sono chiari dal nome del metodo. La mia esperienza è che poche persone leggono la documentazione.

Detto questo, i parametri nominati non dovrebbero essere un'alternativa alla creazione di liste di argomenti sensate, usando oggetti helper (per "legare" insieme argomenti semanticamente correlati) e usando enumerazioni laddove rilevanti.

Penso che questo sia più utile nei linguaggi non OO, dove potresti avere una funzione che deve fare qualcosa in diversi modi leggermente diversi, e il modo in cui determina cosa fare è basato sui valori dei parametri. Nel mondo OOP, dovremmo semplicemente sovraccaricare la funzione, ma quando ciò non è possibile, si finisce per passare un gruppo di flag (o un gruppo di valori, e se sono passati o meno è la bandiera).

Penso che sia più leggibile, in una certa misura; ma come altri hanno già detto, avere molti parametri è un odore di codice, quindi non vedo un sacco di utilizzo per questo in un linguaggio orientato agli oggetti come C #.