Boolean Naming Conventions

[news.microsoft.com]

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.

 

[Jaxon]

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

IsDeadAsAStick
NeedsToBeSlapped
HasToBeDeaf
MustBeRotten


etc etc etc


Greg Jackson
PDX, Oregon

 

[Josh Golden]

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]

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.

 

[Adam Machanic]

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

 

[Josh Golden]

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"

 

[Josh Golden]

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.

 

[Aaron [SQL Server MVP]]

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

 

[Jay Douglas]

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]

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

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

 

[Daniel O'Connell [C# MVP]]

Adam,

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

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.

 

[Aaron [SQL Server MVP]]

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

class member naming...

Oh, I didn't know we were talking about that. Suppose I shouldn't jump in
mid-thread. ;-)

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

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

 

[Adam Machanic]

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

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

 

[Adam Machanic]

Daniel,

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

 

[Jaxon]

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

 

[Jay Douglas]

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

Daniel,

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

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/d...genref/html/cpconpropertynamingguidelines.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/d...en-us/cpgenref/html/cpconnamingguidelines.asp

Hopefully someone will be able to provide a link. I'm pretty sure atleast
one person here has the tinyurl memorized by now.

 

[Steve Beach]

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.

 

[Daniel O'Connell [C# MVP]]

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.

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/2004/02/16/74563.aspx

 

[Daniel O'Connell [C# MVP]]

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.

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.