Risposta breve: No

Risposta lunga: No, i nomi vaghi sono molto meno conservabili dei nomi precisi. Non cambierai il nome delle cose su base settimanale (e se lo fai, dovresti chiederti "Qual è la ragione di questo"). Cambiare il tipo di risultato è un cambiamento piuttosto grande, quindi se dovessi ottenere un detailProxyBroker invece del vero accountDetails sarebbe abbastanza semplice sapere che a prima vista ...

Sii preciso quanto necessario, così tu (o qualsiasi estraneo casuale che si unisce alla tua squadra) puoi leggere & capisci il codice.

Avrei difficoltà a immaginare che cosa var result ottengo da mediator.Send(query).Result;

var accountDetails che ottengo da mediator.Send(accountFilter).Result; è molto più facile da capire. Non è necessario includere nel nome della variabile che l'accountDetails contenga Nome, Compleanno e colore preferito: si tratta di troppi dettagli.

Heck, se non hai bisogno di cambiare i nomi è il tuo obiettivo chiamalo var a = b.Send(c).Result; puoi riempire quello che vuoi in a , b e c ...: /

Quindi, per concludere, usa la variante (2) - il tuo collega (e tu stesso) sarà contento di avere (quasi) codice di auto-documentazione, quando hai bisogno di lavorare di nuovo con quel pezzo di codice in X settimane .

IMHO la maggior parte dei tuoi argomenti "pro" sono difettosi, ma discutiamoli uno per uno:

If the query needs to change and return a different type, we don't have to remember to rename the result variable.

Se la query restituisce un tipo diverso in modo che un nome come accountDetails non si adatti più, il codice dipendente da tale variabile dovrà essere modificato, anche se il nome della variabile è solo result . Questo è decisamente più semplice (e quindi meno incline agli errori) quando la variabile ha un nome specifico. L'unica eccezione qui è IMHO quando non esiste tale codice, come in una funzione in cui result è appena restituita al chiamante.

That also means code reviews won't be polluted with a bunch of files that have changed due to the renaming.

Se inizi a litigare in questo modo, non dovresti mai rinominare alcuna variabile nel tuo codice, indipendentemente da quanto sia stato scelto male il nome, solo per rendere più efficaci le revisioni del codice. Forse non dovresti mai fare nessun refactoring? Ma non stupirti quando la qualità del tuo codice degrada ogni giorno.

Inoltre, nel tuo esempio, result ha l'aspetto di una variabile locale, quindi il refactoring di solito non ha effetto su più di un file.

The job of a Web API controller isn't to know the details about what business logic is going on; it's just to invoke something and return it.

Se var result = mediator.Send(query).Result; è una parte di codice generica e riutilizzabile, che elabora query di tipi diversi e forse restituisce cose diverse, allora questa linea va bene. Tuttavia, se questa fosse la tua situazione, probabilmente non avresti fatto la domanda in primo luogo. Suppongo che in questo caso la query sia sempre un accountFilter , e il risultato è sempre un accountDetails , e finché ciò è vero, i nomi delle variabili dovrebbero esprimerlo.

Naturalmente, come ho scritto sopra, se la riga successiva nella tua funzione è solo return result; , il nome non specifico è ok.

If you really want to know what the line of code is doing, you can look at the context surrounding it.

Sul serio? Volete un altro programmatore di manutenzione per decifrare il contesto circostante per capire cosa sta succedendo, mentre selezionando semplicemente un nome migliore potrebbe salvarlo mezz'ora di lavoro cerebrale? Siate consapevoli che in sei mesi voi potrebbe essere il programmatore di manutenzione per questa linea di codice e vi sembrerà come se qualcun altro l'avesse scritto in primo luogo. Cosa preferiresti in quella situazione? Un nome di variabile che ti dice cosa rappresenta, o uno per il quale devi prima analizzare il codice per essere sicuro di cosa fa?

Quindi, ad eccezione dei casi molto semplicistici in cui l'intera funzione appare come

 AccountDetails GetAccountDetails(Query query)
 {
    var result = mediator.Send(query).Result;
    return result;
 }

probabilmente starai meglio ad usare un nome più specifico (anche se, anche per una funzione così semplice, un nome di parametro come accountFilter anziché query aumenterà pesantemente la leggibilità, e in questo esempio, result parametro è abbastanza inutile, in genere preferirei scrivere return mediator.Send(accountFilter).Result ).

In generale, dovresti preferire nomi descrittivi. Ma, se il metodo / funzione di contenimento è breve (un paio di righe), ben chiamato, e se è chiaro che cosa restituisce, quindi nominare la variabile "risultato" non è davvero un problema.

Tuttavia, poiché il metodo / funzione diventa più grande e più complesso, utilizzando un nome generico non descrittivo, diventa sempre più problematico.

The job of a Web API controller isn't to know the details about what business logic is going on; it's just to invoke something and return it.

Bene ... il nome della variabile dovrebbe indicare ciò che l'oggetto / valore ottenuto rappresenta nel contesto del codice circostante. Se il nome del metodo di contenimento è qualcosa come GetAccountDetails, il tuo argomento non si applica realmente e il nome "accountDetails" è perfetto - ma , se ritieni ancora che il controller sappia dettagli di implementazione non dovrebbe, quindi le tue astrazioni nel livello della logica di bussiness potrebbero essere un po 'spente.

I nomi vaghi sono più mantenibili?

No. Può darsi che non ci siano ulteriori informazioni utili da trasmettere, ma che invece richieda un nome generico . Non confondere tutti senza dire quello che intendi.

I nomi generici sono più mantenibili?

Depends. È quel nome generico che trasmette tutto ciò che è importante, o ci sono più informazioni utili che potresti inserire nel nome senza diventare troppo prolisso o addirittura ripetitivo?

I nomi specifici sono più mantenibili?

Depends. Non essere eccessivamente specifico o ripetitivo.

Come sempre, il contesto è il re.

Riproduzione del difensore del diavolo in una certa misura, ma consideriamo il seguente codice:

public List<Model> getModelsByTypeId(string modelTypeId)
{
    var result = new List<Model>();
    var dataset = myloverlysqlhelper(this.sqlForGettingModels, modelTypeId);
    //loop dataset and populate result...
    return result;
}

Qui ho usato nomi di variabili "generici" invece di dire modelResult e modelDataset e il significato è reso completamente chiaro dal contesto.

Posso copiare e incollare il codice in una dozzina di altre funzioni simili e non dover modificare il nome in ciascuna.

Ma! anche qui sto ancora usando modelTypeId invece di id o qualche altro nome generico. Potresti affermare che il nome della funzione ti offre un contesto sufficiente che id è giustificabile, ma potresti mai mettere queryParameter ? no, non avrebbe assolutamente senso.

Quindi, in sintesi, sì, il contesto ti consente di essere un po 'generico, non vuoi avere for(var integerWhichIAmCountingUpTo10 = 0;.... , ma generalmente è utile una piccola descrizione in più.

La mia risposta dipenderebbe dalla complessità del codice.

Ho usato result , ma generalmente in contesti in cui il codice è semplice e / o la vita della variabile è breve.

Se il codice è complesso (che suona come non è in questo caso), i nomi variabili vaghi rendono più difficile per il lettore capire il codice perché devono sprecare un sovraccarico cognitivo nel ricordare quale sia effettivamente la variabile.