Question 385332 in PHP Question posted in
Official manual can be found here.

Php – Backed Enum Format?

I have a gender enum:

enum Gender: string
{
    use EnumToArray;

    case MALE = 'male';
    case FEMALE = 'female';
    case NON_BINARY = 'non-binary';
    case PREFER_NOT_TO_SAY = 'prefer not to say';

    public function label(): string
    {
        return match ($this) {
            self::MALE => 'Male',
            self::FEMALE => 'Female',
            self::NON_BINARY => 'Non-binary',
            self::PREFER_NOT_TO_SAY => 'Prefer Not To Say',
        };
    }
}

I have a label method that returns the user friendly label, for use in forms etc.

But with my backed enum values that are being stored in my database:

    case MALE = 'male';
    case FEMALE = 'female';
    case NON_BINARY = 'non-binary';
    case PREFER_NOT_TO_SAY = 'prefer not to say';

What should these values be? If using strings as I have done, is there a standard format, e.g. prefer_not_to_say or preferNotToSay?

Should strings be used at all? Should I use 0,1,2,3? Or should I just use letters m,f,n,x?

Tags:

2

Answers


  1. 0

    There isn’t any strict rule about name-backed enum values, we know they can be just scalar type values int or string, and they must be unique. As I see in the PHP libraries common use lowercase. for example:

    enum Sort: string
{
    case Ascending = 'asc';
    case Descending = 'desc';
}

    in my opinion, using spaces between them is not a good idea 'prefer not to say' )

    Login or Signup to reply.
  2. 0

    For a start, PHP enums do not require values at all:

    enum Gender
{
    case MALE;
    case FEMALE;
    case NON_BINARY;
    case PREFER_NOT_TO_SAY;

    public function label(): string
    {
        return match ($this) {
            self::MALE => 'Male',
            self::FEMALE => 'Female',
            self::NON_BINARY => 'Non-binary',
            self::PREFER_NOT_TO_SAY => 'Prefer Not To Say',
        };
    }
}

    Assigning values to enum cases adds maintenance burden and cognitive load, so it’s something that only makes sense when you actually need to map your enum to an external value: a URL parameter value, a database primary key, etc. Once there, if you have to add string or int values to your enum cases it’s because you already have such values coming from outside. In other words, the backed values themselves are really part of your application domain and they are basically given to you. Any additional decision you need to make does not really belong to the enumeration.

    Regarding code style… If you want to adhere to some major code style guide in order to be consistent, one possible option is PER Coding Style (the rolling version of PSR-12):

    Enum case declarations MUST use PascalCase capitalization

    enum Gender
{
    case Male;
    case Female;
    case NonBinary;
    case PreferNotToSay;
}

    Needless to say, there’s no right or wrong. Style is about consistency, not correctness.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search