Boolean Naming Conventions

  • Thread starter Thread starter news.microsoft.com
  • Start date Start date
I use all of these except

MIGHT
MAY
MUST
SHALL
WOULD


Might is too non-deterministic, May is replaced by Can (although
gramatically this is backweards) and Must is replaced by Will or Should


JIM
 
Yuck ! why not simply use bit. ?? I mean if it is only for the
programmers then a bit 1 or 0 makes more sense

Theoretically a Char(1) can contain other characters beside Y or N so now
you need all kinds of overhead to verify data integrity

JIM


"Steve Beach"
 
Yuck ! why not simply use bit. ?? I mean if it is only for the
programmers then a bit 1 or 0 makes more sense
Click to expand...

It's NOT always for the programmers. Bean-counters, slack-jaws, etc. don't
know what 1 and 0 mean. Y or N (or T or F) often make more sense to them.
And yes, you could do this with views, but that might mean a lot of extra
code, depending on how many such columns you have.
Theoretically a Char(1) can contain other characters beside Y or N so now
you need all kinds of overhead to verify data integrity
Click to expand...

You also need this on BIT if you don't want to allow NULL; I don't see a
huge difference here, except the constraint is slightly different.
 
A CHECK (val in ('Y', 'N')) constraint won't cause much overhead.

BIT has other issues, e.g. it can't be included in an index.
 
why not simply use bit. ?? <<

Because in t-SQL, bit datatype has nothing in common with a univeral boolean
datatype. Bit has numeric values while boolean has logical values.
Implication operations require explicit assignments when a numerical value
is treated like a logical value.

In t-SQL, simple CHECK constraint would do.
 
BIT has other issues, e.g. it can't be included in an index.

It can (Enterprise Manager won't allow you to choose a BIT column in its
cumbersome index gui, but Query Analyzer will allow you to run a manual
CREATE INDEX).

However, due to cardinality, it would be no more useful than an index on a
CHAR(1) column, where the values must be IN ('Y', 'N').
 
Aaron said:
It can (Enterprise Manager won't allow you to choose a BIT column in its
cumbersome index gui, but Query Analyzer will allow you to run a manual
CREATE INDEX).
Click to expand...

Thanks for the clarification. I stopped implementing BIT columns around
the same time I stopped using EM :)
However, due to cardinality, it would be no more useful than an index on a
CHAR(1) column, where the values must be IN ('Y', 'N').
Click to expand...

Even an index on a CHAR(1) column could be useful if either the number
of 'Y' or 'N' occurrences was fairly sparse...
 
However, due to cardinality, it would be no more useful than an index on
a
Even an index on a CHAR(1) column could be useful if either the number
of 'Y' or 'N' occurrences was fairly sparse...
Click to expand...

Right, about the same (or "no more useful") as an index on BIT, if either
the number of 0 or 1 occurences was fairly sparse.

I didn't say the index would always be useless, just that in most cases it
is, and that even if BIT couldn't take an index, that wouldn't be a con in
most cases, because the index would only be used in very extreme
circumstances.

A
 
Daniel O'Connell said:
They make mistakes too. I think Is probably was one,
especially inlight of languages like VB where IsXxx()
fuctions are exceedingly common. There are just to many
uses of the word. IsXxx functions, IsXxx Properties, IsXxx
methods, etc.
Click to expand...

Well, this is an interesting issue for me. I'm designing a .NET
tookit, and I want to get things right since it will hopefully be
used by a large number of .NET programmers.

My take on this is the following: IsXXX is a query about an object's
state. You are not accessing an object's state directly, rather you
are asking the object to tell you about its state. That doesn't feel
like a property to me. It would seem more natural to make the query
into a method, IMO.

On the other hand, I've seen lots of IsXXX properties in the .NET
framework. For example, the TextBox class has the IsAccessible,
IsDisposed, and IsHandleCreated properties. So I'm torn as a
designer from doing what seems most elegant and natural to me, to
doing what seems to be standard within .NET, at least the parts of
..NET I'm familiar with.
That doesn't mean I would use any one of them just because
Microsoft did.
Click to expand...

Your point is well taken. I will give this some thought.
 
Wavemaker, no you are not only asking its state you are setting its state.
i.e. Get IsActive, and Set IsActive

i.e. Employee.IsActive = false

and

if ( Employee.IsActive ) ...


JIM
 
Ok, so then what if your target audience is non-English, maybe they
understand Da and Nyet ? So now they are all confused aboiut this Y / N
thingy when it really should be D and N, duh ! I guess in my opinion if
people can't understand 1 and 0 they probably shouldn't be accessing the
database at all. As a db Admin that would make me very nervous.


JIM
 
Ok, so then what if your target audience is non-English, maybe they
understand Da and Nyet ? So now they are all confused aboiut this Y / N
thingy when it really should be D and N, duh ! I guess in my opinion if
people can't understand 1 and 0 they probably shouldn't be accessing the
database at all. As a db Admin that would make me very nervous.
Click to expand...

I don't think anyone said you have to use Y or N, or T or F, or D or N, or 1
or 0. I was merely trying to explain to you *WHY* some people shy away from
1 and 0.
 
Aaron, my response was actually more meant for Steve and the rest but I just
hit reply on your message :-) Everyone has their opinions on these things
and that's OK I suppose, as long as people understand who they are working
for and what they can get away with it all works out in the end. Its kind
of like the dangling barcket issue. I cannot stand reading code with the
opening bracket on the same line as the statement, but many if not most
developers do it that way.

JIM
 
I actually don't care about which method is used; we use both Y/N and 1/0,
depending on where the flag is used. I was just giving the OP an example on
how we do it.

For example, system flags (to control behavior) that are stored in our
"database registry" that can only be changed in the registry are typically
stored as Y/N. To change one of these flags, the user changes the value
from Y to N (or reverse). Flags that can be changed via a form (checkbox)
are stored as 1/0 (vbChecked / vbUnchecked) because we read the value
direcly from the checkbox control.

As you said, whatever works (or whatever you can get away with!). Using 1
and 0 works just as well as (Y or N) or (T or F) or even (D or N)!

As for the opening bracket, I do it both ways, depending on how saucy I feel
that day. :)

Also, one reason that I don't use BIT datatype is because of Joe Celko's
unending hatred of bit fields. I believe that he calls the BIT datatype a
proprietary, non-portable datatype that is designed to suck the soul out of
the body and in order to recover you have to pay him a lot of money to
perform an exorcism. I might have paraphrased a little but I think I got the
main point across.

Steve
 
;-)


"Steve Beach"
I actually don't care about which method is used; we use both Y/N and 1/0,
depending on where the flag is used. I was just giving the OP an example on
how we do it.

For example, system flags (to control behavior) that are stored in our
"database registry" that can only be changed in the registry are typically
stored as Y/N. To change one of these flags, the user changes the value
from Y to N (or reverse). Flags that can be changed via a form (checkbox)
are stored as 1/0 (vbChecked / vbUnchecked) because we read the value
direcly from the checkbox control.

As you said, whatever works (or whatever you can get away with!). Using 1
and 0 works just as well as (Y or N) or (T or F) or even (D or N)!

As for the opening bracket, I do it both ways, depending on how saucy I feel
that day. :)

Also, one reason that I don't use BIT datatype is because of Joe Celko's
unending hatred of bit fields. I believe that he calls the BIT datatype a
proprietary, non-portable datatype that is designed to suck the soul out of
the body and in order to recover you have to pay him a lot of money to
perform an exorcism. I might have paraphrased a little but I think I got the
main point across.

Steve


/ N,
Click to expand...
 
james said:
Wavemaker, no you are not only asking its state you are setting its state.
i.e. Get IsActive, and Set IsActive

i.e. Employee.IsActive = false

and

if ( Employee.IsActive ) ...


JIM
Click to expand...

Well, you can do this, of course. But my comments were based on the
assumption that you wouldn't want to. :-) In your example, IsActive
indicates whether or not an employee is active. When you test this
property with the following:

if(anEmployee.IsActive)

You are saying if this employee *is active*, then do the
following...

The "Is" implies a query about the object's state. Naming a property
IsActive and making it writeable seems odd, like telling a question
what the answer is rather than asking a question to find the answer.
It doesn't seem semantically natural to me.

I would prefer something like this:

anEmployee.Activate();
anEmployee.Deactivate();
anEmployee.IsActive; // Read only property.

If you agree that what I've said above makes sense, then the issue
becomes whether or not to make IsActive a property or a method. I
haven't made up my mind on this, but I'm leaning towards the method
route because asking an object about its state is an action and is
better represented by a method (possibly). But I'm still thinking
about this...

A minor issue, but when you are writing a library that will possibly
be used by a lot of programmers, you find yourself giving a lot of
thought to these small nuances.
 
Well, if you look behind the scenes, a property is really two methods, a
GetIsActive() and a SetIsActive(). So you could just remove the Is part and
simply use Active, but for readability I like the Is. I guess it's like my
old mentor always says, stop thinking and start doing ;-)

JIM
 
Also, one reason that I don't use BIT datatype is because of Joe
Celko's unending hatred of bit fields. I believe that he calls the
BIT datatype a proprietary, non-portable datatype that is designed to
suck the soul out of
the body and in order to recover you have to pay him a lot of money to
perform an exorcism. I might have paraphrased a little but I think I
got the main point across. <<

Actually, that is nicer than I phrased it :)
 
:)

--CELKO-- said:
Celko's unending hatred of bit fields. I believe that he calls the
BIT datatype a proprietary, non-portable datatype that is designed to
suck the soul out of
the body and in order to recover you have to pay him a lot of money to
perform an exorcism. I might have paraphrased a little but I think I
got the main point across. <<

Actually, that is nicer than I phrased it :)
Click to expand...
 
Back
Top