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

Posted on

Question :

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

  • Certificate yes S
  • Certificate not N
  • Certificate in analysis A
  • Considering the above context, the use of constant can be adopted to make it easier to read the code.

    Now see a real example of the Instituicao class that has answer-type fields in which you are 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; }

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


  • In such cases, should we use constants? Is there another alternative?
    If so, which ones?
  • In 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 :


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

    I was not much of a fan of this. It looks like Zero = 0 or Um = 1 . If they are constants 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 redundancy, redundancy or anything that does not leave the code clean for response type fields?

    Again, it seems so unnecessary …

    If it’s to do so, I’d rather even use a enum which is a constants made for this. Increases verbosity, but if it is to give readability …

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


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

    I placed GitHub for future reference .

    Obviously if you need the value with text you will have to deal with it, probably with a own function , give more job. But I think all this really exaggerated.

    Pen enum does not allow string as the underlying type (do not use numeric type as enumeration type).

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

    As for the name, you do not have much to do, you can leave only Sim and Nao in the constant, but it loses readability.

    It can help: Constant is it really useful? .



    In such cases, should we use constants?

    I do not think so. “Constants are fields whose values are defined at compile time and can never be changed. “.

    An example of a constant is PI, wherever you need it, you know that calling Math.PI will have the required value.

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


    Is there another alternative? If so, which ones?

    Yes. Some situations seem to be solved only with bool: Active or Inactive; It has been deleted, or not. ( This point could also be resolved with enum, as I understand that If Active or Inactive is not Deleted, and if Deleted is not Active or Inactive …

    Resolving with enum :


    “An enumeration type (also called an enum or enumeration) provides an efficient way to define a set of named integer constants that can be assigned to a value”

    Your code looks like this:

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

    On 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 / In Analysis) seems to me to be a requirement of the project. One problem is if this list has to be changed:

    Certificate: Valid / Expired / Revoked

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


    Worth reading about enum: link



    These fields can not be changed, and they only work as read variables.


    public const double PI = 3,14;

    The use of enum is often used when it comes to closed response options such as

    public  enum Opcao {Sim, Nao}
    class resposta
        public Opcao Delegado { get; set; }
        public resposta()
            Delegado = Opcao.Nao;

    This limits the options so as not to cause typing errors.
    It can be used for example for positions too.


    Leave a Reply

    Your email address will not be published. Required fields are marked *