Boolean Naming Conventions

Greetings,
I am posting this message to both the SQL Server and C# news groups
because this inquiry is more of a theoretical question that applies to both
database and code naming conventions.

I have currently been prefixing boolean object properties and database
columns with Is .. for example (defining a CAT being declawed): IsDeclawed.
Well, the prefix of Is doesn't always work ... for example: IsHasWiskers ..
well, that doesn't really sound all that great. Also, IsUsesLitterBox .
that doesn't sound good either.

So what I'm asking the development community is what are the standard naming
conventions for boolean fields?

Thanks for your time.

why not leave the "question" out of the name.

IsDeclawed goes to Declawed <True-False> <1-0>
DoesHaveWiskers goes to HasWiskers <True-False> <1-0>
DoesUseLitterBox goes to UsesLitterBox <True-False> <1-0>

am i missing something? why imply datattype in the name?

news.microsoft.com wrote:[color=blue]
> Greetings,
> I am posting this message to both the SQL Server and C# news
> groups because this inquiry is more of a theoretical question that
> applies to both database and code naming conventions.
>
> I have currently been prefixing boolean object properties and database
> columns with Is .. for example (defining a CAT being declawed):
> IsDeclawed. Well, the prefix of Is doesn't always work ... for
> example: IsHasWiskers .. well, that doesn't really sound all that
> great. Also, IsUsesLitterBox . that doesn't sound good either.
>
> So what I'm asking the development community is what are the standard
> naming conventions for boolean fields?
>
> Thanks for your time.[/color]

I generally name bit fields in sql as Yes Or No Questions

IsDeadAsAStick
NeedsToBeSlapped
HasToBeDeaf
MustBeRotten

etc etc etc

Greg Jackson
PDX, Oregon

Josh,
What I'm trying to achieve is to get a set few prefixes that can address
all boolean scenarios. Try to keep everything clean.. One person told me
to try to use just:

Is
Has

but that doesn't address them all. Trying to keep things standardized.

"Josh Golden" <joshg@wachovia.com> wrote in message
news:40eebcb7$0$82993$39cecf19@news.twtelecom.net. ..[color=blue]
> why not leave the "question" out of the name.
>
> IsDeclawed goes to Declawed <True-False> <1-0>
> DoesHaveWiskers goes to HasWiskers <True-False> <1-0>
> DoesUseLitterBox goes to UsesLitterBox <True-False> <1-0>
>
> am i missing something? why imply datattype in the name?
>
>
>
> news.microsoft.com wrote:[color=green]
> > Greetings,
> > I am posting this message to both the SQL Server and C# news
> > groups because this inquiry is more of a theoretical question that
> > applies to both database and code naming conventions.
> >
> > I have currently been prefixing boolean object properties and database
> > columns with Is .. for example (defining a CAT being declawed):
> > IsDeclawed. Well, the prefix of Is doesn't always work ... for
> > example: IsHasWiskers .. well, that doesn't really sound all that
> > great. Also, IsUsesLitterBox . that doesn't sound good either.
> >
> > So what I'm asking the development community is what are the standard
> > naming conventions for boolean fields?
> >
> > Thanks for your time.[/color]
>
>[/color]

"Josh Golden" <joshg@wachovia.com> wrote in message
news:40eebcb7$0$82993$39cecf19@news.twtelecom.net. ..[color=blue]
> why not leave the "question" out of the name.
>
> IsDeclawed goes to Declawed <True-False> <1-0>
> DoesHaveWiskers goes to HasWiskers <True-False> <1-0>
> DoesUseLitterBox goes to UsesLitterBox <True-False> <1-0>
>
> am i missing something? why imply datattype in the name?[/color]

I like implication of boolean types in the name as it allows one to ask
a question of an object:

if (......)
Cat.UsesLitterBox
Cat.IsDeclawed
Cat.HasWhiskers

So: if Cat Uses Litter Box, do X... if Cat Is Declawed, do Y... etc.

It would make no sense to ask:

if Cat.LitterBox //Is this a reference to a litterbox object?

or if Cat Declawed //was this written by someone who is just learning
English? :)

Finally, is not in the same form as UsesLitterBox (verb-noun or
verb-adjective); in my opinion the most important aspect of any naming
scheme is consistency. So if you're going to prefix one boolean with a
verb, prefix all of them with a verb.

ok. do you prefix every database column with the data type?

text_comments
varchar20_customer_name
string_customer_name
intGreaterThanZero_customer_number

it seems weird to me.

customer_number
shipping_comments
balance_due
room_id
employee_extension
currently_employed
married
pack_slip_number
pack_slip_code

all are fairly clear on the data type without saying it. i don't know. i'm
not picking on you. i don't like to do that with names.

i don't like to say

t_customer
table_customer
tblCustomer
v_customers
view_customers
etc.

for a view maybe - "customers" where the underlying table is "customer"

news.microsoft.com wrote:[color=blue]
> Josh,
> What I'm trying to achieve is to get a set few prefixes that can
> address all boolean scenarios. Try to keep everything clean.. One
> person told me to try to use just:
>
> Is
> Has
>
> but that doesn't address them all. Trying to keep things
> standardized.
>
>
>
> "Josh Golden" <joshg@wachovia.com> wrote in message
> news:40eebcb7$0$82993$39cecf19@news.twtelecom.net. ..[color=green]
>> why not leave the "question" out of the name.
>>
>> IsDeclawed goes to Declawed <True-False> <1-0>
>> DoesHaveWiskers goes to HasWiskers <True-False> <1-0>
>> DoesUseLitterBox goes to UsesLitterBox <True-False> <1-0>
>>
>> am i missing something? why imply datattype in the name?
>>
>>
>>
>> news.microsoft.com wrote:[color=darkred]
>>> Greetings,
>>> I am posting this message to both the SQL Server and C# news
>>> groups because this inquiry is more of a theoretical question that
>>> applies to both database and code naming conventions.
>>>
>>> I have currently been prefixing boolean object properties and
>>> database columns with Is .. for example (defining a CAT being
>>> declawed): IsDeclawed. Well, the prefix of Is doesn't always work
>>> ... for example: IsHasWiskers .. well, that doesn't really sound
>>> all that great. Also, IsUsesLitterBox . that doesn't sound good
>>> either.
>>>
>>> So what I'm asking the development community is what are the
>>> standard naming conventions for boolean fields?
>>>
>>> Thanks for your time.[/color][/color][/color]

ok - you are singling out OOP it looks. and the OP is trying to apply a
consistent naming convention across the db and a programming language. i
don't view them the same. i was more targeting sql naming convention.

in OOP i do just as you have explained. in sql, i do as I have explained.

Adam Machanic wrote:[color=blue]
> "Josh Golden" <joshg@wachovia.com> wrote in message
> news:40eebcb7$0$82993$39cecf19@news.twtelecom.net. ..[color=green]
>> why not leave the "question" out of the name.
>>
>> IsDeclawed goes to Declawed <True-False> <1-0>
>> DoesHaveWiskers goes to HasWiskers <True-False> <1-0>
>> DoesUseLitterBox goes to UsesLitterBox <True-False> <1-0>
>>
>> am i missing something? why imply datattype in the name?[/color]
>
>
> I like implication of boolean types in the name as it allows one
> to ask a question of an object:
>
> if (......)
> Cat.UsesLitterBox
> Cat.IsDeclawed
> Cat.HasWhiskers
>
> So: if Cat Uses Litter Box, do X... if Cat Is Declawed, do Y...
> etc.
>
> It would make no sense to ask:
>
> if Cat.LitterBox //Is this a reference to a litterbox object?
>
> or if Cat Declawed //was this written by someone who is just
> learning English? :)
>
> Finally, is not in the same form as UsesLitterBox (verb-noun or
> verb-adjective); in my opinion the most important aspect of any naming
> scheme is consistency. So if you're going to prefix one boolean with
> a verb, prefix all of them with a verb.[/color]

> if Cat.LitterBox //Is this a reference to a litterbox object?

Well, when you map this column in the resultset to a variable in an OOP
language, okay.

But as a column name, I don't think the Is or Has adds anything. You still
can't say WHERE Cat.IsDeclawed, you have to say WHERE Cat.IsDeclawed = 1.
So it's not even really a boolean / true/false / etc. At best, to be a
truly compatible boolean, you would have a function that returns True or
False, and use it like WHERE IsTrue(Cat.Declawed)???

--
http://www.aspfaq.com/
(Reverse address to reply.)

Adam,

So basically, as a rule of thumb, all boolean fields / proerties /
columns should be able to fall in to IS, HAS, or USES ...

I think I posted this question all goofy because a lot of reponses are
referring to T-SQL syntax. This was more of a theroritcal naming convention
question.

Thanks for all of the reponses.

Jay

"Adam Machanic" <amachanic@hotmail._removetoemail_.com> wrote in message
news:uKJTYzcZEHA.1248@TK2MSFTNGP11.phx.gbl...[color=blue]
>
> "Josh Golden" <joshg@wachovia.com> wrote in message
> news:40eebcb7$0$82993$39cecf19@news.twtelecom.net. ..[color=green]
> > why not leave the "question" out of the name.
> >
> > IsDeclawed goes to Declawed <True-False> <1-0>
> > DoesHaveWiskers goes to HasWiskers <True-False> <1-0>
> > DoesUseLitterBox goes to UsesLitterBox <True-False> <1-0>
> >
> > am i missing something? why imply datattype in the name?[/color]
>
>
> I like implication of boolean types in the name as it allows one to[/color]
ask[color=blue]
> a question of an object:
>
> if (......)
> Cat.UsesLitterBox
> Cat.IsDeclawed
> Cat.HasWhiskers
>
> So: if Cat Uses Litter Box, do X... if Cat Is Declawed, do Y... etc.
>
> It would make no sense to ask:
>
> if Cat.LitterBox //Is this a reference to a litterbox object?
>
> or if Cat Declawed //was this written by someone who is just learning
> English? :)
>
> Finally, is not in the same form as UsesLitterBox (verb-noun or
> verb-adjective); in my opinion the most important aspect of any naming
> scheme is consistency. So if you're going to prefix one boolean with a
> verb, prefix all of them with a verb.
>
>
>[/color]

"Aaron [SQL Server MVP]" <ten.xoc@dnartreb.noraa> wrote in message
news:OGpUtBdZEHA.3268@TK2MSFTNGP12.phx.gbl...[color=blue]
>
> But as a column name, I don't think the Is or Has adds anything. You[/color]
still[color=blue]
> can't say WHERE Cat.IsDeclawed, you have to say WHERE Cat.IsDeclawed = 1.
> So it's not even really a boolean / true/false / etc. At best, to be a
> truly compatible boolean, you would have a function that returns True or
> False, and use it like WHERE IsTrue(Cat.Declawed)???[/color]

I agree, it doesn't add anything to a column name. I was referring to
class member naming...

In SQL, were there a boolean datatype, I would actually like it to be
able to resolve to true without a function, so you'd be able to just write:

SELECT *
FROM Cat
WHERE Cat.IsDeclawed

That would create a much nicer mapping between the two worlds in terms
of boolean... And in that case the 'Is' would add something to the column
name :)

"Jay Douglas" <jayREMOVEIFNOTSPAM@squarei.com> wrote in message
news:OcJSIHdZEHA.3664@TK2MSFTNGP12.phx.gbl...[color=blue]
> Adam,
>
> So basically, as a rule of thumb, all boolean fields / proerties /
> columns should be able to fall in to IS, HAS, or USES ...[/color]

While its possible, if your using code that will have to exist with thh
greater .NET community, you should *not* use Is on properties(the general
consensus seems to be that Is fits methods, not properties) and should use
Has or Can only when nessecery; for the most part no prefix is used at all.

For internal code you can probably get away with prefixing your properties,
but it doesn't stand up to the standards imposed by the framework or design
guidelines.
[color=blue]
>
> I think I posted this question all goofy because a lot of reponses are
> referring to T-SQL syntax. This was more of a theroritcal naming
> convention
> question.
>
> Thanks for all of the reponses.
>
> Jay
>
>
> "Adam Machanic" <amachanic@hotmail._removetoemail_.com> wrote in message
> news:uKJTYzcZEHA.1248@TK2MSFTNGP11.phx.gbl...[color=green]
>>
>> "Josh Golden" <joshg@wachovia.com> wrote in message
>> news:40eebcb7$0$82993$39cecf19@news.twtelecom.net. ..[color=darkred]
>> > why not leave the "question" out of the name.
>> >
>> > IsDeclawed goes to Declawed <True-False> <1-0>
>> > DoesHaveWiskers goes to HasWiskers <True-False> <1-0>
>> > DoesUseLitterBox goes to UsesLitterBox <True-False> <1-0>
>> >
>> > am i missing something? why imply datattype in the name?[/color]
>>
>>
>> I like implication of boolean types in the name as it allows one to[/color]
> ask[color=green]
>> a question of an object:
>>
>> if (......)
>> Cat.UsesLitterBox
>> Cat.IsDeclawed
>> Cat.HasWhiskers
>>
>> So: if Cat Uses Litter Box, do X... if Cat Is Declawed, do Y... etc.
>>
>> It would make no sense to ask:
>>
>> if Cat.LitterBox //Is this a reference to a litterbox object?
>>
>> or if Cat Declawed //was this written by someone who is just learning
>> English? :)
>>
>> Finally, is not in the same form as UsesLitterBox (verb-noun or
>> verb-adjective); in my opinion the most important aspect of any naming
>> scheme is consistency. So if you're going to prefix one boolean with a
>> verb, prefix all of them with a verb.
>>
>>
>>[/color]
>
>[/color]

> I agree, it doesn't add anything to a column name. I was referring to[color=blue]
> class member naming...[/color]

Oh, I didn't know we were talking about that. Suppose I shouldn't jump in
mid-thread. ;-)
[color=blue]
> In SQL, were there a boolean datatype, I would actually like it to be
> able to resolve to true without a function, so you'd be able to just[/color]
write:[color=blue]
>
> SELECT *
> FROM Cat
> WHERE Cat.IsDeclawed[/color]

Yes of course, ideally. But there's not, so you wouldn't name your column
that way. ;-)

--
http://www.aspfaq.com/
(Reverse address to reply.)

"Jay Douglas" <jayREMOVEIFNOTSPAM@squarei.com> wrote in message
news:OcJSIHdZEHA.3664@TK2MSFTNGP12.phx.gbl...[color=blue]
>
> So basically, as a rule of thumb, all boolean fields / proerties /
> columns should be able to fall in to IS, HAS, or USES ...[/color]

For objects, use verbs. As other posters have pointed out, it's probably
better to not use verbs/imply data type in a database (I was referring only
to objects in my post).

I believe that the following list of verbs would be sufficient for all
possible cases:

CAN
COULD
DID
DOES
IS
HAS
HAD
MAY
MIGHT
MUST
SHALL
SHOULD
WAS
WILL
WOULD

Daniel,

Do you have a link for Microsoft's suggested C# naming conventions?

"Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
message news:eVXPhMdZEHA.2544@TK2MSFTNGP10.phx.gbl...[color=blue]
>
> For internal code you can probably get away with prefixing your[/color]
properties,[color=blue]
> but it doesn't stand up to the standards imposed by the framework or[/color]
design[color=blue]
> guidelines.[/color]

I think that giving the name something meaningful to suggest Yes/No values
has merit.

he is not suggesting naming these things blnHasChoppers That would TRUELY
Suck

GAJ

Daniel,
You have spawn an interesting concept ... has the FCL uses Is and Has in
various different properties .. (i.e. a DataTable has a property of HasRows
which is a boolean property) .. This is some awesome information and I would
like to adhear to the standards ... whatever those may be. As Adam
requested, I would be very interested in looking at a link or Microsoft
provided document.

"Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
message news:eVXPhMdZEHA.2544@TK2MSFTNGP10.phx.gbl...[color=blue]
>
> "Jay Douglas" <jayREMOVEIFNOTSPAM@squarei.com> wrote in message
> news:OcJSIHdZEHA.3664@TK2MSFTNGP12.phx.gbl...[color=green]
> > Adam,
> >
> > So basically, as a rule of thumb, all boolean fields / proerties /
> > columns should be able to fall in to IS, HAS, or USES ...[/color]
>
> While its possible, if your using code that will have to exist with thh
> greater .NET community, you should *not* use Is on properties(the general
> consensus seems to be that Is fits methods, not properties) and should use
> Has or Can only when nessecery; for the most part no prefix is used at[/color]
all.[color=blue]
>
> For internal code you can probably get away with prefixing your[/color]
properties,[color=blue]
> but it doesn't stand up to the standards imposed by the framework or[/color]
design[color=blue]
> guidelines.
>[color=green]
> >
> > I think I posted this question all goofy because a lot of reponses are
> > referring to T-SQL syntax. This was more of a theroritcal naming
> > convention
> > question.
> >
> > Thanks for all of the reponses.
> >
> > Jay
> >
> >
> > "Adam Machanic" <amachanic@hotmail._removetoemail_.com> wrote in message
> > news:uKJTYzcZEHA.1248@TK2MSFTNGP11.phx.gbl...[color=darkred]
> >>
> >> "Josh Golden" <joshg@wachovia.com> wrote in message
> >> news:40eebcb7$0$82993$39cecf19@news.twtelecom.net. ..
> >> > why not leave the "question" out of the name.
> >> >
> >> > IsDeclawed goes to Declawed <True-False> <1-0>
> >> > DoesHaveWiskers goes to HasWiskers <True-False> <1-0>
> >> > DoesUseLitterBox goes to UsesLitterBox <True-False> <1-0>
> >> >
> >> > am i missing something? why imply datattype in the name?
> >>
> >>
> >> I like implication of boolean types in the name as it allows one to[/color]
> > ask[color=darkred]
> >> a question of an object:
> >>
> >> if (......)
> >> Cat.UsesLitterBox
> >> Cat.IsDeclawed
> >> Cat.HasWhiskers
> >>
> >> So: if Cat Uses Litter Box, do X... if Cat Is Declawed, do Y...[/color][/color][/color]
etc.[color=blue][color=green][color=darkred]
> >>
> >> It would make no sense to ask:
> >>
> >> if Cat.LitterBox //Is this a reference to a litterbox object?
> >>
> >> or if Cat Declawed //was this written by someone who is just[/color][/color][/color]
learning[color=blue][color=green][color=darkred]
> >> English? :)
> >>
> >> Finally, is not in the same form as UsesLitterBox (verb-noun or
> >> verb-adjective); in my opinion the most important aspect of any naming
> >> scheme is consistency. So if you're going to prefix one boolean with a
> >> verb, prefix all of them with a verb.
> >>
> >>
> >>[/color]
> >
> >[/color]
>
>[/color]

"Adam Machanic" <amachanic@hotmail._removetoemail_.com> wrote in message
news:%23iyAVQdZEHA.996@TK2MSFTNGP12.phx.gbl...[color=blue]
> Daniel,
>
> Do you have a link for Microsoft's suggested C# naming conventions?[/color]

Here are a few. I'm pretty sure there is a single page with a table
containing most of these suggestions, but I can't remember what it is.

relevent to properties specifically:
http://msdn.microsoft.com/library/de...guidelines.asp

Note that it suggests naming properties with nouns or noun prhases, not
verbs or verb phrases. Keeping verbs out of properties is generally
prefferable(I would break the is rule, for example, only to keep from naming
a field one of the reserved words, ie instead of Short I'd probably call it
IsShort). Some examples in the BCL use Can and Has, though I can't think of
an instance of Is.

This is only a smattering of the preferences, there is quite alot of
community discussion over proper conventions. I'll post links when I come
across them, dont have time right now to crawl blogs and newsgroups to find
them, ;).

The general guidelines:
http://msdn.microsoft.com/library/de...guidelines.asp

Hopefully someone will be able to provide a link. I'm pretty sure atleast
one person here has the tinyurl memorized by now.[color=blue]
>
>
> "Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
> message news:eVXPhMdZEHA.2544@TK2MSFTNGP10.phx.gbl...[color=green]
>>
>> For internal code you can probably get away with prefixing your[/color]
> properties,[color=green]
>> but it doesn't stand up to the standards imposed by the framework or[/color]
> design[color=green]
>> guidelines.[/color]
>
>[/color]

This isn't directed towards you Josh, just an expansion on your comments.

We don't use bit fields, to signify a boolean value, we use varchar(1) with
Y/N. (char(1) would also work...)

For example:

IsDeclawed goes to DeclawedFg (true-false) (Y-N)
DoesHaveWiskers goes to HasWiskersFg or WiskersFg (true-false) (Y-N)
DoesUseLitterBox goes to UsesLitterBoxFg or LitterBoxFg (true-false) (Y-N)

Basically the "Fg" signifies a Y/N field. Might not be the best way but it
works.

But of course the database doesn't care about what it is named. It is only
for the programmers.

"Josh Golden" <joshg@wachovia.com> wrote in message
news:40eebcb7$0$82993$39cecf19@news.twtelecom.net. ..[color=blue]
> why not leave the "question" out of the name.
>
> IsDeclawed goes to Declawed <True-False> <1-0>
> DoesHaveWiskers goes to HasWiskers <True-False> <1-0>
> DoesUseLitterBox goes to UsesLitterBox <True-False> <1-0>
>
> am i missing something? why imply datattype in the name?
>
>
>
> news.microsoft.com wrote:[color=green]
> > Greetings,
> > I am posting this message to both the SQL Server and C# news
> > groups because this inquiry is more of a theoretical question that
> > applies to both database and code naming conventions.
> >
> > I have currently been prefixing boolean object properties and database
> > columns with Is .. for example (defining a CAT being declawed):
> > IsDeclawed. Well, the prefix of Is doesn't always work ... for
> > example: IsHasWiskers .. well, that doesn't really sound all that
> > great. Also, IsUsesLitterBox . that doesn't sound good either.
> >
> > So what I'm asking the development community is what are the standard
> > naming conventions for boolean fields?
> >
> > Thanks for your time.[/color]
>
>[/color]

"Jay Douglas" <jayREMOVEIFNOTSPAM@squarei.com> wrote in message
news:OGu4WWdZEHA.384@TK2MSFTNGP10.phx.gbl...[color=blue]
> Daniel,
> You have spawn an interesting concept ... has the FCL uses Is and Has
> in
> various different properties .. (i.e. a DataTable has a property of
> HasRows
> which is a boolean property) .. This is some awesome information and I
> would
> like to adhear to the standards ... whatever those may be. As Adam
> requested, I would be very interested in looking at a link or Microsoft
> provided document.[/color]

Is, Has, and Can are pretty common I think. There was a discussion about it
at [1], and I seem to recall a few other instances(I"ll have to look it up).
Is is an example of things that are not covered in the guidelines but by
more community consensus. When I wrote my original response I did think that
Brad Abrams had mentinoed a modification to the design guidelines, but I
can't seem to find that anywhere, so it seems I was mistaken in that
respect.

1. http://blogs.msdn.com/brada/archive/.../16/74563.aspx[color=blue]
>
> "Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
> message news:eVXPhMdZEHA.2544@TK2MSFTNGP10.phx.gbl...[color=green]
>>
>> "Jay Douglas" <jayREMOVEIFNOTSPAM@squarei.com> wrote in message
>> news:OcJSIHdZEHA.3664@TK2MSFTNGP12.phx.gbl...[color=darkred]
>> > Adam,
>> >
>> > So basically, as a rule of thumb, all boolean fields / proerties /
>> > columns should be able to fall in to IS, HAS, or USES ...[/color]
>>
>> While its possible, if your using code that will have to exist with thh
>> greater .NET community, you should *not* use Is on properties(the general
>> consensus seems to be that Is fits methods, not properties) and should
>> use
>> Has or Can only when nessecery; for the most part no prefix is used at[/color]
> all.[color=green]
>>
>> For internal code you can probably get away with prefixing your[/color]
> properties,[color=green]
>> but it doesn't stand up to the standards imposed by the framework or[/color]
> design[color=green]
>> guidelines.
>>[color=darkred]
>> >
>> > I think I posted this question all goofy because a lot of reponses are
>> > referring to T-SQL syntax. This was more of a theroritcal naming
>> > convention
>> > question.
>> >
>> > Thanks for all of the reponses.
>> >
>> > Jay
>> >
>> >
>> > "Adam Machanic" <amachanic@hotmail._removetoemail_.com> wrote in
>> > message
>> > news:uKJTYzcZEHA.1248@TK2MSFTNGP11.phx.gbl...
>> >>
>> >> "Josh Golden" <joshg@wachovia.com> wrote in message
>> >> news:40eebcb7$0$82993$39cecf19@news.twtelecom.net. ..
>> >> > why not leave the "question" out of the name.
>> >> >
>> >> > IsDeclawed goes to Declawed <True-False> <1-0>
>> >> > DoesHaveWiskers goes to HasWiskers <True-False> <1-0>
>> >> > DoesUseLitterBox goes to UsesLitterBox <True-False> <1-0>
>> >> >
>> >> > am i missing something? why imply datattype in the name?
>> >>
>> >>
>> >> I like implication of boolean types in the name as it allows one
>> >> to
>> > ask
>> >> a question of an object:
>> >>
>> >> if (......)
>> >> Cat.UsesLitterBox
>> >> Cat.IsDeclawed
>> >> Cat.HasWhiskers
>> >>
>> >> So: if Cat Uses Litter Box, do X... if Cat Is Declawed, do Y...[/color][/color]
> etc.[color=green][color=darkred]
>> >>
>> >> It would make no sense to ask:
>> >>
>> >> if Cat.LitterBox //Is this a reference to a litterbox object?
>> >>
>> >> or if Cat Declawed //was this written by someone who is just[/color][/color]
> learning[color=green][color=darkred]
>> >> English? :)
>> >>
>> >> Finally, is not in the same form as UsesLitterBox (verb-noun or
>> >> verb-adjective); in my opinion the most important aspect of any naming
>> >> scheme is consistency. So if you're going to prefix one boolean with
>> >> a
>> >> verb, prefix all of them with a verb.
>> >>
>> >>
>> >>
>> >
>> >[/color]
>>
>>[/color]
>
>[/color]

"Daniel Jin" <DanielJin@discussions.microsoft.com> wrote in message
news:11FA3630-C34F-4115-AD92-BFDD15E0CE8C@microsoft.com...[color=blue][color=green]
>>
>> While its possible, if your using code that will have to exist with thh
>> greater .NET community, you should *not* use Is on properties(the general
>> consensus seems to be that Is fits methods, not properties) and should
>> use
>> Has or Can only when nessecery; for the most part no prefix is used at
>> all.
>>[/color]
>
> if you look at BCL, there are quite a few examples of bool properties
> prefixed with is. If MS uses it, it's good enough for me. :)[/color]

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.

I could probably spend the rest of the month picking about minor bits in the
BCL that don't fit the naming guidelines if I wanted to. That doesn't mean I
would use any one of them just because Microsoft did.

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

"Adam Machanic" <amachanic@hotmail._removetoemail_.com> wrote in message
news:uPD4EOdZEHA.2216@TK2MSFTNGP10.phx.gbl...[color=blue]
>
> "Jay Douglas" <jayREMOVEIFNOTSPAM@squarei.com> wrote in message
> news:OcJSIHdZEHA.3664@TK2MSFTNGP12.phx.gbl...[color=green]
> >
> > So basically, as a rule of thumb, all boolean fields / proerties /
> > columns should be able to fall in to IS, HAS, or USES ...[/color]
>
> For objects, use verbs. As other posters have pointed out, it's probably
> better to not use verbs/imply data type in a database (I was referring[/color]
only[color=blue]
> to objects in my post).
>
> I believe that the following list of verbs would be sufficient for all
> possible cases:
>
> CAN
> COULD
> DID
> DOES
> IS
> HAS
> HAD
> MAY
> MIGHT
> MUST
> SHALL
> SHOULD
> WAS
> WILL
> WOULD
>
>[/color]

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"
<(RE-M0V3)steveb@path(RE-M0V3)guide.com(RE-M0VE--THE-REST)nospam@sp4m.com>
wrote in message news:ux1USedZEHA.2520@TK2MSFTNGP12.phx.gbl...[color=blue]
> This isn't directed towards you Josh, just an expansion on your comments.
>
> We don't use bit fields, to signify a boolean value, we use varchar(1)[/color]
with[color=blue]
> Y/N. (char(1) would also work...)
>
> For example:
>
> IsDeclawed goes to DeclawedFg (true-false) (Y-N)
> DoesHaveWiskers goes to HasWiskersFg or WiskersFg (true-false) (Y-N)
> DoesUseLitterBox goes to UsesLitterBoxFg or LitterBoxFg (true-false)[/color]
(Y-N)[color=blue]
>
> Basically the "Fg" signifies a Y/N field. Might not be the best way but[/color]
it[color=blue]
> works.
>
> But of course the database doesn't care about what it is named. It is[/color]
only[color=blue]
> for the programmers.
>
>
> "Josh Golden" <joshg@wachovia.com> wrote in message
> news:40eebcb7$0$82993$39cecf19@news.twtelecom.net. ..[color=green]
> > why not leave the "question" out of the name.
> >
> > IsDeclawed goes to Declawed <True-False> <1-0>
> > DoesHaveWiskers goes to HasWiskers <True-False> <1-0>
> > DoesUseLitterBox goes to UsesLitterBox <True-False> <1-0>
> >
> > am i missing something? why imply datattype in the name?
> >
> >
> >
> > news.microsoft.com wrote:[color=darkred]
> > > Greetings,
> > > I am posting this message to both the SQL Server and C# news
> > > groups because this inquiry is more of a theoretical question that
> > > applies to both database and code naming conventions.
> > >
> > > I have currently been prefixing boolean object properties and database
> > > columns with Is .. for example (defining a CAT being declawed):
> > > IsDeclawed. Well, the prefix of Is doesn't always work ... for
> > > example: IsHasWiskers .. well, that doesn't really sound all that
> > > great. Also, IsUsesLitterBox . that doesn't sound good either.
> > >
> > > So what I'm asking the development community is what are the standard
> > > naming conventions for boolean fields?
> > >
> > > Thanks for your time.[/color]
> >
> >[/color]
>
>[/color]

> Yuck ! why not simply use bit. ?? I mean if it is only for the[color=blue]
> programmers then a bit 1 or 0 makes more sense[/color]

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.
[color=blue]
> Theoretically a Char(1) can contain other characters beside Y or N so now
> 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.)

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.

"james" <nospam@hypercon.net> wrote in message
news:Ol7fW2dZEHA.3692@TK2MSFTNGP09.phx.gbl...[color=blue]
> 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[/color]

>> 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.
[color=blue][color=green]
>> so now you need all kinds of overhead to verify data integrity <<[/color][/color]

In t-SQL, simple CHECK constraint would do.

--
Anith

> 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').

--
http://www.aspfaq.com/
(Reverse address to reply.)

"Aaron [SQL Server MVP]" <ten.xoc@dnartreb.noraa> wrote in message
news:uoGcNAeZEHA.2840@TK2MSFTNGP11.phx.gbl...[color=blue][color=green]
> > BIT has other issues, e.g. it can't be included in an index.[/color]
>
> 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).[/color]

Thanks for the clarification. I stopped implementing BIT columns around
the same time I stopped using EM :)
[color=blue]
> 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').[/color]

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[color=blue][color=green]
> > CHAR(1) column, where the values must be IN ('Y', 'N').[/color]
>
> Even an index on a CHAR(1) column could be useful if either the number
> of 'Y' or 'N' occurrences was fairly sparse...[/color]

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 [C# MVP]" wrote:[color=blue]
> "Daniel Jin" wrote:
>[color=green]
> >
> > if you look at BCL, there are quite a few examples
> > of bool properties prefixed with is. If MS uses it,
> > it's good enough for me. :)[/color]
>
> 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.[/color]

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.
[color=blue]
> That doesn't mean I would use any one of them just because
> Microsoft did.[/color]

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

"Wavemaker" <jabberdabber@BiteMeHotmail.com> wrote in message
news:QOSdnU0aI7vwcHPdRVn-hQ@comcast.com...[color=blue]
>
> "Daniel O'Connell [C# MVP]" wrote:[color=green]
> > "Daniel Jin" wrote:
> >[color=darkred]
> > >
> > > if you look at BCL, there are quite a few examples
> > > of bool properties prefixed with is. If MS uses it,
> > > it's good enough for me. :)[/color]
> >
> > 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.[/color]
>
> 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.
>[color=green]
> > That doesn't mean I would use any one of them just because
> > Microsoft did.[/color]
>
> Your point is well taken. I will give this some thought.
>
>[/color]

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@dnartreb.noraa> wrote in message
news:OqGJB5dZEHA.3512@TK2MSFTNGP12.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]

> 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.

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@dnartreb.noraa> wrote in message
news:%23HzAP7BaEHA.2972@TK2MSFTNGP12.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]

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@hypercon.net> wrote in message
news:uAtiaCCaEHA.3692@TK2MSFTNGP09.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@dnartreb.noraa> wrote in message
> news:%23HzAP7BaEHA.2972@TK2MSFTNGP12.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]

;-)

"Steve Beach"
<(RE-M0V3)steveb@path(RE-M0V3)guide.com(RE-M0VE--THE-REST)nospam@sp4m.com>
wrote in message news:%23hJFdHDaEHA.2296@TK2MSFTNGP10.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@hypercon.net> wrote in message
> news:uAtiaCCaEHA.3692@TK2MSFTNGP09.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@dnartreb.noraa> wrote in message
> > news:%23HzAP7BaEHA.2972@TK2MSFTNGP12.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]

"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.IsActive = false
>
> and
>
> if ( Employee.IsActive ) ...
>
>
> 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.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

"Wavemaker" <jabberdabber@BiteMeHotmail.com> wrote in message
news:keednSmIEKq2smnd4p2dnA@comcast.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.IsActive = false
> >
> > and
> >
> > if ( Employee.IsActive ) ...
> >
> >
> > 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.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.
>
>[/color]

>> 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--" <jcelko212@earthlink.net> wrote in message
news:18c7b3c2.0407181157.1639d6b7@posting.google.c om...[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]

Boolean Naming Conventions

re: Boolean Naming Conventions

re: Boolean Naming Conventions

re: Boolean Naming Conventions

re: Boolean Naming Conventions

re: Boolean Naming Conventions

re: Boolean Naming Conventions

re: Boolean Naming Conventions

re: Boolean Naming Conventions

re: Boolean Naming Conventions

re: Boolean Naming Conventions

re: Boolean Naming Conventions

re: Boolean Naming Conventions

re: Boolean Naming Conventions

re: Boolean Naming Conventions

re: Boolean Naming Conventions

re: Boolean Naming Conventions

re: Boolean Naming Conventions

re: Boolean Naming Conventions

re: Boolean Naming Conventions

re: Boolean Naming Conventions

re: Boolean Naming Conventions

re: Boolean Naming Conventions

re: Boolean Naming Conventions

re: Boolean Naming Conventions

re: Boolean Naming Conventions

re: Boolean Naming Conventions

re: Boolean Naming Conventions

re: Boolean Naming Conventions

re: Boolean Naming Conventions

re: Boolean Naming Conventions

re: Boolean Naming Conventions

re: Boolean Naming Conventions

re: Boolean Naming Conventions

re: Boolean Naming Conventions

re: Boolean Naming Conventions

re: Boolean Naming Conventions

re: Boolean Naming Conventions

re: Boolean Naming Conventions

Similar C# / C Sharp bytes

/bytes/development

/bytes/it

/bytes/about