What is the standard for naming objects?

[rsine]

I did a recent post about what the standard was for naming a string
builder object. My concern was that I did not what to use "str" prefix
since this is used for strings but did not know what to use in its
place. A few responses I received indicated such prefixing is no
longer necessary in .Net and should be abandoned. Is this the correct
approach? I am striving hard to make sure I use best practices in my
code.

-Thanks

[Cor Ligthert [MVP]]

Rsine,

The languages don't need it. But there is nobody who can say you should not
use it.

Although I see it seldom used in these newsgroups, where I am than talking
about VB.

However try than as well than to avoid not necessary global declarations and
even try to declare fields as tight as where they are needed.

But just my thought about it.

Cor

<rs***@stationeryhouse.com> schreef in bericht
news:11**********************@i40g2000cwc.googlegr oups.com...

I did a recent post about what the standard was for naming a string
builder object. My concern was that I did not what to use "str" prefix
since this is used for strings but did not know what to use in its
place. A few responses I received indicated such prefixing is no
longer necessary in .Net and should be abandoned. Is this the correct
approach? I am striving hard to make sure I use best practices in my
code.

-Thanks

[GhostInAK]

Hello rs***@stationeryhouse.com,

I've come up with one I particularly like.. feel free to use, abuse, bash,
hate, maim and mangle it:

I use VB primarily so my examples will be in that, however it seems to work
well for just about any language with minor modifications to allow for syntax.

First, a few rules:
1. Member variables will never be exposed directly, but rather they will
be exposed through properties.
Convention:
First and foremost all variables will have descriptive names. When the prefix
(see below) is not enough to determin an object's type (object) then the
variable name should pick up the slack.
Example: an object that holds a date representing the day someone fell down
drunk in the ditch might be named: oDrunkInDitchDate

First.5: All identifiers will capitalize the first letter of each independant
word that makes up the identifier.
Example: A method for making the dog bark could be called: MakeDogBark(),
or BarkTheDog().
It would not be: makeDogBark(), makedogbark(), makedogBark(), etc.

Second: member variables, and, godforbid, global variables (vb varaibles
declared public in a module, YECH!) shall be prefaced with a single character:

o - objects which are not covered below
s - string
b - boolean
i - any numeric datatype (came from Integer, but I found that I do not
need to distinguish numeric data types.. so i stuck as the prefix)

Examples: storing someone's age in a byte: Dim iAge As Byte
storing a flag to determin if we should stop something: Dim bStop As
Boolean
a combobox on a WinForm for selecting a color of carpet: oCarpetColorCombo

Third: all locally scoped variables (function arguments, variables declared
within a function, etc) are to be prefixed with t.
t stands for temerary. There is no need for data typing on local variables
because functions/properties/etc are usually small enough that you can refer
to the data type by simply looking up a few lines. One should never try
to modify a function without first reading and understanding it in its entirety
so the lack of data type in the prefix is not a problem for maintenance programmers
either.

Thats pretty much it.

-Boo

I did a recent post about what the standard was for naming a string
builder object. My concern was that I did not what to use "str"
prefix since this is used for strings but did not know what to use in
its place. A few responses I received indicated such prefixing is no
longer necessary in .Net and should be abandoned. Is this the correct
approach? I am striving hard to make sure I use best practices in my
code.

-Thanks

[R. MacDonald]

Hello, rsine,

I agree with Cor. I have found three letter "type prefix" conventions
to be very useful in languages I have used previously, but there is not
much advantage to these in .Net and in any sizable project there are far
too many types to be able to remember the prefixes for all of them.

In .Net the scope of most local names is very narrow, and the IDE
provides very good information about them. But I'm still inclined to
use some convention to denote wider scope names (e.g. private class
variables and the occasional global) but so far I haven't determined
what it should be.

Cheers,
Randy
Cor Ligthert [MVP] wrote:

Rsine,

The languages don't need it. But there is nobody who can say you should not
use it.

Although I see it seldom used in these newsgroups, where I am than talking
about VB.

However try than as well than to avoid not necessary global declarations and
even try to declare fields as tight as where they are needed.

But just my thought about it.

Cor

<rs***@stationeryhouse.com> schreef in bericht
news:11**********************@i40g2000cwc.googlegr oups.com...

I did a recent post about what the standard was for naming a string
builder object. My concern was that I did not what to use "str" prefix
since this is used for strings but did not know what to use in its
place. A few responses I received indicated such prefixing is no
longer necessary in .Net and should be abandoned. Is this the correct
approach? I am striving hard to make sure I use best practices in my
code.

-Thanks

[Joris Zwaenepoel]

Hi,

If these prefixes work for you, that's fine, but I wouldn't recommend them
to others.
It is just so easy to give your variables a good name, and the prefix will
most of the time not add any value.

(Please do not use "i" as a prefix for numeric values like decimal, single,
double. That could be very confusing.)

A few examples
- a string variable that holds an SQL statement: sql / strSql / sSql ?
- a boolean variable: isRequired / bRequired?
- a numeric variable: value / iValue / numValue / dblValue?

I don't think you need any help guessing the datatype for clearly names
variables, like firstName, lastName, birthDate, isMarried, numberOfChildren,
emailAddress, ...

Sometimes you will need some help, for example if you see "sql" as a
variable name, how do you know what type it is (string or stringbuilder)?
The IDE will help you: tooltips in de code editor, intellisense while typing,
....

I used to use prefixes in VB6, and it took only a little time getting used
to the new style, but I soon found that using no prefixes makes the code more
readable.

I have 2 exceptions to the "no prefix" rule:
- for UI controls, I still use them: txtFirstName, chkIsMarried, ... because
it makes it easier to distinguish controls from variables and procedures
- an underscore charater as a prefix for "member"-variables (private, class
scope), but no prefix for function arguments and local variables (and I don't
use global variables).

Joris

"GhostInAK" wrote:

Hello rs***@stationeryhouse.com,

I've come up with one I particularly like.. feel free to use, abuse, bash,
hate, maim and mangle it:
.... Second: member variables, and, godforbid, global variables (vb varaibles
declared public in a module, YECH!) shall be prefaced with a single character:

o - objects which are not covered below
s - string
b - boolean
i - any numeric datatype (came from Integer, but I found that I do not
need to distinguish numeric data types.. so i stuck as the prefix)
.... Third: all locally scoped variables (function arguments, variables declared
within a function, etc) are to be prefixed with t.
t stands for temerary. There is no need for data typing on local variables
because functions/properties/etc are usually small enough that you can refer
to the data type by simply looking up a few lines. ... -Boo

[Chris Dunaway]

GhostInAK wrote:

Hello rs***@stationeryhouse.com,

I've come up with one I particularly like.. feel free to use, abuse, bash,
hate, maim and mangle it:
Yeah this is one of those "religious" areas of programming in which
everyone has their personal preferences and everyone else is going to
Hell! :)

Convention:
First and foremost all variables will have descriptive names. When the prefix
(see below) is not enough to determin an object's type (object) then the
variable name should pick up the slack.
Example: an object that holds a date representing the day someone fell down
drunk in the ditch might be named: oDrunkInDitchDate
This I completely agree with. If the variable name is descriptive
enough, then specifying the type in the variable name is not that
important.

First.5: All identifiers will capitalize the first letter of each independant
word that makes up the identifier.
Example: A method for making the dog bark could be called: MakeDogBark(),
or BarkTheDog().
It would not be: makeDogBark(), makedogbark(), makedogBark(), etc.
I agree with this somewhat. If the method is a private class method,
then I leave the first letter of the first word in lower case. If the
method is public, then I do as you say.

Second: member variables, and, godforbid, global variables (vb varaibles
declared public in a module, YECH!) shall be prefaced with a single character:

o - objects which are not covered below
s - string
b - boolean
For private member variables that are class level variables, I prefix
them with an underscore as in: _variableName

For variables local to a method, I leave them all lower case and tend
to use shorter names. I will sometimes use a single character name for
a tmp variable such as:

Dim s As String.

But only if I know if I will not use the variable more than a few lines
later.
i - any numeric datatype (came from Integer, but I found that I do not
need to distinguish numeric data types.. so i stuck as the prefix)
I have to disagree with this. I also think this is confusing.

Examples: storing someone's age in a byte: Dim iAge As Byte
storing a flag to determin if we should stop something: Dim bStop As
Boolean
a combobox on a WinForm for selecting a color of carpet: oCarpetColorCombo

If the variable is local to a method, I tend to use all lower case:

Dim age As Byte

[Chris Dunaway]

rs***@stationeryhouse.com wrote:

longer necessary in .Net and should be abandoned. Is this the correct
approach? I am striving hard to make sure I use best practices in my
code.

As you can see from the various replies, there is no standard
convention. The best practice would to use something that is logical,
that you understand, and then be consistent about using it.

Chris

[Cor Ligthert [MVP]]

Chris,

I can completely agree with what Joris wrote, except that I hate the
underscore, there are places you don't see that underscore on screen, I use
forever a "m" in that case, why, I would not know, probably a "p" would be
better to tell that it is a private variable which is accessed by a
property; so it is very limitid in the place and use in a program. (Right
above the property).

For the rest: I have ever hated prefixes, it makes programs less readable.

But feel free to do it your way.

Cor

"Chris Dunaway" <du******@gmail.com> schreef in bericht
news:11**********************@b68g2000cwa.googlegr oups.com...

GhostInAK wrote:

Hello rs***@stationeryhouse.com,

I've come up with one I particularly like.. feel free to use, abuse,
bash,
hate, maim and mangle it:

Yeah this is one of those "religious" areas of programming in which
everyone has their personal preferences and everyone else is going to
Hell! :)

Convention:
First and foremost all variables will have descriptive names. When the
prefix
(see below) is not enough to determin an object's type (object) then the
variable name should pick up the slack.
Example: an object that holds a date representing the day someone fell
down
drunk in the ditch might be named: oDrunkInDitchDate

This I completely agree with. If the variable name is descriptive
enough, then specifying the type in the variable name is not that
important.

First.5: All identifiers will capitalize the first letter of each
independant
word that makes up the identifier.
Example: A method for making the dog bark could be called:
MakeDogBark(),
or BarkTheDog().
It would not be: makeDogBark(), makedogbark(), makedogBark(), etc.

I agree with this somewhat. If the method is a private class method,
then I leave the first letter of the first word in lower case. If the
method is public, then I do as you say.

Second: member variables, and, godforbid, global variables (vb varaibles
declared public in a module, YECH!) shall be prefaced with a single
character:

o - objects which are not covered below
s - string
b - boolean

For private member variables that are class level variables, I prefix
them with an underscore as in: _variableName

For variables local to a method, I leave them all lower case and tend
to use shorter names. I will sometimes use a single character name for
a tmp variable such as:

Dim s As String.

But only if I know if I will not use the variable more than a few lines
later.

i - any numeric datatype (came from Integer, but I found that I do not
need to distinguish numeric data types.. so i stuck as the prefix)

I have to disagree with this. I also think this is confusing.

Examples: storing someone's age in a byte: Dim iAge As Byte
storing a flag to determin if we should stop something: Dim bStop As
Boolean
a combobox on a WinForm for selecting a color of carpet:
oCarpetColorCombo

If the variable is local to a method, I tend to use all lower case:

Dim age As Byte

[R. MacDonald]

Hello, Cor,

I also use "m". (I've used it for so long that I've forgotten it's
origin. Perhaps it stands for "module scope", but I'm just guessing.)
I think that it is better than "p", because I've seen some programmers
use "p" for "private" and others use "p" for "public".

And (unlike Joris) I do, on rare occasions use a global. I give these a
prefix of "g".

Groetjes,
Randy
Cor Ligthert [MVP] wrote:

Chris,

I can completely agree with what Joris wrote, except that I hate the
underscore, there are places you don't see that underscore on screen, I use
forever a "m" in that case, why, I would not know, probably a "p" would be
better to tell that it is a private variable which is accessed by a
property; so it is very limitid in the place and use in a program. (Right
above the property).

For the rest: I have ever hated prefixes, it makes programs less readable.

But feel free to do it your way.

Cor

"Chris Dunaway" <du******@gmail.com> schreef in bericht
news:11**********************@b68g2000cwa.googlegr oups.com...

GhostInAK wrote:

Hello rs***@stationeryhouse.com,

I've come up with one I particularly like.. feel free to use, abuse,
bash,
hate, maim and mangle it:

Yeah this is one of those "religious" areas of programming in which
everyone has their personal preferences and everyone else is going to
Hell! :)

Convention:
First and foremost all variables will have descriptive names. When the
prefix
(see below) is not enough to determin an object's type (object) then the
variable name should pick up the slack.
Example: an object that holds a date representing the day someone fell
down
drunk in the ditch might be named: oDrunkInDitchDate

This I completely agree with. If the variable name is descriptive
enough, then specifying the type in the variable name is not that
important.

First.5: All identifiers will capitalize the first letter of each
independant
word that makes up the identifier.
Example: A method for making the dog bark could be called:
MakeDogBark(),
or BarkTheDog().
It would not be: makeDogBark(), makedogbark(), makedogBark(), etc.

I agree with this somewhat. If the method is a private class method,
then I leave the first letter of the first word in lower case. If the
method is public, then I do as you say.

Second: member variables, and, godforbid, global variables (vb varaibles
declared public in a module, YECH!) shall be prefaced with a single
character:

o - objects which are not covered below
s - string
b - boolean

For private member variables that are class level variables, I prefix
them with an underscore as in: _variableName

For variables local to a method, I leave them all lower case and tend
to use shorter names. I will sometimes use a single character name for
a tmp variable such as:

Dim s As String.

But only if I know if I will not use the variable more than a few lines
later.

i - any numeric datatype (came from Integer, but I found that I do not
need to distinguish numeric data types.. so i stuck as the prefix)

I have to disagree with this. I also think this is confusing.

Examples: storing someone's age in a byte: Dim iAge As Byte
storing a flag to determin if we should stop something: Dim bStop As
Boolean
a combobox on a WinForm for selecting a color of carpet:
oCarpetColorCombo

If the variable is local to a method, I tend to use all lower case:

Dim age As Byte

[GhostInAK]

Hello rs***@stationeryhouse.com,

For those of you wondering where the "m" prefix came from that so many of
you use, it used to originally mean member variable and was typically used
to decorate what we now call private fields (class-level private variables)
in .NET.

-Boo

I did a recent post about what the standard was for naming a string
builder object. My concern was that I did not what to use "str"
prefix since this is used for strings but did not know what to use in
its place. A few responses I received indicated such prefixing is no
longer necessary in .Net and should be abandoned. Is this the correct
approach? I am striving hard to make sure I use best practices in my
code.

-Thanks

[GhostInAK]

Hello Joris,

To address a few of your and Chris's questions/comments...

A few examples
- a string variable that holds an SQL statement: sql / strSql / sSql ?
If the variable is class-level then it would be sSql. If the variable is
function-level then it would be tSql.
- a boolean variable: isRequired / bRequired?
As a variable it would be bRequired, or bIsRequired. As a property that
refered to the variable it would be Required, or IsRequired.
I don't think you need any help guessing the datatype for clearly
names variables, like firstName, lastName, birthDate, isMarried,
numberOfChildren, emailAddress, ...
True, hoever.. The point of the prefix is to partially eliminate the need
to guess (think 6 months to a year down the road when you have forgotten
all about this code). Also it is for consistency.
Sometimes you will need some help, for example if you see "sql" as a
variable name, how do you know what type it is (string or
stringbuilder)? The IDE will help you: tooltips in de code editor,
intellisense while typing, ...
In this case it would be oSql for a StringBuilder and sSql for a string.
However I despise using both of those names. oSql doesnt tell me if this
is a StringBuilder, a SqlCommand, or a SqlConnection, etc.. I would probably
choose a name like: oSqlStringBuilder.
I have 2 exceptions to the "no prefix" rule:
- for UI controls, I still use them: txtFirstName, chkIsMarried, ...
because
it makes it easier to distinguish controls from variables and
procedures
I have this habit as well. I've been searching for a way to eliminate this,
but I havent found a good way.. so the habit sticks.
- an underscore charater as a prefix for "member"-variables (private,
class
scope), but no prefix for function arguments and local variables (and
I don't
use global variables).

I absolutely hate the underscore. It makes code very unreadable im my opinion.
as for Chris's comments about the case of the variable names.. I would have
to disagree. I haven't considered the impact to a case-sensitive language
at present, however vb is case-insensitive.. if someone were writing code
in say, notepad or any other editor besides VS.NET, then they could write
cat, Cat, CAT and all mean the same thing..
As others have mentioned, this is mostly personal choice.. just try to remember
that down the road you wont be the only person having to read and modify
this code. Try to choose a convention that others can easily follow as well.

-Boo

[Jon Skeet [C# MVP]]

GhostInAK <gh*******@gmail.com> wrote:

Hello rs***@stationeryhouse.com,

For those of you wondering where the "m" prefix came from that so many of
you use, it used to originally mean member variable and was typically used
to decorate what we now call private fields (class-level private variables)
in .NET.

The privacy doesn't affect whether or not they're member variables -
they're still called member variables, or instance variables, whether
they're public (let's hope not), protected, whatever.

(I'm not recommending anything other than private fields - don't get me
wrong.)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Cor Ligthert [MVP]]

Thanks guys,

Cor

"Jon Skeet [C# MVP]" <sk***@pobox.com> schreef in bericht
news:MP***********************@msnews.microsoft.co m...

GhostInAK <gh*******@gmail.com> wrote:

Hello rs***@stationeryhouse.com,

For those of you wondering where the "m" prefix came from that so many of
you use, it used to originally mean member variable and was typically
used
to decorate what we now call private fields (class-level private
variables)
in .NET.

The privacy doesn't affect whether or not they're member variables -
they're still called member variables, or instance variables, whether
they're public (let's hope not), protected, whatever.

(I'm not recommending anything other than private fields - don't get me
wrong.)

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[GhostInAK]

Hello Jon Skeet [C# MVP],

True, but on the whole I havent noticed many people exposing these "m"-decorated
fields publicly... and the few I have found.. well.. noone will ever find
their bodies.

-Boo

GhostInAK <gh*******@gmail.com> wrote:

Hello rs***@stationeryhouse.com,

For those of you wondering where the "m" prefix came from that so
many of you use, it used to originally mean member variable and was
typically used to decorate what we now call private fields
(class-level private variables) in .NET.

The privacy doesn't affect whether or not they're member variables -
they're still called member variables, or instance variables, whether
they're public (let's hope not), protected, whatever.

(I'm not recommending anything other than private fields - don't get
me wrong.)

[Göran Andersson]

I take it that you used the Dispose method of the Body class? ;)

GhostInAK wrote:

Hello Jon Skeet [C# MVP],

True, but on the whole I havent noticed many people exposing these
"m"-decorated fields publicly... and the few I have found.. well.. noone
will ever find their bodies.

-Boo

>GhostInAK <gh*******@gmail.comwrote:

>>Hello rs***@stationeryhouse.com,

For those of you wondering where the "m" prefix came from that so
many of you use, it used to originally mean member variable and was
typically used to decorate what we now call private fields
(class-level private variables) in .NET.

The privacy doesn't affect whether or not they're member variables -
they're still called member variables, or instance variables, whether
they're public (let's hope not), protected, whatever.

(I'm not recommending anything other than private fields - don't get
me wrong.)