I finally did it-- hungarian notation

[Herfried K. Wagner [MVP]]

So forget samples... how about their actual FRAMEWORKS which implement
their Patterns & Practices and which they distribute as actual source
code.
Here's an abridged piece of code (below) from their CompositeUI Block
released just last month.

Mhm... What about the core parts of "Microsoft.VisualBasic.dll"? Pascal
case everywhere, even for method parameters! Really great!

BTW: If people give method parameters ugly (camel case) names only to be
able to distinguish them from local variables which are pascal case this
means making an ugly implementation detail visible. I think it's better
(although the .NET Framework naming rules say something different) to use
pascal case for everything which is publically visible (including
namespaces, classes, methods, properties, fields, and method parameters) and
maybe use camel case internally.

Just my 2 Euro cents...

 

[Herfried K. Wagner [MVP]]

And if the VB enterprise frameworks source code isn't enough... how about
their own internal guidelines (which reference VB as well not just C#)?
"Do use camelCasing for local variables"
http://blogs.msdn.com/brada/articles/361363.aspx

Like I said in another post concerning this document.... I guess they
don't make this part of the official Guidelines, which stresses
only the public object model of your classes, for fear of throwing the
community into chaos.... though I think the community (VB especially) is
in chaos.

Those guidelines have not been designed with VB in mind, thus I don't think
they are a good foundation to base new guidelines for VB on. For example,
the following points made in the article technically cannot be applied to
VB:

| * Do not use a prefix for member variables (_, m_, s_, etc.). If
| you want to distinguish between local and member variables you
| should use “this.” in C# and “Me.” in VB.NET.
|
| * Do use camelCasing for member variables

 

[Herfried K. Wagner [MVP]]

Cor,

As Herfried has stated very well, done mostly by amateurs like you and me
who are just developers.

Thank you for pointing this important thing out again. In the article I
conclude that most naming guidelines are simply descriptions of practice
instead of a plan which is based on expertise in psychology, design,
linguistics, ... We could find new naming guidlines based on a consensus,
but I believe it's much more important to let real professionals create and
evaluate the guidelines before forcing them on developers. Obviously this
has not been done for the .NET Framework Guidelines and the Internal Coding
Guidelines.

 

[CMM]

Mhm... What about the core parts of "Microsoft.VisualBasic.dll"? Pascal

case everywhere, even for method parameters! Really great!

Maybe that's because that namespace duplicates special keywords that have
been in B.A.S.I.C. since as far back as 1977... before BASIC even had the
ability for encapsulated Functions and Subs and was instead a punch-card
style, line-driven programming language.

In fact, everything in that "core part" should be ALL CAPS.... ;-) but
somewhere along the line (VB1? QBASIC? not sure) MS smartly decided this
would be ugly.... but in .NET I guess they kept the Casing for nostalgic
reasons. Who knows.

 

[academic]

MS suggest camel for Protected instance field
and Pascal for Public instance field

Do you think they meant Friend, Private and Protected as protected
instances?

 

[academic]

Only if one wanted to flout the Microsoft naming standard. ;-)

Have a look at that link I included before. There's a pretty basic set of
rules for method and property naming that, as far as I can tell, would
alleviate any problems you're talking about. For example, you'd be able
to tell that EnrollCustomer was a method and that CustomerNum was a
property just by the names themselves. If you use the convention of using
verbs in your method names, you don't need to mess around with casing to
make these distinctions.

Microsoft doesn't take a stand on whether to use PascalCase for method
variables. (At least, not that I've found.)

MS on the link
http://msdn.microsoft.com/library/d...s/cpgenref/html/cpconcapitalizationstyles.asp
suggest camel for Parameter and for Protected instance field
and Pascal for Public instance field

Do you think they meant Friend, Private and Protected as protected
instances?

 

[academic]

constructs. A common convention like today's camelCase for vars,

PascalCase for everything else, etc etc is very liberating and very
consistent and will make for much more maintainable body of work.

What about Public variables
If there are any do you think it makes sense to make them PascalCase as MS
suggests?