Hungarian notation pros vs cons

[Ronald S. Cook]

An ongoing philosophical argument, I would like your opinions. With the
release of .NET, Microsoft spoke of moving away from the notation as a best
practice. I'm a believer for a few reasons:

1) Consistency throughout and knowing which objects are yours
(clsEmployee, tblEmployee, frmEmployee, etc).

2) Not having to name an employee form EmployeeForm.aspx because the
mane is already taken by your class named Employee.cs

3) We once had a major entity "System" in our model. Because it's
reserved name, would have to alias somehow anyway.

4) I just created a form "Login.aspx" in an ASP.NET 2.0 app. That's now
a conflict with the new "Login" control.

Does anyone disagree with using Hungarian notation? If so, I'd be
interested to hear specific bullets of why you don't like it (and also what
you would do to avoid naming conflicts).

Thanks,
Ron

[Mark Ingram]

I like using hungarian notation in old C / C++ code, because the data
types generally have quite short names. However in .NET when you
consider there are types like:

UpDownBase+UpDownButtons+UpDownButtonsAccessibleOb ject+DirectionButtonAccessibleObject
IDataGridColumnStyleEditingNotificationService
(source: http://weblogs.asp.net/rchartier/arc.../05/68350.aspx)

what would your variable look like then?
udbudbudbaodbaoMyVariable
dgcsensMyVariable

They look stupid dont they?

pszName - thats ok because the type fits neatly into 3 characters.

Another reason is to make it more readable, make the code appear just as
you say it. e.g.

Button exitButton = new Button;
vs
Button butExit = new Button;

If you were speaking, you wouldnt say im looking for the "but Exit"
control, you'd say "exit button".


Ronald S. Cook wrote:

An ongoing philosophical argument, I would like your opinions. With the
release of .NET, Microsoft spoke of moving away from the notation as a best
practice. I'm a believer for a few reasons:

1) Consistency throughout and knowing which objects are yours
(clsEmployee, tblEmployee, frmEmployee, etc).

2) Not having to name an employee form EmployeeForm.aspx because the
mane is already taken by your class named Employee.cs

3) We once had a major entity "System" in our model. Because it's
reserved name, would have to alias somehow anyway.

4) I just created a form "Login.aspx" in an ASP.NET 2.0 app. That's now
a conflict with the new "Login" control.

Does anyone disagree with using Hungarian notation? If so, I'd be
interested to hear specific bullets of why you don't like it (and also what
you would do to avoid naming conflicts).

Thanks,
Ron

[Nick Hounsome]

"Ronald S. Cook" <rc***@westinis.com> wrote in message
news:OK*************@TK2MSFTNGP09.phx.gbl...

An ongoing philosophical argument, I would like your opinions. With the
release of .NET, Microsoft spoke of moving away from the notation as a
best practice. I'm a believer for a few reasons:

1) Consistency throughout and knowing which objects are yours
(clsEmployee, tblEmployee, frmEmployee, etc).
How does that tell you what are yours?

There is an argument for prefixing with something related to the subsystem
or class library that is not entirely negated by namespaces but that is not
what is normally understood as being hungarian notation.

2) Not having to name an employee form EmployeeForm.aspx because the
mane is already taken by your class named Employee.cs
But you are going to call it frmEmployee anyway so what have you gained?
3) We once had a major entity "System" in our model. Because it's
reserved name, would have to alias somehow anyway.
Without wishing to flame - any model that has a class called System is
probably not very good and anyway - do you really create your model without
knowing what you are going to implement it in?
4) I just created a form "Login.aspx" in an ASP.NET 2.0 app. That's
now a conflict with the new "Login" control.
Surely it's in a different namespace.

Does anyone disagree with using Hungarian notation?
Well obviously the key .NET people at Microsoft do.
If so, I'd be interested to hear specific bullets of why you don't like it
(and also what you would do to avoid naming conflicts).

It clutters code with characters that convey little or no extra information.
It is inconsistent with any of the existing libraries that you are going to
be using and probably inconsistent with the hungarian notation used by any
other programmer picked at random.

Namespaces and "using" eliminate naming conflicts.

There are a couple of places where I do use prefixes for private fields and
methods ONLY:

1) Event handling methods - these do not form part of the core processing of
the form and hence it helps to declutter class views and intellisense if
they are all kept together so I tend to prefix with Cb for callback.
Anonymous delegates are the better solution to this problem.
2) private helper methods - again this is to separate them in displays from
the public methods.
3) fields holding controls - I haven't got a really good justification for
this - I just find it helpful sometimes. With 2005 I tend to eliminate the
fields altogether where possible.

Since all these are private they are never visible to anyone inheriting or
using my classes. Beyond forms only (2) applies.

[Chris S.]

hungarian notation was useful before the generation of text editor that
includes tooltips for types, intellisense etc. It now has very little
use outside of loosely typed languages. Even then I would question its
use except for basic types such as ints,strings,bools.

[Andy]

Some counterpoints:

1. Not sure what you mean exactly by 'knowning which objects are
yours..' If your code is using them, they are all yours. If you want
to know if they are defined in libraries you wrote, the IDE can tell
you that.

2. this isn't a concern, because Employee (the web page class) should
be in a different namespace than Employee (the business object). You
would have to fully qualify one (probably the BO), so there's more
typing, but only when you declare the object or are tryign to cast it.
And technically, shouldn't your page be called formEmployee; after all,
you DO have a class that represents the aspx page.

3. System seems to be a pretty bad choice for a class name; it doesn't
really tell you anything about what the class does. Does system
represent a plumbing system? A network system?

4. Again, fully qualifying your classes should resolve this. Thats
why the concept of namespace was introduced.

I don't like hungarian notation because:

A. Its alot more typing; namespace conflicts are much more rare, so
its hard to justify that EVERY instance object have some extra
characters thrown in.

B. Your methods shouldn't be pages and pages long. If you're doing
proper OO design, each method should be fairly short, rarely taking up
more than 10 lines or so...making it really easy to look further up the
screen to double check what you're dealing with by looking up (or by
hovering your mouse of the name of the vairable).

C. .Net's type casting makes the mistakes which hungarian was trying
to adress very rare. In VBS Hungarian makes sense, since it will
happily let you Set intX = frmY and not complain. But in .Net, just
compiling your app will catch that mistake, so you don't need to name
variables to remind you what their types are.

Your last point (how to avoid naming conflicts) was addressed in 1.0;
use namespaces! If you want to have two different classes in the exact
same namespace with the exact same name, I'd say your design is off.

[Bruce Wood]

I think that everyone else here has outlined the counterarguments
nicely. I just want to outline why Hungarian notation was created, and
therefore why it's no longer useful.

It is my understanding that Hungarian notation was originally invented
for assembly language programming. There, it is immensely useful,
because nothing has "type," as such. In a completely typeless world,
you _need_ the characters before a name to tell you what it's meant to
be.

For some reason, the Hungarian habit (which was a good one in assembly
language) made it into C. I hated it in C and never used it. My
argument was that properly-written C programs, with short, well-named
functions and few or no global variables, were easy enough to read. In
an environment like that, Hungarian just got in the way.

The classic example is a variable that starts off being an int, and
then later you discover that it's not an integral quantity and you need
decimal places, so (sometimes) in C it became a double. Now you have
two unpleasant choices: 1) change the name everywhere (and hope you get
them all), or 2) live with a variable whose name indicates one type but
which is really another type. Perhaps int to double is a poor example,
but you get the idea: in an environment in which the language knows
what type each variable is, tagging the variable name with a type
indicator just introduces redundant information, which you then have to
maintain. Why bother?

In C# it makes absolutely no sense at all, because the IDE will tell
you what type something is just by your mousing over it. There's no
need to tag names saying "this is an int" "this is a string" because
the IDE will tell you, so why do all of that extra work to maintain
information that you get for free?

That said, your question doesn't seem to be about Hungarian in
particular, because many of your examples have more to do with naming
collisions than with tagging variable names with their respective
types.

In that sense, yes, it's helpful to have some convention for avoiding
naming conflicts, or for naming some things based on other things. One
that I've adopted solves the problem of how to name properties that
expose private fields: obviously you want the property named something
readable, like CustomerCode, but then naming the field customerCode
makes Intellisense act in annoying ways. Mangling the name to be
custCode or something quickly wears thin. So, I prefix private fields
with an underscore: _customerCode. However, the point is _not_ to make
it more "readable" or to give me a visual clue as to what is a private
field. Rather, this has everything to do with how the IDE acts
(Intellisense and the debugger) and how to make it work better for me.
In that sense, it's a naming convention, but it's not Hungarian.

Hungarian notation itself was very useful for the environment in which
it was created. Porting it into C was a questionable but widespread
practice. Porting it into C# is, IMHO, bordering on mindless habit.
Kick the habit!

[Jon Skeet [C# MVP]]

Ronald S. Cook <rc***@westinis.com> wrote:

An ongoing philosophical argument, I would like your opinions. With the
release of .NET, Microsoft spoke of moving away from the notation as a best
practice. I'm a believer for a few reasons:

1) Consistency throughout and knowing which objects are yours
(clsEmployee, tblEmployee, frmEmployee, etc).
The fact that you can tell which types are yours proves it
*inconsistent* with the rest of the framework.
2) Not having to name an employee form EmployeeForm.aspx because the
mane is already taken by your class named Employee.cs
You mean you have your forms in the same namespace as your business
objects? Even if namespaces didn't solve this, Employee would be a bad
name for a form, because in no way does "Employee" indicate the actual
purpose of the type.
3) We once had a major entity "System" in our model. Because it's
reserved name, would have to alias somehow anyway.
That's no reason to use Hungarian notation - you can rename it
4) I just created a form "Login.aspx" in an ASP.NET 2.0 app. That's now
a conflict with the new "Login" control.
LoginForm then?
Does anyone disagree with using Hungarian notation?
Very much so.
If so, I'd be
interested to hear specific bullets of why you don't like it (and also what
you would do to avoid naming conflicts).

1) It makes the code hard to read "out loud" in your head. This is my
main bugbear.

2) You can change types without having to change variable and type
names everywhere. (If your class becomes a struct or vice versa, why
should the name need to indicate that?)

3) It's not actual true Hungarian in the first place. True Hungarian
notation was meant to make it obvious that although you might store
both a height and a weight in float variables, they were effectively
different units. (That's just an example, obviously :)

4) It's inconsistent with the rest of the framework. Ideally, your own
code should just blend in with the framework code - you should be able
to use the framework classes and your own classes as easily as each
other, and transparently.

5) What use is "cls" anyway, when almost everything is a class? There
are far more possible types than memorable abbreviations.

6) Reinforcing point 1 in a way, but in a slightly different tack - it
keeps the details of the underlying implementation of the code too
tightly coupled with what the code is trying to achieve. Most of the
time, when I'm reading code, I want to just see what it's doing. I'll
assume the types are sensible - if I see a variable called "name" I'll
assume it's probably a string unless I see anything to the contrary,
for instance. The extra type information in every identifier just adds
to the "noise".

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

[Ronald S. Cook]

All good points.. thanks.

But what about in the database where you can't organize by namespace? In my
example, "System" is an entity in our design. Cable companies are called
MSOs: Multiple System Operators, so a "System" is owned by an "MSO".

If you don't have a tblSystem type of naming convention, then you must get
creative and name the object other than what best fits the need
("CableSystem" (blech)).

So if this situation warrants a prefix, why not go ahead and do throughout?
I do it on columns too (colID, colFirstName) so that when you need a column
named Date, you don't have the problem there as well.


"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...

Ronald S. Cook <rc***@westinis.com> wrote:

An ongoing philosophical argument, I would like your opinions. With the
release of .NET, Microsoft spoke of moving away from the notation as a
best
practice. I'm a believer for a few reasons:

1) Consistency throughout and knowing which objects are yours
(clsEmployee, tblEmployee, frmEmployee, etc).

The fact that you can tell which types are yours proves it
*inconsistent* with the rest of the framework.

2) Not having to name an employee form EmployeeForm.aspx because the
mane is already taken by your class named Employee.cs

You mean you have your forms in the same namespace as your business
objects? Even if namespaces didn't solve this, Employee would be a bad
name for a form, because in no way does "Employee" indicate the actual
purpose of the type.

3) We once had a major entity "System" in our model. Because it's
reserved name, would have to alias somehow anyway.

That's no reason to use Hungarian notation - you can rename it

4) I just created a form "Login.aspx" in an ASP.NET 2.0 app. That's
now
a conflict with the new "Login" control.

LoginForm then?

Does anyone disagree with using Hungarian notation?

Very much so.

If so, I'd be
interested to hear specific bullets of why you don't like it (and also
what
you would do to avoid naming conflicts).

1) It makes the code hard to read "out loud" in your head. This is my
main bugbear.

2) You can change types without having to change variable and type
names everywhere. (If your class becomes a struct or vice versa, why
should the name need to indicate that?)

3) It's not actual true Hungarian in the first place. True Hungarian
notation was meant to make it obvious that although you might store
both a height and a weight in float variables, they were effectively
different units. (That's just an example, obviously :)

4) It's inconsistent with the rest of the framework. Ideally, your own
code should just blend in with the framework code - you should be able
to use the framework classes and your own classes as easily as each
other, and transparently.

5) What use is "cls" anyway, when almost everything is a class? There
are far more possible types than memorable abbreviations.

6) Reinforcing point 1 in a way, but in a slightly different tack - it
keeps the details of the underlying implementation of the code too
tightly coupled with what the code is trying to achieve. Most of the
time, when I'm reading code, I want to just see what it's doing. I'll
assume the types are sensible - if I see a variable called "name" I'll
assume it's probably a string unless I see anything to the contrary,
for instance. The extra type information in every identifier just adds
to the "noise".

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

[Jon Skeet [C# MVP]]

Ronald S. Cook <rc***@westinis.com> wrote:

All good points.. thanks.

But what about in the database where you can't organize by namespace? In my
example, "System" is an entity in our design. Cable companies are called
MSOs: Multiple System Operators, so a "System" is owned by an "MSO".

If you don't have a tblSystem type of naming convention, then you must get
creative and name the object other than what best fits the need
("CableSystem" (blech)).
So in that particular (hopefully rare) case you have something like
CableSystem, or maybe some prefix/suffix which is only applicable to
these cases - BolSystem for the business layer object, for example.
So if this situation warrants a prefix, why not go ahead and do throughout?
Because it incurs the readability penalty *everywhere* when only a very
few of your types/variables are actually going to cause problems.

It's like saying "Well, I need to use reflection in a few places, so
why not make *every* method call using reflection?"
I do it on columns too (colID, colFirstName) so that when you need a column
named Date, you don't have the problem there as well.

Why would you need to have your own type for the date? Or if you *do*
have your own type for the date, name it according to how it's
different from DateTime.

Normally though I'd just have:

DateTime date;

No problems there.

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

[kevin cline]

If you have a column named "Date", someone is eventually going to ask
"Date of what?". So name your column "DateOfBirth" or "DateOrdered" or
"DateInstalled" or something.

I hate reading SQL queries filled with crap like colFirstName. When I
see Select FirstName from Employees, I don't need prefixes to tell me
that FirstName is a column and Employees is a table. How about a
simple rule that singular names are columns and plural names are
tables? You would be amazed how simple life seems when everything has
a descriptive readable name.

[kevin cline]

There are two problems:

1. It is unpronouncable and hence unreadable. When you talk to a user
about the application, do you talk about "frmMain?" No, you talk about
the "main form". So why not use the same name in the code?

2. It has little value in the strongly-typed OO world. Hungarian
notation was invented as a work-around for the weakly typed Windows
API, where the same types (int, char*, etc.) were used for multiple
purposes. An int could be an integer, or a window handle, or seventeen
other things, and it was important to keep them straight.

[Otis Mukinfus]

On 31 Jan 2006 15:51:03 -0800, "kevin cline" <ke*********@gmail.com>
wrote:

If you have a column named "Date", someone is eventually going to ask
"Date of what?". So name your column "DateOfBirth" or "DateOrdered" or
"DateInstalled" or something.

I hate reading SQL queries filled with crap like colFirstName. When I
see Select FirstName from Employees, I don't need prefixes to tell me
that FirstName is a column and Employees is a table. How about a
simple rule that singular names are columns and plural names are
tables? You would be amazed how simple life seems when everything has
a descriptive readable name.

Amen! I hate Hungarian notation. Have you ever tried to pronounce any
of that crap?

Name your objects for what they are or what they do.

Why would you name an integer index intIndex???

Who would think firstName was anything other than a string.

Otis Mukinfus
http://www.otismukinfus.com
http://www.tomchilders.com

[Steven Nagy]

I'm just a n00b compared to the other 'greats' who frequent this forum,
but I personally need to rely on intellisense a bit.
If I want the variable that stores the first name, this is how I code.

Start typing "Fi"
CTRL-SPACE
DOWN-ARROW
DOWN-ARROW
DOWN-ARROW
SPACE

If the variable is named 'strFirstName' then I'm screwed.

[Mythran]

"kevin cline" <ke*********@gmail.com> wrote in message
news:11**********************@f14g2000cwb.googlegr oups.com...

If you have a column named "Date", someone is eventually going to ask
"Date of what?". So name your column "DateOfBirth" or "DateOrdered" or
"DateInstalled" or something.

I hate reading SQL queries filled with crap like colFirstName. When I
see Select FirstName from Employees, I don't need prefixes to tell me
that FirstName is a column and Employees is a table. How about a
simple rule that singular names are columns and plural names are
tables? You would be amazed how simple life seems when everything has
a descriptive readable name.

We use something similar to your suggestion. Sorta...singular table names,
singular column names ;)

For example:

create table tblCustomer (
CustomerId int identity not null,
LastName varchar(50) not null,
FirstName varchar(25) not null,
MiddleName varchar(25) null,
Appellation varchar(9) null,
UpdateUser varchar(15) not null,
UpdateDate datetime not null,
[RowVersion] timestamp not null
)

-- Not including constraints.

We prefix our tables with tbl...followed by the entity name. Our stored
procedures are named EntityName_Function so, as an example:

Customer_SelectById
Customer_SelectByLastName
Customer_Delete
Customer_Insert
Customer_Update
:)

Mythran

[Ken Wilson]

On 31 Jan 2006 09:27:35 -0800, "Andy" <aj********@capcitypress.com>
wrote:

Some counterpoints:

1. Not sure what you mean exactly by 'knowning which objects are
yours..' If your code is using them, they are all yours. If you want
to know if they are defined in libraries you wrote, the IDE can tell
you that.

2. this isn't a concern, because Employee (the web page class) should
be in a different namespace than Employee (the business object). You
would have to fully qualify one (probably the BO), so there's more
typing, but only when you declare the object or are tryign to cast it.
And technically, shouldn't your page be called formEmployee; after all,
you DO have a class that represents the aspx page.

3. System seems to be a pretty bad choice for a class name; it doesn't
really tell you anything about what the class does. Does system
represent a plumbing system? A network system?

4. Again, fully qualifying your classes should resolve this. Thats
why the concept of namespace was introduced.

I don't like hungarian notation because:

A. Its alot more typing; namespace conflicts are much more rare, so
its hard to justify that EVERY instance object have some extra
characters thrown in.

B. Your methods shouldn't be pages and pages long. If you're doing
proper OO design, each method should be fairly short, rarely taking up
more than 10 lines or so...making it really easy to look further up the
screen to double check what you're dealing with by looking up (or by
hovering your mouse of the name of the vairable).

Even if your methods are long, if your aren't declaring your variables
until you absolutely have to they shouldn't really be too far from any
code you be working on I suspect.

Ken Wilson
Seeking viable employment in Victoria, BC

[Ken Wilson]

On Tue, 31 Jan 2006 14:19:26 -0700, "Ronald S. Cook"
<rc***@westinis.com> wrote:

All good points.. thanks.

But what about in the database where you can't organize by namespace? In my
example, "System" is an entity in our design. Cable companies are called
MSOs: Multiple System Operators, so a "System" is owned by an "MSO".

If you don't have a tblSystem type of naming convention, then you must get
creative and name the object other than what best fits the need
("CableSystem" (blech)).
I don't know about that. 'Cable System' tells me exactly what I need
to know and, in fact, conveys more information than 'System'.
'SystemOperator' would convey more information than just 'System'.
So if this situation warrants a prefix, why not go ahead and do throughout?
I do it on columns too (colID, colFirstName) so that when you need a column
named Date, you don't have the problem there as well.

Where I am at the only prefixing we do is every member variable starts
with a lowercase 'm' and every instance variable starts with a
lowercase 'i'. (Don't ask me, ask the boss.)

Ken Wilson
Seeking viable employment in Victoria, BC

[Jon Skeet [C# MVP]]

Ken Wilson wrote:

So if this situation warrants a prefix, why not go ahead and do throughout?
I do it on columns too (colID, colFirstName) so that when you need a column
named Date, you don't have the problem there as well.

Where I am at the only prefixing we do is every member variable starts
with a lowercase 'm' and every instance variable starts with a
lowercase 'i'. (Don't ask me, ask the boss.)

Out of interest, what do you class as a "member variable" compared with
an "instance variable"? I've always heard them used interchangably
(with "instance variable" being the correct terminology in C#).

Often "g_" is used for static variables (also known as "class
variables") so you'd have:

class Foo
{
int m_myHeight;
static int g_defaultHeight;
}

What would your code look like for the above?

Jon

[Ken Wilson]

On 31 Jan 2006 15:44:29 -0800, "kevin cline" <ke*********@gmail.com>
wrote:

There are two problems:

1. It is unpronouncable and hence unreadable. When you talk to a user
about the application, do you talk about "frmMain?" No, you talk about
the "main form". So why not use the same name in the code?

2. It has little value in the strongly-typed OO world. Hungarian
notation was invented as a work-around for the weakly typed Windows
API, where the same types (int, char*, etc.) were used for multiple
purposes. An int could be an integer, or a window handle, or seventeen
other things, and it was important to keep them straight.

Yes, and MS went even further towards making it confusing with all
those bloody uppercase type defs. Some MS code with its various
conventions inserted over the years is some of the fugliest code to
ever try to get a handle on.

Ken Wilson
Seeking viable employment in Victoria, BC

[Nick Hounsome]

"Ken Wilson" <kw*********@NOshaw.SPAMca> wrote in message
news:ab********************************@4ax.com...

On 31 Jan 2006 15:44:29 -0800, "kevin cline" <ke*********@gmail.com>
wrote:

There are two problems:

1. It is unpronouncable and hence unreadable. When you talk to a user
about the application, do you talk about "frmMain?" No, you talk about
the "main form". So why not use the same name in the code?

2. It has little value in the strongly-typed OO world. Hungarian
notation was invented as a work-around for the weakly typed Windows
API, where the same types (int, char*, etc.) were used for multiple
purposes. An int could be an integer, or a window handle, or seventeen
other things, and it was important to keep them straight.
Yes, and MS went even further towards making it confusing with all
those bloody uppercase type defs. Some MS code with its various
conventions inserted over the years is some of the fugliest code to
ever try to get a handle on.

Of course the main cause of so many typedefs, macros and hungarian is to try
to distinguish pointer-to-a-char, pointer-to-an-array-of-char and "string".

These problems don't arise in C#.

The closest you might get is to distinguish value types from reference
types.
Ken Wilson
Seeking viable employment in Victoria, BC

Nick Hounsome
Seeking viable employment near Bristol, UK :-)

[Ken Wilson]

On 3 Feb 2006 03:42:23 -0800, "Jon Skeet [C# MVP]" <sk***@pobox.com>
wrote:

Ken Wilson wrote:

>So if this situation warrants a prefix, why not go ahead and do throughout?
>I do it on columns too (colID, colFirstName) so that when you need a column
>named Date, you don't have the problem there as well.

Where I am at the only prefixing we do is every member variable starts
with a lowercase 'm' and every instance variable starts with a
lowercase 'i'. (Don't ask me, ask the boss.)

Out of interest, what do you class as a "member variable" compared with
an "instance variable"? I've always heard them used interchangably
(with "instance variable" being the correct terminology in C#).

Often "g_" is used for static variables (also known as "class
variables") so you'd have:

class Foo
{
int m_myHeight;
static int g_defaultHeight;
}

What would your code look like for the above?

Jon

Pretty much. I like the 'g' idea by the way.. The other part goes
this way.

Foo iRedFoo;
Foo iBluFoo;

We avoid underscores by using camel casing, or is it Pascal casing,
that always confuses me. Luckily the boss doesn't care about that as
long as I get it right. He's more worried if I get confused actually
writing code. ;-)

Ken Wilson
Seeking viable employment in Victoria, BC

[Jon Skeet [C# MVP]]

Ken Wilson <kw*********@NOshaw.SPAMca> wrote:

Out of interest, what do you class as a "member variable" compared with
an "instance variable"? I've always heard them used interchangably
(with "instance variable" being the correct terminology in C#).

Often "g_" is used for static variables (also known as "class
variables") so you'd have:

class Foo
{
int m_myHeight;
static int g_defaultHeight;
}

What would your code look like for the above?
Pretty much.

So where would you use an m?
I like the 'g' idea by the way.. The other part goes
this way.

Foo iRedFoo;
Foo iBluFoo;
So that's where I'd use m_ - I'm confused about where you'd use an m.
We avoid underscores by using camel casing, or is it Pascal casing,
that always confuses me.
It's sort of a mixture... PascalCasingStartsTheFirstWordCapitalised,
camelCasingStartsTheFirstWordLower.

In your case, the first *word* is capitalised, but the first letter of
the identifier itself is still lower case...
Luckily the boss doesn't care about that as long as I get it right.
He's more worried if I get confused actually writing code. ;-)

:)

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

[Ken Wilson]

On Sun, 5 Feb 2006 18:19:36 -0000, Jon Skeet [C# MVP]
<sk***@pobox.com> wrote:

Ken Wilson <kw*********@NOshaw.SPAMca> wrote:

>Out of interest, what do you class as a "member variable" compared with
>an "instance variable"? I've always heard them used interchangably
>(with "instance variable" being the correct terminology in C#).
>
>Often "g_" is used for static variables (also known as "class
>variables") so you'd have:
>
>class Foo
>{
> int m_myHeight;
> static int g_defaultHeight;
>}
>
>What would your code look like for the above?
Pretty much.

So where would you use an m?

Where you have the 'm_' only without the underscore.

I like the 'g' idea by the way.. The other part goes
this way.

Foo iRedFoo;
Foo iBluFoo;

My boss' interpretation is each of those is an instance of Foo
therefore, 'i'.

If, for argument sake, a member variable happened to be public (makes
sign of cross and says quick prayer to the Gods of 1 and 0) we would
be able to do this.

iRedFoo.mDeveloperIQ = 0; // hehehe...

This is actually helpful inside methods where you have the usual mix
of method and class member variables. Although we have other clues
such as plain-old variables are camel-cased with no prefix I feel it
doesn't hurt to have the additional clue and it doesn't impact
productivity.

So that's where I'd use m_ - I'm confused about where you'd use an m.

We avoid underscores by using camel casing, or is it Pascal casing,
that always confuses me.

It's sort of a mixture... PascalCasingStartsTheFirstWordCapitalised,
camelCasingStartsTheFirstWordLower.

In your case, the first *word* is capitalised, but the first letter of
the identifier itself is still lower case...

Luckily the boss doesn't care about that as long as I get it right.
He's more worried if I get confused actually writing code. ;-)

:)

Ken Wilson
Seeking viable employment in Victoria, BC

[Jon Skeet [C# MVP]]

Ken Wilson <kw*********@NOshaw.SPAMca> wrote:

So where would you use an m?
Where you have the 'm_' only without the underscore.

Foo iRedFoo;
Foo iBluFoo;

My boss' interpretation is each of those is an instance of Foo
therefore, 'i'.

So it's actually a difference between value types and reference types?
Ah - that's more like the broken Hungarian, and is awful IMO.
If, for argument sake, a member variable happened to be public (makes
sign of cross and says quick prayer to the Gods of 1 and 0) we would
be able to do this.

iRedFoo.mDeveloperIQ = 0; // hehehe...

This is actually helpful inside methods where you have the usual mix
of method and class member variables. Although we have other clues
such as plain-old variables are camel-cased with no prefix I feel it
doesn't hurt to have the additional clue and it doesn't impact
productivity.

I can't see how having the i/m differentiation helps. You need to know
the type in order to use the variable anyway, and knowing the type
tells you whether it's a reference type or a value type.

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

[Ken Wilson]

On Tue, 7 Feb 2006 07:34:13 -0000, Jon Skeet [C# MVP]
<sk***@pobox.com> wrote:

Ken Wilson <kw*********@NOshaw.SPAMca> wrote:

>So where would you use an m?

Where you have the 'm_' only without the underscore.

>> Foo iRedFoo;
>> Foo iBluFoo;

My boss' interpretation is each of those is an instance of Foo
therefore, 'i'.

So it's actually a difference between value types and reference types?
Ah - that's more like the broken Hungarian, and is awful IMO.

If, for argument sake, a member variable happened to be public (makes
sign of cross and says quick prayer to the Gods of 1 and 0) we would
be able to do this.

iRedFoo.mDeveloperIQ = 0; // hehehe...

This is actually helpful inside methods where you have the usual mix
of method and class member variables. Although we have other clues
such as plain-old variables are camel-cased with no prefix I feel it
doesn't hurt to have the additional clue and it doesn't impact
productivity.

I can't see how having the i/m differentiation helps. You need to know
the type in order to use the variable anyway, and knowing the type
tells you whether it's a reference type or a value type.

If it were up to me there wouldn't be any prefixing but a stronger
emphasis on meaningful names. I firmly believe if your starting to
get longer than a couple of hundred lines of code for anything smaller
than an actual class, i.e. a method, you really need to review the
design. That alone, IMO, will reduce the size of the headache and the
need for prefixes should be redundant. When I run my own company I'm
going to ... [8-)

Ken Wilson
Seeking viable employment in Victoria, BC

[Jon Skeet [C# MVP]]

Ken Wilson <kw*********@NOshaw.SPAMca> wrote:

I can't see how having the i/m differentiation helps. You need to know
the type in order to use the variable anyway, and knowing the type
tells you whether it's a reference type or a value type.

If it were up to me there wouldn't be any prefixing but a stronger
emphasis on meaningful names. I firmly believe if your starting to
get longer than a couple of hundred lines of code for anything smaller
than an actual class, i.e. a method, you really need to review the
design. That alone, IMO, will reduce the size of the headache and the
need for prefixes should be redundant. When I run my own company I'm
going to ... [8-)

Couple of hundred lines of code? I get worried if I can't fit a method
in one screen...

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