Argomenti (parametri) nominati come ausilio alla leggibilità

Molto tempo fa ho programmato molto in ADA ed era normale nominare argomenti quando si invocava una funzione - SomeObject.DoSomething (SomeParameterName => someValue);

Ora che C # supporta argomenti denominati, sto pensando di ripristinare questa abitudine in situazioni in cui potrebbe non essere ovvio cosa significhi un argomento.

Potresti sostenere che dovrebbe sempre essere ovvio cosa significhi un argomento, ma se hai un argomento booleano e i chiamanti stanno passando "vero" o "falso", qualificare il valore con il nome rende il sito di chiamata più leggibile.

contentFetcher.DownloadNote (nota, manuale: true);

Immagino di poter creare Enum invece di usare true o false (Manuale, Automatico in questo caso).

Cosa ne pensi di utilizzare occasionalmente argomenti con nome per rendere più facile la lettura del codice?

Ciò è stato suggerito nello sviluppo del C ++ e Stroustrup ne parla nel suo "Design and Evolution of C ++", pagine 153 e seguenti. La proposta era ben formata e si basava su precedenti esperienze con Ada. Non è stato adottato.

Il motivo principale era che nessuno voleva incoraggiare funzioni con un gran numero di parametri. Ogni funzione aggiuntiva in una lingua costa qualcosa e non si desiderava aggiungere una funzione per facilitare la scrittura di programmi errati.

Ha anche sollevato dubbi su quali fossero i nomi dei parametri canonici, in particolare nella solita convenzione di file di intestazione e 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 (sostituire i suffissi di file come desiderato). Richiedere che siano uguali comporterebbe un costo aggiuntivo per la compilazione e la confusione dei nomi tra i file di origine potrebbe causare bug sottili.

Può anche essere gestito utilizzando oggetti anziché chiamate di funzione. Invece di una chiamata GetWindow con una dozzina di parametri, crea una classe Window con una dozzina di variabili private e aggiungi setter come necessario. Incatenando i setter, è possibile scrivere qualcosa di simile my_window.SetColor(green).SetBorder(true).SetBorderSize(3);. È anche possibile avere funzioni diverse con impostazioni predefinite diverse che chiamano la funzione che svolge effettivamente il lavoro.

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

Penso che questo sia il problema di rendere più leggibile il cattivo codice, piuttosto che la "migliore pratica".

Avere un metodo (o appaltatore) che accetta 20 parametri è un "cattivo odore" ed è probabilmente dovuto a un problema nella progettazione. Tuttavia, se sono costretto a lavorare sul codice quando i metodi accettano molti parametri, allora il parametro denominato rende il codice meno difficile da capire.

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

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

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

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

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

Ciò ti offre maggiore flessibilità durante l'implementazione dell'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 nominati in situazioni in cui i tipi e la semantica non sono chiari dal nome del metodo. La mia esperienza è che poche persone hanno letto la documentazione.

Detto questo, i parametri nominati non dovrebbero essere un'alternativa alla creazione di elenchi di argomenti sensibili, utilizzando oggetti helper (per "legare" argomenti semanticamente correlati) e, se pertinente, utilizzare le enumerazioni.

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 si basa sui valori dei parametri. Nel mondo OOP, potremmo semplicemente sovraccaricare la funzione, ma quando ciò non è possibile, finisci per passare un gruppo di bandiere (o un gruppo di valori e se sono passate 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 molto uso di ciò in un linguaggio orientato agli oggetti come C #.