Boolean Naming Conventions

[james]

Re: Boolean Naming Conventions

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


"Aaron [SQL Server MVP]" <ten.xoc@dnartr eb.noraa> wrote in message
news:OqGJB5dZEH A.3512@TK2MSFTN GP12.phx.gbl...[color=blue][color=green]
> > Yuck ! why not simply use bit. ?? I mean if it is only for the
> > programmers then a bit 1 or 0 makes more sense[/color]
>
> It's NOT always for the programmers. Bean-counters, slack-jaws, etc.[/color]
don't[color=blue]
> 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.
>[color=green]
> > Theoretically a Char(1) can contain other characters beside Y or N so[/color][/color]
now[color=blue][color=green]
> > you need all kinds of overhead to verify data integrity[/color]
>
> 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.
>
> --
> http://www.aspfaq.com/
> (Reverse address to reply.)
>
>[/color]

[Aaron [SQL Server MVP]]

Re: Boolean Naming Conventions

> Ok, so then what if your target audience is non-English, maybe they[color=blue]
> 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.[/color]

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.

[james]

Re: Boolean Naming Conventions

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


"Aaron [SQL Server MVP]" <ten.xoc@dnartr eb.noraa> wrote in message
news:%23HzAP7Ba EHA.2972@TK2MSF TNGP12.phx.gbl. ..[color=blue][color=green]
> > 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[/color][/color]
if[color=blue][color=green]
> > 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.[/color]
>
> I don't think anyone said you have to use Y or N, or T or F, or D or N, or[/color]
1[color=blue]
> or 0. I was merely trying to explain to you *WHY* some people shy away[/color]
from[color=blue]
> 1 and 0.
>
>[/color]

[Steve Beach]

Re: Boolean Naming Conventions

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


"james" <nospam@hyperco n.net> wrote in message
news:uAtiaCCaEH A.3692@TK2MSFTN GP09.phx.gbl...[color=blue]
> Aaron, my response was actually more meant for Steve and the rest but I[/color]
just[color=blue]
> 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
>
>
> "Aaron [SQL Server MVP]" <ten.xoc@dnartr eb.noraa> wrote in message
> news:%23HzAP7Ba EHA.2972@TK2MSF TNGP12.phx.gbl. ..[color=green][color=darkred]
> > > 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 /[/color][/color][/color]
N[color=blue][color=green][color=darkred]
> > > thingy when it really should be D and N, duh ! I guess in my opinion[/color][/color]
> if[color=green][color=darkred]
> > > people can't understand 1 and 0 they probably shouldn't be accessing[/color][/color][/color]
the[color=blue][color=green][color=darkred]
> > > database at all. As a db Admin that would make me very nervous.[/color]
> >
> > I don't think anyone said you have to use Y or N, or T or F, or D or N,[/color][/color]
or[color=blue]
> 1[color=green]
> > or 0. I was merely trying to explain to you *WHY* some people shy away[/color]
> from[color=green]
> > 1 and 0.
> >
> >[/color]
>
>[/color]

[james]

Re: Boolean Naming Conventions

;-)


"Steve Beach"
<(RE-M0V3)steveb@pat h(RE-M0V3)guide.com( RE-M0VE--THE-REST)nospam@sp4 m.com>
wrote in message news:%23hJFdHDa EHA.2296@TK2MSF TNGP10.phx.gbl. ..[color=blue]
> 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[/color]
on[color=blue]
> 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[/color]
feel[color=blue]
> 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[/color]
of[color=blue]
> 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[/color]
the[color=blue]
> main point across.
>
> Steve
>
>
> "james" <nospam@hyperco n.net> wrote in message
> news:uAtiaCCaEH A.3692@TK2MSFTN GP09.phx.gbl...[color=green]
> > Aaron, my response was actually more meant for Steve and the rest but I[/color]
> just[color=green]
> > hit reply on your message :-) Everyone has their opinions on these[/color][/color]
things[color=blue][color=green]
> > and that's OK I suppose, as long as people understand who they are[/color][/color]
working[color=blue][color=green]
> > for and what they can get away with it all works out in the end. Its[/color][/color]
kind[color=blue][color=green]
> > of like the dangling barcket issue. I cannot stand reading code with[/color][/color]
the[color=blue][color=green]
> > opening bracket on the same line as the statement, but many if not most
> > developers do it that way.
> >
> > JIM
> >
> >
> > "Aaron [SQL Server MVP]" <ten.xoc@dnartr eb.noraa> wrote in message
> > news:%23HzAP7Ba EHA.2972@TK2MSF TNGP12.phx.gbl. ..[color=darkred]
> > > > 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[/color][/color][/color]
/[color=blue]
> N[color=green][color=darkred]
> > > > thingy when it really should be D and N, duh ! I guess in my[/color][/color][/color]
opinion[color=blue][color=green]
> > if[color=darkred]
> > > > people can't understand 1 and 0 they probably shouldn't be accessing[/color][/color]
> the[color=green][color=darkred]
> > > > database at all. As a db Admin that would make me very nervous.
> > >
> > > I don't think anyone said you have to use Y or N, or T or F, or D or[/color][/color][/color]
N,[color=blue]
> or[color=green]
> > 1[color=darkred]
> > > or 0. I was merely trying to explain to you *WHY* some people shy[/color][/color][/color]
away[color=blue][color=green]
> > from[color=darkred]
> > > 1 and 0.
> > >
> > >[/color]
> >
> >[/color]
>
>[/color]

[Wavemaker]

Re: Boolean Naming Conventions


"james" wrote:[color=blue]
> Wavemaker, no you are not only asking its state you are setting[/color]
its state.[color=blue]
> i.e. Get IsActive, and Set IsActive
>
> i.e. Employee.IsActi ve = false
>
> and
>
> if ( Employee.IsActi ve ) ...
>
>
> JIM[/color]

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.I sActive)

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.Acti vate();
anEmployee.Deac tivate();
anEmployee.IsAc tive; // 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.

[james]

Re: Boolean Naming Conventions

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



"Wavemaker" <jabberdabber@B iteMeHotmail.co m> wrote in message
news:keednSmIEK q2smnd4p2dnA@co mcast.com...[color=blue]
>
> "james" wrote:[color=green]
> > Wavemaker, no you are not only asking its state you are setting[/color]
> its state.[color=green]
> > i.e. Get IsActive, and Set IsActive
> >
> > i.e. Employee.IsActi ve = false
> >
> > and
> >
> > if ( Employee.IsActi ve ) ...
> >
> >
> > JIM[/color]
>
> 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.I sActive)
>
> 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.Acti vate();
> anEmployee.Deac tivate();
> anEmployee.IsAc tive; // 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.
>
>[/color]

[--CELKO--]

Re: Boolean Naming Conventions

>> 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 :)

[Steve Beach]

Re: Boolean Naming Conventions

:)

"--CELKO--" <jcelko212@eart hlink.net> wrote in message
news:18c7b3c2.0 407181157.1639d 6b7@posting.goo gle.com...[color=blue][color=green][color=darkred]
> >> Also, one reason that I don't use BIT datatype is because of Joe[/color][/color]
> 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 :)[/color]