Naming conventions: "State" versus "Status"
Naming ConventionsNomenclatureNaming Conventions Problem Overview
Quick question: I'd like to hear your thoughts on when to use "State" versus "Status" when naming both fields such as "Foo.currentState" vs "Foo.status" and types, like "enum FooState" vs "enum FooStatus". Is there a convention discussed out there? Should we only use one? If so which one, and if not, how should we choose?
Naming Conventions Solutions
Solution 1 - Naming Conventions
IMO:
status == how are you? [good/bad]
state == what are you doing? [resting/working]
Solution 2 - Naming Conventions
It depends on the context
State generally refers to the entire state of an entity - all its values and relationships at a particular point in time (usually, current)
Status is more of a time-point, say, where something is at in a process or workflow - is it dirty (therefore requiring saving), is it complete, is it pending input, etc
I hope that helps you in your decision.
Solution 3 - Naming Conventions
Typically I will use State to mean the current condition of an object or the system as a whole. I use status to represent the outcome of some action. For example, the state of an object may be saved/unsaved, valid/invalid. The status (outcome) of a method is successful/unsuccessful/error. I think this jibes pretty well with the definition of status as "state or condition with respect to circumstances," the circumstances in this case being the application of an action/method.
Solution 4 - Naming Conventions
Another (entirely pragmatic) reason to prefer state over status is that the plural is straightforward:
- state -> states
- status -> statuses
And believe me, you will sooner or later have a list or array or whatever of states in your code and will have to name the variable.
Solution 5 - Naming Conventions
I think many people use "Status" to represent the state of an object if for no other reason than "State" refers to a political division of the United States.
Solution 6 - Naming Conventions
I think you could add another perspective to the equation, namely 'sender-requester'.
From a senders perspective, I'd communicate my state with anyone willing to listen. While from a requesters perspective, I'd be asking for someone's status.
The above could also be interpreted from an uncertainty point of view:
- Defined = state
- Undefined = status
What's your status? I'm in a relaxed state.
I'm pretty sure this is just one interpretation, which may not apply to your particular situation.
Solution 7 - Naming Conventions
A quick dictionary check reveals that status is a synonym for state, but has an additional interpretation of a position relative to that of others.
So I would use state for a set of states that don't have any implicit ordering or position relative to one another, and status for those that do (perhaps off-standby-on ?). But it's a fine distinction.
Solution 8 - Naming Conventions
A lot of the entities I deal with (accounts, customers) may have a State (TX, VA, etc.) and a Status (Active, Closed, etc.)
So the point about the term being misleading is possible. We have a standardized database naming convention (not my personal choice) where a state is named ST_CD and a status would be ACCT_STAT_CD.
With an enum in an OO milieux, this issue is not as important, since if you have strict type safety, the compiler will ensure that no one attempts to do this:
theCustomer.State = Customer.Status.Active;
If you are in a dynamic environment, I would be more worried!
If you are dealing with a domain where state machines or other state information and that terminology is predominant, then I would think State is perfectly fine.
Solution 9 - Naming Conventions
We had this exact debate on my current project a while back. I really don't have a preference, but consistency is an important consideration.
The first (there are several) definition of "state" in my Sharp PW-E550 (an awesome dictionary, I might add) is "the particular condition that someone or something is in at a specific time." The first definition of "status" is "the relative social, professional, or other standing of someone or something". Even the second (and last) definition of "status" is inferior to "state" in this context: "the position of affairs at a particular time, esp. in political or commercial contexts."
So if we wanted it to be as easy as possible for someone using my dictionary (it uses the New Oxford American Dictionary, 2001), "state" would be the best choice.
Furthermore, there is a design pattern described in the Gang of Four's book called the State Pattern, firmly establishing the term in the computing lexicon.
For these reasons I suggest "state".
P.S. Is that you DDM? Are you still bitter about "state" versus "status" ?!!!!!!! LMAO!
Solution 10 - Naming Conventions
Not the same thing at all. Stopped and started are states. Stopping and starting are status.
If you make them them the same thing how do you describe the vehicle as stopped but is currently starting. Or an application as currently lodged but hasn't yet entered the approval process or is being approved but is currently on hold with an error condition of awaiting signature?
Solution 11 - Naming Conventions
Well, they do mean the same thing. I don't think it's necessary to promulgate a great preference of one over the other, but I would generally go with "status", because I like things that sound Latinate and classicist. I mean, in my world, the plural of schema is schemata, so there's pretty much no other way for it to go, with me.
Solution 12 - Naming Conventions
Sophistifunk, I'm sure you'll get arguments for both State and Status. The most important thing to do is that you pick one, and use only one. I'd suggest discussing this with your team and see what everyone agrees on.
That said, my suggestion is as follows.
Assuming you are using an object-oriented programming language, an object's "state" is represented by the object itself. SomeObject.state is misleading imo. I'm not sure what "status" represents in your example, but my natural intuition is to prefer this to state.