What is the standard for naming objects?

  • Thread starter Thread starter rsine
  • Start date Start date
R

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
 
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
 
Hello (e-mail address removed),

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
 
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
 
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 said:
Hello (e-mail address removed),

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

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
Click to expand...

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.
Click to expand...

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
Click to expand...

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)
Click to expand...

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
Click to expand...

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

Dim age As Byte
 
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.
Click to expand...

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
 
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
 
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
 
Hello (e-mail address removed),

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
 
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 ?
Click to expand...

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?
Click to expand...

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, ...
Click to expand...

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, ...
Click to expand...

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
Click to expand...

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).
Click to expand...

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.

-Bo
 
GhostInAK said:
Hello (e-mail address removed),

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.
Click to expand...

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.)
 
Thanks guys,

Cor

Jon Skeet said:
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.)
Click to expand...
 
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
 
I take it that you used the Dispose method of the Body class? ;)
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
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.)
Click to expand...
Click to expand...
 
Back
Top