Denominazione del metodo con un parametro out

Per C # è sufficiente esaminare le convenzioni già in uso all'interno del framework .NET, in particolare i vari metodi Parse e TryParse .

Il metodo int.Parse(string) genera un FormatException se passi una stringa che non può essere analizzata in un numero intero a 32 bit.

Il metodo bool int.TryParse(string, out int) restituisce false per ogni input che genera un'eccezione quando viene passato al metodo int.Parse(string) .

Se il tuo caso d'uso non rientra in questi limiti, non è necessario utilizzare questo modello e in effetti potresti confondere altri sviluppatori .NET che sono già abituati a questo modello.

Se Find qualcosa, dovrebbe generare un'eccezione o restituire null quando la cosa non viene trovata? Anche questo dipende dal caso d'uso.

Se provi a trovare una chiave in un dizionario e non ci sono elementi con quella chiave, ha senso lanciare un'eccezione.

Se si tenta di trovare un record nel database, in cui il codice non ha lo stesso livello di controllo di un oggetto Dizionario, il lancio di un'eccezione si verificherà più spesso. Risolvi eccezioni per condizioni davvero eccezionali (ad esempio, cose che non accadono spesso e il tuo codice non può recuperare da).

Se stai cercando di trovare un record da un database o da una sorta di archivio dati, direi che è più idiota restituire un valore nullo che generare un'eccezione. Se sei davvero preoccupato di come altri programmatori potrebbero interpretare un puntatore nullo, quindi avvolgilo in un altro oggetto che ha una proprietà booleana che determina se è stato trovato o meno qualcosa.

Un metodo "trova" su un oggetto di accesso ai dati che restituisce un puntatore nullo non è mai stato un mistero per me, nemmeno come programmatore principiante. Ho sempre saputo che significava "la cosa che hai cercato di trovare non è stata trovata".

Capisco che stia tentando di seguire una convenzione utilizzando un metodo TryXXX , simile a TryParse . Vale la pena notare, tuttavia, che le versioni CLR dei metodi TryXXX operano tutti su tipi di valore. Se il metodo in questione restituisce un tipo di riferimento, puoi rinunciare al valore di ritorno bool e al parametro out , e invece restituire un riferimento null se non trovato.

Così invece di

public bool TryFindItemNameInNameDomain(out string itemName)

Potresti usare

public string FindItemNameInNameDomain()

Detto questo, potresti essere in grado di migliorare ulteriormente le cose con un concetto separato di NameDomain, ad es.

class NameDomain
{
    public string FindItemName()
    {
    }
}

Quindi il chiamante dovrebbe scrivere

var itemName = this.NameDomain.FindItemName();

La domanda qui non riguarda la ricerca di qualcosa che dovrebbe o non deve generare un'eccezione o restituire null, si tratta di come denominare i metodi.

Era così che gli IDE non erano davvero una cosa. Questo ha reso tutto ok, ad esempio includere il tipo restituito nei nomi dei metodi (per lo sviluppatore ricordare cosa sta per fare). Avresti qualcosa di simile

public string StringFindItemNameInDomain() 

Potresti anche includere informazioni pubbliche / private. Credo, ma non citarmi su questo, che è ancora pratica comune in c ++ far precedere i nomi dei membri privati con m_. Oggi tieni il mouse su una chiamata al metodo e ottieni tutte le informazioni di cui hai bisogno. L'accesso, il tipo di ritorno e i parametri.

Il problema che stai avendo riguarda l'ottimizzazione / la ridondanza. Vuoi ottimizzare il tuo nome del metodo per la leggibilità, ma non vuoi avere ridondanze.

Questo si collega alle funzioni di passaggio del mouse dell'IDE perché se vedo una chiamata come

TryFindInDomain(out somestring);

Alzo il mouse sopra di esso e noto il parametro itemName, ora so cosa fa. Tuttavia quando vedo una chiamata a

TryFindItemNameInDomain(out somestring);

Non ho bisogno di fluttuare, posso leggerlo così com'è. Penso che sia una questione di gusto / stile.

Tuttavia, potremmo provare a trovare anche altre cose nel dominio. Questo è dove diventa interessante. Se un tipo in C # lo supporta, il metodo viene sempre chiamato TryParse / Parse. Ho solo bisogno di sapere dell'esistenza di questi 2 metodi.

Se aggiungi un altro metodo al nostro esempio attuale come

public bool TryFindCarInDomain(out Car car) 

Ora ho bisogno di sapere che ci sono 2 metodi.

Se rifatto questi metodi a questo:

public bool TryFindInDomain(out string itemName) 
public bool TryFindInDomain(out Car car)

Il compilatore si prende cura dei tipi, ho solo bisogno di sapere circa 1 firma del metodo che posso usare per trovare roba di alcuni tipi. Se mai dovessi trovare il tipo x lì dentro, ci provo. Se il compilatore mi dice che il tipo non è disponibile, aggiungo un altro metodo per il tipo x.

Quindi, a mio parere, è meglio non includere itemName nella firma.

Nell'app funzionalmente orientata, ogni metodo vive in un contesto della sua classe. La classe in un contesto del suo spazio dei nomi. La catena di spazi dei nomi + nome classe + nome metodo formano una frase che spiega la funzionalità offerta. Questo vale anche per i parametri del metodo. I nomi relativi alla tecnologia, se necessario, appaiono alla fine della catena del contesto. Per es.

Spreadsheet.NumbersExporter.TryWrite( NumbersRow row, out NumbersSheet numbersSheet )

Nei documenti API vediamo le firme complete. I buoni IDE mostrano i nomi dei parametri in linea con le chiamate di un metodo. Le informazioni sono visibili.

Lavorare con il contesto può essere visto come uno strumento per gestire i nomi ridondanti. Alcuni ingegneri, tuttavia, si sentono meglio con la ripetizione dei nomi "in" o "out" nel nome del metodo. Il fatto è che scriviamo codice per i nostri colleghi, in modo che possano capire rapidamente di andare avanti.