Field names...

Eric Gunnerson s C Compendium Field names | Hair Growth Products

Eric Gunnerson s C Compendium Field names | Hair Growth Products — Sat, 13 Jun 2009 15:56:56 GMT

PingBack from http://hairgrowthproducts.info/story.php?id=403

Eric Gunnerson s C Compendium Field names | Green Tea Fat Burner

Eric Gunnerson s C Compendium Field names | Green Tea Fat Burner — Mon, 08 Jun 2009 05:31:03 GMT

PingBack from http://greenteafatburner.info/story.php?id=4172

re: Field names...

tina — Mon, 21 Mar 2005 19:00:00 GMT

re: Field names...

Michael Cook — Thu, 17 Mar 2005 16:02:00 GMT

#3 is too much, #1 is too little, #2 is just right :)

re: Field names...

duncan — Wed, 16 Mar 2005 15:20:00 GMT

Since I hate trying to type lots of _'s (shifted characters are bad m'kay) I prefix member variables with just the 'm':

mMembershipList;

otherwise no prefixes allowed.

re: Field names...

Jason Cone — Tue, 15 Mar 2005 02:05:00 GMT

I seem to be in the minority, but I can't stand prefixes on variable names. Spare me from ever working with Hungarian-notated code! Put me in camp #1.

If approach #1 was not an option for some reason, then appending an underscore seems like a reasonable (and less obtrusive) compromise.

re: Field names...

Daniel Moth — Sun, 13 Mar 2005 15:21:00 GMT

'm' for fields
'a' for in parameters
'the' for out paramters
'aThe' for inout params
'' for local vars (i.e. no prefix)

re: Field names...

Thomas Eyde — Thu, 10 Mar 2005 19:28:00 GMT

And

string name_;

even works in VB6:

Dim name_ As String

But that's a pure coinsidence, I guess?

re: Field names...

Scott Wisniewski — Thu, 10 Mar 2005 16:49:00 GMT

Personally, I like the naming convention advocated by Scott Meyers, and Andrei Alexandrescu:

string name_;

It doesn't feel like a compiler generated construct, the naming doesn't interfear with readability or asthetics, and its meaning is pretty clear.

re: Field names...

it's all in the mix — Thu, 10 Mar 2005 14:55:00 GMT

It's not about using simplistic rules it's about the key goal:

Can someone else* understand this quickly with little or no chance of errors.

If you always try to keep variable scope extremly short then a lot of the prefixing usage becomes redundant (so it begins to hinder not help as you duplicate the information).

Using this. in front of instance variables is also far more preferable since it make auto completion kick in. Unfortunately current visual studio behaviour is annoying when you have variable/property with identical names bar case - if I type in a lower case letter give me the lowercase one first dammit!!!**.

One area lack of prefixes can cause confusion with is in constructors this prefixes should be mandatory (not at the compiler level I mean as a coding guideline)(I really should make that an FxCop rule at some point)

I admit that static variables are an area that might benefit from an our. or class. (maybe static. would be non breaking).
* you in 6 months time counts as someone else ;¬)

** Sorry but if you could feed that back to the VS developers that would be good