Positive or Negative

  • Comments posted to this topic are about the item Positive or Negative

  • I am definitely in the 'IsActive', 'IsCurrent' camp.

    The absence of evidence is not evidence of absence.
    Martin Rees

    You can lead a horse to water, but a pencil must be lead.
    Stan Laurel

  • I always try and use IsActive with 1 for Yes and 0 for No (Default 1, Not NULL) and save it as a Bit / Boolean data type.

    Obviously when it's not a straight Yes / No or On / Off then usually a Char(1) Not Null Default 1.

    David Grant

  • "IsActive" or "Active" or suchlike - 1 when it is active and 0 when not.

    I have seen a column that is "NotActive" with a value of 0 to indicate that it is active. In my mind this is a double negative and makes it more complicated than it needs to be - especially if there a few indicators like this in the same query. How easy is it read something that keeps referring to "Not NotActive"?

  • I suggest it depends on intent. If the intent is that the user must explicitly acknowledge that it is active then I would go for the positive approach. If the records are normally inactive and only some become active then I would use the negative approach.

  • The negative form leads to difficulties with double negatives (if isInactive = 0). The positive form is much clearer.

  • I have always used a column called Active with a value of 1 for active and 0 for inactive. I find it much easier to think in terms of a 1 being true and 0 being negative, I think the term is positive logic, and I think it makes the code more intuitive to understand.

  • I prefer notation, described in post.

    If state of record considered as normal, it should be "0". I use value "1" for special condition.

    For example:

    Correct:

    Default state of record: Deleted = 0

    Manually switched or coused by special event state: Deleted = 1

    Incorrect:

    Normal user account: IsActive = 1 by default

    Banned user account: IsActive = 0

  • I don't have a preference and I use both. For me it depends on the actual meaning of the flag and the default value. Usually I will choose the name that will make the default value 0 (=No). For example are the records normally active? If so then I prefer "Inactive" or "IsInactive" or "Disabled" as it clearly shows which state deviates from normal.

    Sometimes I may use one or the other to emphasize the meaning.

    Rarely I may choose the one that makes most expressions simpler to code. For example if I commonly check if something is inactive in order to do some special processing or filter, but the opposite is not true, I prefer IsInactive. If OTOH I usually check for something being active (e.g. return only active records) then I prefer IsActive. Regularly using negations (NOT IsActive or IsActive=0) is error prone.

  • I predominately work in the data warehousing space and adopt an alternative approach which takes out the aspect of either 'Positive' or 'Negative'. For example, a fact which measures the change in activity on a record, would have a "StatusKey" that links back to a dimension containing the actual values "Active", "Inactive" as well as a couple other relevant statuses (such as "Deleted" to track those pesky removals from the source data).

  • I am firmly in the "flag exceptions" camp. So normally I have columns like [disabled], [exclude], [unsubscribed] which default to zero, and are set to 1 to mark the exception. This is the way many operating systems and languages have always worked: 0=nothing to report, non-zero means some kind of exception / error.

    I always try to name the column for the exception condition. For example, if the normal condition was "inactive", my column might be called [active] with a default of zero. If the normal condition was "active", my column might be called [inactive] with a default of zero.

    Consistency is good, as is using a limited set of verbs for these column names, and always trying to use the same verb for the same kind of exception across the whole database. (i.e. do not mix-n-match synonyms)

  • Not exactly an answer to the question, but I use a field named State, Status, or Condition.

    VARCHAR(1), Default '' (an empty string).

    I fill this field with a Char when the Status is "not normal", e.g.

    e = ex client

    i = ignore client (the client doesn't want any contact: e.g. client deceased)

    u = undesirable (we don't want that client any more: payment problems, etc.)

    For normal clients the clause is:

    WHERE Status = ''

    Active clients are found with a negative flag (Compare an empty string with zero)

  • I try to avoid naming Boolean columns as the inverse of their meaning.

    It makes for confusion when naming Boolean columns Un... or Not...

    I believe that for most people Deleted=True is less confusing than Undeleted=False

    Or you could really confuse things by naming columns such as NotInactive (I have seen it done!)

  • Fedor 28151 (10/23/2015)


    I prefer notation, described in post.

    If state of record considered as normal, it should be "0". I use value "1" for special condition.

    For example:

    Correct:

    Default state of record: Deleted = 0

    Manually switched or coused by special event state: Deleted = 1

    Incorrect:

    Normal user account: IsActive = 1 by default

    Banned user account: IsActive = 0

    I agree with you, it depends on the case. However, when I am in doubt I choose IsActive. Also, I prefer to use IsActive than Active

  • Henk Schreij (10/23/2015)


    Not exactly an answer to the question, but I use a field named State, Status, or Condition.

    VARCHAR(1), Default '' (an empty string).

    I fill this field with a Char when the Status is "not normal", e.g.

    e = ex client

    i = ignore client (the client doesn't want any contact: e.g. client deceased)

    u = undesirable (we don't want that client any more: payment problems, etc.)

    Yike. With an FK to a table to explain what each one means and to prevent illegal values?

Viewing 15 posts - 1 through 15 (of 129 total)

You must be logged in to reply to this topic. Login to reply