How can I use or name constants for response type fields?

Question

There are situations in which we have fields that represent a type of response, whether boolean responses sim and não, S and N or with multiple responses like the status of something. For example the status of a course certificate analysis provided by some institution:

1. Certificate yes S
2. Certificate not N
3. Certificate in analysis A

Considering the above context, the use of constant can be adopted to facilitate the reading of the code.

Now see a real example of the class Instituicao which has response type fields in which it is using constants for them:

public class Instituicao
{
    public static string DeletadoSim { get; } = "S";
    public static string DeletadoNao { get; } = "N";
    public static string AtivaSim { get; } = "S";
    public static string AtivaNao { get; } = "N";
    public static string CertificadoDisponivel { get; } = "S";
    public static string CertificadoNaoDisponivel { get; } = "N";
    public static string CertificadoEmAnalise { get; } = "A";

    public int Id { get; set; }
    public string RazaoSocial { get; set; }
    public string UrlSite { get; set; }
    public string Ativa { get; set; } = AtivaSim;
    public string TemCertificadoGratuito { get; set; }
    public string Deletado { get; set; } = DeletadoNao;
    public DateTime DataCadastro { get; set; }
    public List<Curso> Cursos { get; set; }
}

Therefore, the scenario that was illustrated above left me with doubts regarding the appointment and creation of constants.

Doubts

1. In cases like this, should we use constants? Is there another alternative? If yes, which?
2. In the case of constants, how could I name them in order to avoid prolixity, redundancy or anything that does not leave the code clean for response type fields?

Answer 1

In such cases, should we use constants? Is there another alternative? If so, which?

I’m not really a fan of this. It seems Zero = 0 or Um = 1. If they are constant even why not put them as constants?

public const string DeletadoSim = "S";
public const string DeletadoNao = "N";
public const string AtivaSim = "S";
public const string AtivaNao = "N";
public const string CertificadoDisponivel = "S";
public const string CertificadoNaoDisponivel = "N";
public const string CertificadoEmAnalise = "A";

In the case of constants, how could I name them in order to avoid prolixity, redundancy or anything that does not leave the code clean for response type fields?

Again, it seems so unnecessary...

If you’re gonna do it like that, enum which is a constants made for it. It increases verbosity, but if it is to give legibility...

public enum Deletado { [Display("N")]Nao, [Display("S")]Sim }
public enum Certificado { [Display("N")]NaoDisponivel, [Display("S")]Disponivel, [Display("A")]EmAnalise }

Using:

public Deletado Deletado { get; set; } = Deletado.Nao;

I put in the Github for future reference.

Obviously if you need the value with text you will have to deal with this, probably with a proper function, gives more work. But I find all this exaggerated same.

Pity the enum not allow string as the underlying type (do not use a numerical type as the enumeration type).

read more about the most correct semantics for enum in An enumeration must be constant in the lifetime of the solution?. For everything has an exception. We are talking about something that is complicated to deal with when it involves versioning. So I’m critical of some methodologies that preach doing what you need to do and then find a solution if something goes wrong. Hint: almost all that are used nowadays preach this, even if some deny.

As for the name, there’s not much to do Sim and Nao in the constant, but loses readability.

Can help: Constant is really useful?.

Answer 2

In such cases, we should use constants?

I don’t think so. "Constants are fields whose values are defined at compile time and can never be changed.".

An example of constant is PI, where whenever you need it, you know what to call Math.PI will have the necessary value.

In your specific case, the name of the constant is being more significant than its own value.

Is there another alternative? If so, which?

Yes. Some situations seem to be solved only with bool: is Active or Inactive; Deleted, or not. (This point could also be solved with Enum, because I understand that Whether Active or Inactive is Not Deleted, and if Deleted is not Active or Inactive...)

Solving with Enum:

"An enumeration type (also called an enumeration or Enum) provides an efficient way to define a set of named integral constants that can be assigned to a value"

Your code would look like this:

public enum StatusCertificados
{
     Disponivel,
     NaoDisponivel,
     EmAnalise
}

public enum StatusInstituicoes
{
     Ativo,
     Inativo,
     Deletado
}

public class Instituicao
{
    public int Id { get; set; }
    //...
    public StatusInstituicoes Status {get;set;}
    public StatusCertificados CertificadoStatus {get;set;}
    //...
}

In the object:

Instituicao obj = new Instituicao();
obj.CertificadoStatus = StatusCertificados.EmAnalise;
obj.Status = StatusInstituicoes.Ativo;

//...


if (obj.Status == StatusInstituicoes.Ativo)
{
 //...
}

//...


if (obj.CertificadoStatus == StatusCertificados.Disponivel)
{
 //...
}

---

This list of values (Available/Not Available/Analyzed) seems to me to be a requirement of the project. A problem is if this list has to be changed:

Certificate: Valid / Expired / Revoked

Perhaps it was the case to create it with all possible values.

Worth reading about Enum: /a/22575/69359

Answer 3

Constants

These are fields that cannot be changed, and function only as reading variables.

Example

public const double PI = 3,14;

The use of Enum is usually used when it comes to closed response options for example

public  enum Opcao {Sim, Nao}

class resposta
{
    public Opcao Delegado { get; set; }

    public resposta()
    {
        Delegado = Opcao.Nao;
    }
}

This way limits the options so as not to cause typos. Can be used for example for positions too.