Rappresentare uno stato come stringhe a lettera singola [duplicato]

Utilizza enum

Dal punto di vista del database, questo accoppiatore efficiente storage con valori significativi in query SQL e visualizzatori di database.

Sul lato C # questo trova errori di compilazione in fase di compilazione, migliora la sicurezza del tipo e dà accesso a funzionalità IDE come "Trova tutti i riferimenti".

Le stringhe di codifica hard possono a volte essere appropriate, ma non penso che questo sia uno di quei casi. Ad esempio, durante la scrittura di un parser, potrei scrivere delle stringhe hardcode che hanno un significato specifico nella grammatica. L'importante è specificare solo una stringa di questo tipo una volta, quando viene usata più spesso, estrarla in una costante.

Utilizza switch invece di if / else catena

Questo è esattamente il caso d'uso per cui è stato progettato switch . È un codice idiomatico e probabilmente più veloce per catene più lunghe.

Non supponiamo implicitamente che il caso predefinito sia l'ultimo valore possibile

Questo nasconde errori. Definisci invece un caso per tutti i tuoi valori e genera un'eccezione nel caso predefinito per rilevare i dati imprevisti.

Ricorda il principio della responsabilità unica

Assicurati di non mescolare preoccupazioni separate in un singolo campo. Non capisco completamente che tu usi il caso, ma potrebbe essere opportuno suddividere il campo in campi separati.

Scriverò qualcosa del genere:

switch(db.field)
{
    case OrderStatus.Deleted:
        ...
        break;
    case OrderStatus.Ignored:
        ...
        break;
    ...
    default:
        throw new NotSupportedException(string.Format("Unexpected OrderStatus '{0}'", db.field));
}

Sull'hardcoding delle costanti di stringa

I tried to stress the importance of NOT doing comparisons on hardcoded string values (and also enums). In my eyes against SQL best practises, is "smelly" code and so on.

Sai cosa è peggio di qualcosa di hardcoding? Rendere qualcosa "codificato in modo soft" / "configurabile" / "flessibile" quando è già codificato altrove. Quando lo fai, hai tutti gli svantaggi della flessibilità (flessibilità = più possibilità di errore) e nessuno dei vantaggi (perché in realtà non puoi cambiarlo comunque). Si finisce con un valore che sembra essere qualcosa che puoi cambiare quando in realtà deve essere impostato su uno e un solo valore per funzionare. Non serve a niente, e in effetti è di intralcio.

Quindi ti chiedo di pensare a due cose:

(1) Il software che inserisce questi record. È hardcoded? Quindi, inserisci il codice hard del software che lo legge.

(2) Il database. Quando si distribuisce il software, il database esiste già e contiene dati? Se sì, qualsiasi dato simbolico (come A / D / I) in quelle tabelle è buono come hardcoded, a meno che non si preveda di eseguire script di migrazione con le distribuzioni.

Secondo me, il confronto con una costante di stringa hardcoded non è solo perfetto in questa situazione, è il metodo go-to per gestirlo.

Eliminazione di quell'istruzione case

Ora, potresti avere un problema con l'istruzione case . Va bene. Puoi aggirare il problema con alcuni delegati, in questo modo:

//Declare our hardcoded values
const string OrderAdd = "A";
const string OrderDelete = "D";
const string OrderIgnore = "I";

//Initialize.  Add to static constructor somewhere.
var lookup = new Dictionary<string, Action<DataRow>);
lookup.Add(OrderAdd, ExecuteAddOrder);
lookup.Add(OrderDelete, ExecuteDeleteOrder);
lookup.Add(OrderIgnore, (DataRow) => {} );

//Handle a record
var code = dataRow["OrderAction"] as string;
if (!lookup.Exists(code)) throw new InvalidOperationException();
var action = lookup[code];
action(dataRow);

//Define handlers
void ExecuteAddOrder(DataRow sourceRecord)
{
    //Add order here
}

void ExecuteDeleteOrder(DataRow sourceRecord)
{
    //Delete order here
}

Anche se quanto sopra sembra interessante, in realtà non aggiunge il valore molto . Aggiunge un po '. A seconda del team, la diminuzione della leggibilità potrebbe non valerne la pena.

Durante la procrastinazione

A meno che tu non sia molto fortunato, non stai lavorando a un lavoro artistico. Stai lavorando a una soluzione pratica a un problema aziendale. In molti casi, la tempestività ha molto più valore aziendale dell'eleganza. Il tuo successo come ingegnere dipenderà molto dalla tua capacità di risolvere rapidamente problemi tecnici e praticamente . Venire con la soluzione perfetta un mese di ritardo non ti darà alcun credito extra di sorta.

Ricorda questo, e ricorda che tra un anno, non importa quanto sia bello il tuo codice, probabilmente lo guarderai e riderai.

La mia opinione su questi "stili di codifica" è che si tratta solo di uno "stile di codifica"

Chi scrive in realtà il particolare bit di codice in questione dovrebbe essere dotato di un considerevole modo per usare il proprio stile.

Questi argomenti tendono ad essere vinti dalla persona che è la più aggressiva e, indipendentemente da quanto tu sia giusto, porta solo ad un ambiente di lavoro cattivo in cui la sperimentazione e il flare vengono repressi.

Se hai un vero problema con codice errato, probabilmente ti mancano i requisiti per le tue attività. Spingi per ottenere aggiustamenti come la scalabilità e le prestazioni, in modo da avere un argomento legittimo in caso di problemi.