Guidelines
Maurits Jansen
Can anyone explain to me why Microsoft does not approve to the Hungarian
notation?
Doe anyone know what the right name of a instance of a class should be?
objObjectName?
oObjectname?
ObjectName?
thanx,
mj
Joseph Albahari
>
> objObjectName?
> oObjectname?
> ObjectName?
None of the above :-) Class names are usually Pascal Cased (ie MyClass),
where object names and variables are camelCased (ie objectName). Properties
are usually Pascal Cased, while fields are camelCased (although some people
prefix fields with an underscore or m_, the latter being quite ugly IMHO).
A three-letter prefix for Control objects is quite popular (such as lblName
and txtName) as a simple way to avoid naming conflicts (in that example
between the label and textbox, although "Name" may also be a property in the
class, and "name" a field). I've also got into the habit of prefixing
dataset classes with "DS" (and dataset instances with "ds") for the same
reason.
I've always used Hungarian notation in the past with Visual FoxPro, but IMO
it isn't necessary with C# because
(a) strong typing and intellisense avoids confusion with types
(b) in C# and .NET there isn't a heap of globally scoped rubbish you can
potentially conflict with, as with some loosely typed "evolved" languages.
C# also lends itself to minimum-visibility scoping. The default visiblity
modifier is private, which is excellent.
Anyway, a lot of that's my opinion, and there are bound to be some others!
Regards,
Joseph
"Maurits Jansen" <maur...@wanadoo.nl> wrote in message
news:uZVSe4eqAHA.1456@tkmsftngp04...
Jonathan Allen
> notation?
First of all, the actual "Hungarian" notation was designed for C and other
non-type safe languages. With modern languages, you don't need the notation
to remind you what type you are using and how many indirections are needed.
The lack of pointers and the addition of smarter compilers takes care of
that for you.
In addition, Hungarian just makes things harder to read. I know when I'm
looking at a list of classes, I don't want them all listed under "C". The
method signature tells me the parameter's type, so I don't need the
decorations there either.
> Doe anyone know what the right name of a instance of a class should be?
Whatever you feel like calling it. The guidelines are for public identifiers
only. No one cares what you name your internal stuff, except possibly your
co-workers.
As for my company, we use the prefix "o" for objects. We are considering the
prefix "xo" for objects that need to be disposed.
--
Jonathan Allen
Lasse B. Schiøttz
> Can anyone explain to me why Microsoft does not approve to the Hungarian
> notation?
pI vThink aHungarian nNotation vIs iA aWonderful nThing cAnd pEveryone
avShould vUse pIt aAll dThe nTime, adNo nMatter pWhat dThe nContext,
adEven adWhen vSpeaking.
s:-)
p = pronoun
v = verb
a = adjective
n = noun
i = indef. art.
d = def. art.
c = conjunction
av = aux. verb
ad = adverb
s = smiley
/lasse
Steffen Ramlow
"Lasse B. Schiøttz" <l...@nonet.dit.dk.nonet> wrote in message
news:OAJeQNvqAHA.2016@tkmsftngp04...
Matt Thalman
"Jonathan Allen" <grey...@cts.com> wrote in message
news:enV7CpnqAHA.1296@tkmsftngp05...
Then technically you should prefix everything with "o" since all variables
are actually objects in C#. I was going to do what you just stated until I
reminded myself of this.
-matt
Robert M. Cohen
i.e. you shouldn't really care where a value 'comes from' as long as it
behaves as it is intended to.
Bob Cohen
"Matt Thalman" <mtha...@greatplains.com> wrote in message
news:egC#XyvqAHA.1784@tkmsftngp05...
Jonathan Allen
> the
> > prefix "xo" for objects that need to be disposed.
>
> Then technically you should prefix everything with "o" since all variables
> are actually objects in C#. I was going to do what you just stated until
I
> reminded myself of this.
In my company, the prefix "o" and "xo" reflect "how it is used", not "what
it is".
If it is used as a reference, then it gets "o".
If it need to be disposed IN THAT METHOD, then it gets "xo". If some other
method is suppose to dispose it, then it just gets "o".
--
Jonathan Allen
Dan Haygood
[Regarding capitalization:]
It depends on the way you are referencing your object. If you are
referencing it with a local variable, you are on your own: strangely
enough, MS (ref 1) does not specify a recommendation for local variable
declaration capitalization. I might recommend either using Pascal-case to
distinguish it from parameters; or I might recommend camel-case, because
that is what Eric Gunnerson (of MS) uses (ref 2).
(But Eric never discuss casing of variable names in the book--although he
usually uses camel-casing for variable names, he only specifies camel-casing
for "private members of classes, such as fields" (p287). By extension of
his logic, since variable names are not seen publicly, they would be
camel-cased, but he never says this. BTW, Eric mixes c-casing (all
lower-case) with camel-casing, e.g. "retval" and "numberString" on p. 212 )
If your instance is referenced in a parameter list, it would be camel-cased.
If you have a protected field referencing the obeject, that is camel-cased.
You may have a property that resolves to an object reference. That would be
Pascal-case, as would be most other references to your object.
[Regarding sp-notation ("Stupid Prefix"):]
I haven't seen any systematic prefixes (suffixes) used in any of the docs,
except that Interfaces begin with "I" followed by a Pascal-case name, and
event handlers end with "EventHandler" There are many recommendations to
"Do Not" use Hungarian notation.
So, why would you want to use it to distinguish objects from, well,
wait...everything is an object! You would have to put a little (or big) "o"
in front of every variable and parameter if you did this. Of couse, there
are a few types that tie to a primitive model, like Int32...maybe you want
to show this somewhat-artificial binding, or to distinguish between value
type instances and object type references? I don't see how that would be
useful, since everything is boxed to an object for most use ayway.
> [Hungarian Notation] isn't necessary with C# because...
...(IMHO) to do effective work on code, you have to learn it anyway, so why
rely on crutch names, when you can go look at the actual declaration?
It was only bad C programmers long ago who made this necessary anyway, using
characters, bytes, longs, booleans, signed and unsigned, and everything
else, interchangably in their type-unsafe world. Good C programmers never
wrote type-mixing code in the first place, and in C#, now no one is able to.
> ...object names and variables are camelCased (ie objectName)....
You don't cite Gunnerson, so do you have a newer help file, or did you find
a reference someplace that I missed? Or is this what you do or have seen
done?
> A three-letter prefix for Control objects is quite popular...
These are good ideas, and although they look Hungarian, when I use them, I
use them as a shorthand for a description. Sometimes it is useful to refer
to a vaiable named "SidePanelLabel"...I sometimes use "lblSidePanel"
instead...I try only to do this on Label controls though, so that people who
try overly-hard to read Hungarian intentions into my variable names don't
get too confused. The declaration "String lblSidePanel;" would freak them
out.
- Dan
(1) .NET Framework SDK / .NET Framework Developer Secifications / .NET
Framework Design Guidelines / Naming Guidelines / Capitalization Styleset.
(et al)
(2) "A Programmer's Introduction to C#", Eric Gunnerson.
"Joseph Albahari" <m...@albahari.com> wrote in message
news:#rqa5HhqAHA.2020@tkmsftngp05...