@ Head

I use #5, with Procedure Separators off. ;-)

#1 all the way baby.

I'm also a fan of apps hungarian as desscribed by Joel in this article:
http://www.joelonsoftware.com/articles/Wrong.html

I prefer #1.

camelCasing without any prefix;

to distinguish between local and member variables you should use [this]

#2 at work (Tha'ts the corp standard..) and #6 at home.

Why, it's less typing...

For all non public variables I use camel case, and I just use the _ to indicate it's module level... (I'm too lazy to type the extra m)

I use:

pCamelCase

The p is for 'private'

Hey Jacob,

Good article. Basically use common sense when naming <g>

Scary thing is I kind of agree on the Exception thing also. Everytime I write code knowing that it may cascade an error out of a method, I just get this urge to not do it.. to try to encapsualte that. Can't always achieve it though

Phil: But what happens when someoen else workign on your code does have procedure seperators turned on ?

Anatoly: Doesn't that require you to have a different naming pattern for case insensitive languages ?

Eddie: ROFL. I've hear people say that for 3 & 4 more so than 6, as then they just type m, instead of SHIFT -

I Agree with Anatoly. If I have a property with the same name in VB I always put Value in the end of the private module variable (camelCasingValue).

What Anatoly said. Using the underscore can lead to FxCop violations if the field isn't private, and I just don't like "m_"

And I know you're asking for private field naming conventions, but I don't want a different naming convention for private and non-private fields, so I end up not using "m_". I used to, but now I just use camelCasing and prefix this (or Me, or self, or whatever the language wants) to scope it and make it explicit in code.

And your CAPTCHA control is driving me nuts! I can't tell if some characters are upper-case or lower case of it's a "1" or an "l".

Jason, you *should* have different naming conventions for fields based on their accessibility. Public fields should be PascalCase. (Public includes Friend). Protected fields should be camelCase. So logically it makes sense that if we differentiate for those two (based on MS's published standards), then we should also differentiate Private from Protected. Doing so, allows anyone editing your code to look at the member usage and know whether or not that is encapsulated within the class or not.

Besides a class with a Public Property HashValue using camelCasingValue rules, the backing field becomes hashValueValue. That's just ugly. returnValueValue is another.

On the CAPTCHA, yeh I knwo, sorry ,but not in my control. I beleive letters are only a-f, os it should never be i or l, but it does have a short tiemout as well. Usually will fial onthe first attempt so I don't even bother tryign first time

I'm still trapped back in my vb6 days. Hungarian baby!

Well, at least, I think so, I've never actually bothered to research it.

for private members, I use msFoo for a string, mlFoo for an int, mbFoo for a boolean, etc. The worst of these if mlFoo - in VB6 a real int was a long, so therefore now that I have real ints in .net, the l stayed too
Of course, you'd then think that if I ever had an miFoo, then it would have to be an Int16, but sadly no - that looks too confusing *laughs*

For local variables within a method, I use the same convention - but leave the 'm' off. Parameters to a method I replace the m with a p. Properties of course are PascalCased.

Me, I like the fact just by glancing at a variable I can immediately tell if it was declared locally, passed in, or member level variable. I still put the type prefix on mostly from habit, but it's nice to tell immediately if it's a bool or string or int or whatever. In most other cases, I make sure i name the variables to both be description of what they represent AND their type (eg, moSerializer shows it's the member serializer, and that its, well, a serializer

I particularly hate having to qualify access to members by preceding it with a Me. or equivalent. To me, it's a waste of a dereference operation *grin* When I refer to msSomeString, it's pretty damn well obvious that it's a member level variable and not method call.

It's a sad state of affairs. I know noone that does it the same way as me, but no ones been able to convince me enough to change.

The important thing is that I'm completely consistent, and even someone else complains at my style, they've never once complained (to my face) that they can't tell what's going on.

A good point you did make is access to protected variables. I've never been happy with how I've named them (they still get the msFoo) but I haven't thought of a nice way to make it clear that they're protected and still be consistant to my style (p is already taken....hmm...maybe f for friend

Hey Geoff,

you just sick We'll have to beat the 21st century into you

did you read Joel's take on hungarian ? Jacob posted the link :
<http://www.joelonsoftware.com/articles/Wrong.html>
to summize, he basically talks about using hungrain for logical distinctions not type distinctions. I find 99% of the time I really don't need type suffixes as the name should imply what it is. Waht with intellisense, strong typing and back ground compiler checking that strong typing, I jsut dont' really need to worry abotu the size of an integer type anywhere other than where I declare it. Okay sure I still sometimes use semi hungarian, eg strFoo for locals, and abbreviation style locals for small routines, eg fs for a filestream, but not at moduel level.. I think the biggest difficulty I have is finding good names for method parameters (and NO adding p in front of them is eeeeeeeeewwwww. Like imagine a routine that asks for a hue, it's get a phue

#3 from the minute I was born

I use (6) _camelCasing. I don't see any value in the m_ other than the "other languages don't support" argument, which doesn't affect me. Why? Because all of my fields are private as they should be. You shouldn't have public or protected fields because implementation changes end up being breaking changes, so better to use properties for public and protected items. Fields should always be private. CLS compliance should not be an issue if you stay away from publicly (or protected) identifiers.

Gosh, just finished a consulting gig where (in at least one app) there are (by coding standards) form/module/class-level declarations like:
Private miptrItemReceiptFrm As frmSomething
Private mintChocolate As Integer
AND method-level declarations of similar ilk
Dim liptrItemReceiptFrm As frmSomething
Dim lintChocolate As Integer
AND global constants like:
gstrCOLUMN_ITEM_RECEIVE_SERIAL_NBR
AND maybe best of all, parameters like:
ByRef aINOUTstrDataString As String
ByRef aINiptrSomething As Object
ByRef aINstrStringValue As String

...I'm worn out from all the typing and mental gymnastics. Ya, the "iptr" prefix on various objects was a C guy trying reform VB (circa 2001), and the parameter names were an attempt to distinguish ByRef/ByVal parameters, though I never did figure out what the "a" had to do with it.).

I especially like the "mint" and "lint" prefixes -- you can get a coder doubled-up in laughter with a little creative variable naming. All-cap constants ARE FUN, TOO.

Seriously: For underlying class variables of properties, I use "x_sPropertyString As String" just to make sure I don't try doing a direct assignment to the property variable (something I see often as a consultant and get good money for fixing) instead of going thru the property itself.

Until vbScipt/ASP-Classic are outa my life, I'll keep using simple hungarian -- like [m][s, i, l, b, o]VariableName. It keeps my coding life simple and minimizes (unexpected) type-coercion screwups.

Lets all agree to dump "_" except in extreme cases (the "Matrix" gets it's energy from developers pressing the "Shift" + "-" keys and from MS-Solitare mouse-clicks).

[For clients, I write it my way and then do RegX manipulations to conform to their individualized styles.]

And, ya, I use [p]ParamName for ByVal parameters and [pref]ParamName for byRef parameters (in the rare cases I'm forced to use them). Go, Geoff...

Showing my age and heritage, I use "fVariable" for singles and doubles -- otherwise know as 'floats".

Last but not least, (I like my code's references to seem obvious) I like the clarity of writing:
Me.PropertyValue = "abc"
oClass.PropertyValue = "abc"
because
PropertyValue = "abc"
looks hinky (lacks intuitive clarity), in the sense that it has no context if you're using some sort of prefix notation for variables. (Sorry, Geoff. Sorry, Compiler/DeReferencer.)

It (on-the-surface) would be good if there was an obvious way to distinguish between a class's methods and properties, as in:
SomeClass.Methods.DoThis(parameter)
SomeClass.Properties.IsDirty = False
T'would be nice in the IDE, too, to separate methods from properties (more than just the method/property icons).