Positive or negative boolean field names

Question

A table's boolean fields can be named using the positive vs the negative...

for example, calling a field:

"ACTIVE" , 1=on / 0=off 
or
"INACTIVE" , 0=on / 1=off

---

Question: Is there a proper way to make this type of table design decision, or is it arbitrary?

---

My specific example is a messages table with a bool field (private/public). This field will be set using a form checkbox when a user enters a new message. Is there a benefit in naming the field "public" vs "private"?

thanks.

Answer 1

I always prefer positive names, to avoid double negatives in code. "Is not inactive" is often cause for a double take when reading. "Is inactive" can always be written as "if (!Active)" whilst taking advantage of built-in language semantics.

Answer 2

My personal preference:

• Use prefixes like "Is", "Has", etc. for Boolean fields to make their purpose clear.
• Always name variables in the affirmative. For Active/Inactive, I would name it IsActive.
• Don't make a bit field nullable unless you really have a specific purpose in doing so.

In your specific use case, the field should be named either IsPublic or IsPrivate--whichever name would result in a True answer when the user ticks the checkbox.

Answer 3

i would not disagree with some of the other answers but definitely avoid the incorrect answer which is not to put in double negatives always

Answer 4

Always use positive names.

If use negative names, you very quickly get into double negation. Not that double negation is rocket surgery, but it's a brain cycle and those are valuable :)

Answer 5

Always use positive.

It's simpler.

Take using the negation to the logical extreme: if InActive is better than Active, then why not InInActive, or InInInActive?

Because it would be less simple.

Answer 6

The proper way to handle these situations is to create a table to house the values associated with the column, and create a foreign key relationship between the two tables. IE:

WIDGETS table:

• WIDGET_ID
• WIDGET_STATUS (fk)

WIDGET_STATUS_CODES table:

• WIDGET_STATUS_CODE (pk)
• DESCRIPTION

If possible, WIDGET_STATUS_CODE would be a natural key (IE: ACT for "Active", INA for "Inactive"). This would make records more human readable, but isn't always possible so you'd use an artificial/surrogate key (like an auto-number/sequence/etc).

You want to do this because:

• It's readable what status indicates (which was the original question)
• Future proof in the need to define/use more statuses
• Provides referencial integrity so someone couldn't set the value to 2, 3, 4, etc.
• Space is cheap; there's nothing efficient about allowing bad data