Nomi di funzioni - prefissi "standardizzati"

Ci sono molte convenzioni possibili: spesso ho delle routine che fanno qualcosa e altre routine che controllano le cose e poi, alla fine, lo faccio o no. Invocobilmente chiamiamo questi frobWidgets() e maybeFrobWidgets() . Esistono altri prefissi che si adatterebbero, ad es. ensure è spesso usato per il codice che inizializza qualcosa pigramente, ma non esiste una convenzione universale. Non è necessario, però. Molto più importante della coerenza percepita con lo "stato dell'arte" è effettiva consistenza all'interno del codice base. Quindi, prosegui con checkAndFrob() rispetto a frob() se hai già iniziato a farlo.

Se ho una funzione che potrebbe non riuscire - come creare una directory, scrivere su un file, ecc. - Io uso la seguente firma:

bool TryDoSomething(string someParam)

Quindi il metodo farà qualcosa con someParam . Se ha successo, restituisce true; allo stesso modo, se non ha successo, restituisce false.

I parametri del metodo ovviamente non sono sempre necessari. C'è un altro vantaggio di questa firma del metodo in quanto non è necessario lanciare eccezioni sopra questo metodo a meno che non si ritenga fatale. Si noti che questo metodo può essere utilizzato anche per restituire valori di out . Fai riferimento al metodo del dizionario C # TryGetValue(...) .

Ho anche assegnato un nome alle funzioni che convalidano i dati come SomeParamIsValid(string SomeParam) . In questo modo, posso scrivere qualcosa come:

if (SomeParamIsValid(someParam) {
   if(!TryDoSomething(someParam, out SomeObject someObj) {
      // handle failed operation
   }

   return someObj;
}

Questo è un codice molto leggibile e facilmente gestibile, secondo me.

Solitamente i nomi delle funzioni dovrebbero essere più lunghi quando l'ambito delle funzioni è più breve (per esempio i metodi privati) e più breve il nome quando le funzioni sono pubbliche con un ambito più lungo.

Nel tuo caso, di solito faccio qualcosa del genere: createDir ($ path) e fallisco con un brutto errore; oppure tryCreatingDir ($ path) e rilevare l'errore e continuare con una decisione interna come lanciare un bel messaggio di errore o se la directory esiste già sopprimere tutti gli errori e uscire normalmente.

Questo non inquina la denominazione ma fa una differenziazione. Anche l'esplicito messaggio di eccezioni user friendly è sufficiente per tutti i casi eccezionali.

A volte lo inverto e uso createDir () per verificare la presenza di elementi e il secondo metodo sarebbe doCreateDir () e lo chiamerei SOLO se tutte le condizioni sono soddisfatte per creare la directory.

Non prefissi, ma caso. Prendi in considerazione l'utilizzo di TurgidCapitalCaseNames() per le funzioni 'supponenti' e brief_lower() per le funzioni di base 'raw'.

Questo presume che tu possa separare la tua applicazione in parti "grezzi" e "supponenti". Un po 'come quello che Linux chiama politica / meccanismo. Quindi, la tua domanda su dove mettere la decisione funziona per soddisfare le precondizioni risponde a se stessa: nelle funzioni supponenti.

    error_type  mkdir_and_parents(string path);
    Dir         MakeAnEmptyOutputDirectory(string subdir);

Il mix di casi di identificazione come questo disgusta alcune persone, ma potrebbe funzionare per te?

Per 'supponenti', intendo le funzioni che sarebbero:

• cock-sure : illuso con l'indiscutibile raggiungibilità dell'obiettivo
• espediente : prendere scorciatoie per il successo, ad es. riuscire silenziosamente se la directory esiste già
• precoce : acquisire le risorse necessarie senza pensarci due volte, allocare memoria, creare directory madri
• testardo : ad es. riprovare mentre il sistema risponde con 'filesystem full'
• robusto : ottiene le cose fatte; potrebbe registrare gli avvisi quando qualcun altro è in errore, ma probabilmente ha una risposta di fallback

Le tue funzioni "raw" potrebbero essere esattamente l'opposto:

• sottomesso : non fare nulla se non richiesto, e quando richiesto, fai solo questo
• leaky : non tentare di coprire l'orrore, se qualcosa va storto; Problema acuto a mano a qualcun altro
• umile : non assume alcun controllo su nessuna risorsa non espressamente fornita
• semplice : conosce solo una gamma molto piccola di cose

Dubito che ci sia molto di mezzo. Sarebbe un terreno molto confuso.

A parte questo, penso che il codice interno del sottosistema e le interfacce di sistema siano di solito "grezzi". D'altra parte ho trovato che la maggior parte del codice di "risposta agli eventi" rivolta al cliente è di solito molto ponderata: ad es. Gestori di comandi chiave, visualizzatori di rendering, generatori di report, compiti cron.

Tale correlazione potrebbe essere dovuta al fatto che è più importante che parti del sistema rivolte al mondo raggiungano un qualcosa solido invece di un niente fragile. Forse riflette le esigenze e le aspettative approssimative dell'utente o dell'utente, rispetto alle esigenze di ingegnere-artigiano conservatore e attento ai dettagli per affrontare la complessità e diagnosticare i guasti.

Ho scelto:

createDirectory(param)
chkDirectoryExists(param)

Se questi sono ambigui, cioè se ci fossero due diversi tipi di directory, avrei diviso l'oggetto in due, che entrambi implementerebbero un'interfaccia chiamata qualcosa come DirectoryHandler.