Naming conventions: "State" versus "Status"

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

Heh. The other day at work I came across some structure that had a member named "state" and another member named "status," and they were different things. I started thinking about what the words meant, and about whether to change it, but the code was old and crufty and working, so I let that sleeping dog lie. Oh.. this probably should have been a "comment," rather than an "answer, eh? Comment, answer, state, status... whatever.

Answer 6

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!

Answer 7

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.

Answer 8

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.

Answer 9

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.