Convenzione di denominazione C # per enum e proprietà di corrispondenza

Spesso mi trovo a implementare una classe che mantiene una sorta di proprietà status come enum: ho una proprietà Status enum e ONE Status di tipo Status. Come dovrei risolvere questo conflitto di nomi?

public class Car
{
  public enum Status
  {
    Off,
    Starting,
    Moving
  };

  Status status = Status.Off;

  public Status Status // <===== Won't compile =====
  {
    get { return status; }
    set { status = value; DoSomething(); }
  }
}

Se l'enumerazione dello stato fosse comune a tipi diversi, lo metterei fuori dalla classe e il problema sarebbe risolto. Ma Status si applica solo a Car, quindi non ha senso dichiarare l'enumerazione al di fuori della classe.

Quale convenzione di denominazione usi in questo caso?

NB: Questa domanda è stata parzialmente discussa nei commenti di una risposta a questa domanda . Dato che non era la domanda principale , non ha avuto molta visibilità.

EDIT: Filip Ekberg suggerisce un'eccellente soluzione alternativa IMO per il caso specifico di "Status". Tuttavia, sarebbe interessante leggere le soluzioni in cui il nome dell'enumerazione / proprietà è diverso, come nella risposta di Michael Prewecki .

EDIT2 (maggio 2010): la mia soluzione preferita è quella di pluralizzare il nome del tipo di enumerazione, come suggerito da Chris S. Secondo le linee guida MS, questo dovrebbe essere usato solo per le enumerazioni flag. Ma mi piace sempre di più. Ora lo uso anche per enumerazioni regolari.

Aggiungerò il mio 1 euro alla discussione ma probabilmente non aggiungerò nulla di nuovo.

La soluzione più ovvia è spostare Status fuori dall'essere un Enum annidato. La maggior parte delle enumerazioni .NET (tranne forse alcune nello spazio dei nomi Windows.Forms) non sono nidificate e ne rende fastidioso l'utilizzo per lo sviluppatore che utilizza l'API, dovendo anteporre il nome della classe.

Una cosa che non è stata menzionata è che le enumerazioni dei flag secondo le linee guida MSDN dovrebbero essere sostantivi pluralizzati che probabilmente già conosci (lo stato è un enum semplice, quindi i nomi singolari dovrebbero essere usati).

State (enum chiamato States) è il vocativo, "Status" è il nominativo di un sostantivo che l'inglese come la maggior parte della nostra lingua ha assorbito dal latino. Vocativo è ciò che chiami un sostantivo per la sua condizione e nominativo è il soggetto del verbo.

Quindi, in altre parole, quando l'auto è in movimento , questo è il verbo: muoversi è il suo status. Ma l'auto non si spegne, il suo motore sì. Né si avvia, il motore sì (probabilmente hai scelto un esempio qui, quindi potrebbe essere irrilevante).

public class Car
{
  VehicleState _vehicleState= VehicleState.Stationary;

  public VehicleState VehicleState 
  {
    get { return _vehicleState; }
    set { _vehicleState = value; DoSomething(); }
  }
}

public enum VehicleState
{
    Stationary, Idle, Moving
}

Stato è un nome così generalizzato, non sarebbe meglio descrivere a quale stato si riferisce? Come ho fatto sopra

L'esempio di tipo anche a mio avviso non si riferisce al tipo di lettore, ma al suo database. Lo preferirei se descrivessi il prodotto del database del lettore che non è necessariamente rilevante per il tipo di lettore (ad esempio, il tipo di lettore potrebbe essere solo in avanti, in cache e così via). Così

reader.Database = Databases.Oracle;

In realtà questo non accade mai poiché sono implementati come driver e una catena di ereditarietà invece di utilizzare enumerazioni, motivo per cui la riga sopra non sembra naturale.

La definizione di "Off", "Starting" e "Moving" è ciò che chiamerei uno "Stato". E quando stai insinuando che stai usando uno "Stato", è il tuo "Stato". Così!

public class Car
{
  public enum State
  {
    Off,
    Starting,
    Moving
  };

  State state = State.Off;

  public State Status
  {
    get { return state ; }
    set { state= value; DoSomething(); }
  }
}

Se prendiamo un altro esempio da quello indicato in cui desideri utilizzare la parola "Tipo", in questo caso:

public class DataReader
{
    public enum Type
    {
        Sql,
        Oracle,
        OleDb
    }

    public Type Type { get; set; } // <===== Won't compile =====

}

Hai davvero bisogno di vedere che c'è una differenza tra enumerazioni ed enumerazioni, giusto? Ma quando crei un framework o parli di architettura devi concentrarti sulle somiglianze, ok cerchiamole:

Quando qualcosa è impostato su uno Stato, viene definito come lo Stato delle "cose"

Esempio: lo stato dell'auto è in stato di marcia, stato fermo e così via.

Quello che vuoi ottenere nel secondo esempio è in qualche modo questo:

myDataReader.Type = DataReader.Database.OleDb

Potresti pensare che questo dica contro ciò che ho predicato agli altri, che devi seguire uno standard. Ma stai seguendo uno standard! Il caso Sql è anche un caso specifico e quindi necessita di una soluzione un po 'specifica.

Tuttavia, l'enumerazione sarebbe riutilizzabile all'interno del tuo file System.Data spazio, ed è di questo che si tratta.

Un altro caso da considerare con il "Tipo" è "Animale" dove Tipo definisce la specie.

public class Animal
    {
        public enum Type
        {
            Mammal,
            Reptile,
            JonSkeet
        }

        public Type Species{ get; set; }

    }

Questo sta seguendo uno schema, non hai bisogno di "conoscere" specificatamente l'Oggetto per questo e non stai specificando "AnimalType" o "DataReaderType", puoi riutilizzare le enumerazioni nel tuo spazio dei nomi preferito.

Penso che il vero problema qui sia che l'enum Status è incapsulato all'interno della tua classe, in modo che Car.Statussia ambiguo sia per la proprietà Statusche per l'enumStatus

Meglio ancora, metti il ​​tuo enum fuori dalla classe:

public enum Status
{
    Off,
    Starting,
    Moving
}

public class Car
{
    public Status Status
    { ... }
}

AGGIORNARE

A causa dei commenti qui sotto, spiegherò il mio design sopra.

Sono uno che non crede che enumerazioni o classi o qualsiasi altro oggetto debba risiedere all'interno di un'altra classe, a meno che non sia totalmente privato all'interno di quella classe. Prendi l'esempio sopra, ad esempio:

public class Car
{
    public enum Status
    {...}
    ...
    public Status CarStatus { get; set;}
}

Mentre alcuni commentatori sostengono che Stato non ha alcun significato al di fuori del campo di applicazione della classe Car, il fatto che si sta impostando un pubblico mezzi di proprietà che ci sono altre parti del programma che farà l'uso che enum:

public Car myCar = new Car();
myCar.CarStatus = Car.Status.Off;

E questo per me è un odore di codice. Se guarderò a quello stato al di fuori di Car, potrei anche definirlo al di fuori .

Come tale, probabilmente lo rinominerò come:

public enum CarStatus
{...}

public class Car
{
    ...
    public CarStatus Status { get; set; }
}

Tuttavia, se tale enumerazione verrà utilizzata all'interno e solo all'interno della classe auto, allora mi va bene dichiarare l'enumerazione lì.

So che il mio suggerimento va contro le convenzioni di denominazione .NET, ma personalmente prefisso le enumerazioni con "E" e le enumerazioni con "F" (simile a come prefisso Interfacce con "I"). Davvero non capisco perché questa non sia la convenzione. Le enumerazioni / flag sono un caso speciale come le interfacce che non cambieranno mai il loro tipo. Non solo rende chiaro di cosa si tratta, è molto facile digitare intellisense poiché il prefisso filtrerà la maggior parte degli altri tipi / variabili / ecc. E non avrai questi conflitti di denominazione.

E ciò risolverebbe anche un altro problema in cui per esempi in WPF si usano classi statiche come enumerazioni (ad esempio FontWeights) che hanno istanze di tipi predefinite ma non lo sapresti se non le cerchi. Se li precedessero semplicemente con "E", tutto ciò che dovresti fare è digitare sul carattere per trovare queste classi statiche speciali.

Al diavolo chi odia la notazione ungherese e le sue varianti. Uso una convenzione di suffisso delle enumerazioni con - aspetta - Enum. Di conseguenza non ho mai il problema che descrivi, perdo tempo a preoccuparmi di come chiamarli e il codice è leggibile e auto-descrittivo per l'avvio.

public class Car
{
  public enum StatusEnum
  {
    Off,
    Starting,
    Moving
  };

  public StatusEnum Status { get; set; }

}

Modificherei il nome della proprietà in qualcosa come "CurrentStatus". Veloce e facile :)

Suggerisco di aggiungere "Opzione" al nome del tipo (o Flag se contiene flag di bit), cioè il tipo è Car.StatusOption e la proprietà è Car.Status.

Rispetto al pluralismo, questo evita le collisioni di denominazione quando si creano raccolte del tipo enum, dove normalmente si desidera pluralizzare la proprietà della raccolta , non il tipo enum .

Di solito ho prefisso le enumerazioni, ad esempio CarStatus. Suppongo che tutto dipenda dal team con cui lavori (se hanno regole / processi per quel genere di cose) e dall'utilizzo degli oggetti. Solo i miei 2 centesimi (: