3
\$\begingroup\$

I'm re-designing the login functionality for our application, and the first thing I came across is something a previous developer wrote a while back. There's a simple Login class that just contains 2 strings, username and password, and an enum LoginStatus:

public enum LoginStatus
{
    LoggedIn,
    LoggedOut
}

I'm thinking it would be better to just use a bool here, but maybe there's something more here that I'm not understanding?

In my opinion, it is slower and more confusing to read:

if (login.LoginStatus == LoginStatus.LoggedIn) 
{
    ...
}

It would seem a lot better to just write:

if (login.loggedIn) { ... }

or

if (!login.loggedIn) { ... }

I already tested it in my branch and changed everything accordingly. Everything still works normally, so the new Login class looks like this:

public class Login
{
    public string username { get; set; }
    public string password { get; set; }
    public bool loggedIn { get; set; }
}

Is there any specific reason one would want to use enum over bool in this instance? Performance, readability, ease of future expansions, or any other overhead my young mind may not be seeing?

\$\endgroup\$
  • 1
    \$\begingroup\$ Use an enum if there can ever be more than two states, or they are not a yes/no-style of state, otherwise use a bool. (I.e., Up/Down would be a candidate for an enum, LoggedIn and LoggedOut probably not.) \$\endgroup\$ – 410_Gone Apr 13 '17 at 18:23
  • \$\begingroup\$ You may want to use other status in the future like Locked, Failed... \$\endgroup\$ – paparazzo Apr 13 '17 at 20:42
2
\$\begingroup\$

I find enums are ofte easier to use then booleans. At some point you probably will want to search for users so consider this:

User FindUserByStatus(LoginStatus status)

and its usage

userSearch.FindUserByStatus(LoginStatus.LoggedIn)

vs

User FindUserByStatus(bool loginStatus)

and its usage

userSearch.FindUserByStatus(true);

but even with the enum you could do

if (login) { .. }

by adding an implicit cast to the Login

public static implicit operator bool(Login login) => login.Status == LoginStatus.LoggedIn;
\$\endgroup\$
2
\$\begingroup\$

I would not use either. A boolean is too restrictive, and not readable. I enum is also too restrictive. Java enums are fine, but C# enums are bad OO, and under-powered.

Being logged in is not a simple as it may seem. Are you Identified? Are you identified, and authenticated? Are you identified, authenticated, and authorized? This term is ambiguous.

If you want the easiest and simplest solution, then use bool, but not from a LoggedIn property; maybe, an IsAuthorized property?

Still, you would do best to replace the enum with an full-fledged class (this matches your current terminology, but as I said above, it is ambiguous):

class LoginStatus
{
     private LoginStatus(string statusName) { StatusName = statusName; }
     public string StatusName { get; private set }
     public static readonly LoginStatus NOT_LOGGED_IN = new LoginStatus("Not Logged In");
     public static readonly LoginStatus LOGGED_IN = new LoginStatus("Logged In");
}

My life has been made much easier since I have stopped using C# enums, they really do cause more harm than good. In this situation, using an enum add more code to maintain over just using bool, but without the flexibility of using a full class.

\$\endgroup\$
  • 1
    \$\begingroup\$ Well, you can have a [Flags] enum and combine multiple values which is very useful for multiple states at the same time. \$\endgroup\$ – t3chb0t Apr 13 '17 at 19:17
  • \$\begingroup\$ You can do the same with a full fledged class, either by using a collection (the preferable solution), or assigning it a numerical Id the same way you would do with enums. I can also pass a function with an enum argument an undefined value, or combine enums in ways which make no sense. \$\endgroup\$ – TheCatWhisperer Apr 13 '17 at 19:22
  • \$\begingroup\$ It'd be great if you could add an example for this. Maybe you even convince me to use classes too ;-] \$\endgroup\$ – t3chb0t Apr 13 '17 at 19:24
  • 1
    \$\begingroup\$ I was just creating new enums... but I'll give classes a shot this time and see how it works for me. I always like to try out new ideas ;-) \$\endgroup\$ – t3chb0t Apr 13 '17 at 19:44
  • 2
    \$\begingroup\$ Trust me, when it becomes more than just a lookup (which they usually do) it will be much easier to make the change. Let me also state, the concept of something being just a lookup and not a first-class-entity is not as helpful as it may seem. Thanks for having an open mind :) \$\endgroup\$ – TheCatWhisperer Apr 13 '17 at 19:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.