Pascal / Camel casing have only recently come about in the last 10 years and are unlikely to be a permanent standard.

I work within each of the coding standards I’ve had to follow and generally resort to using single word variable, parameter, identifer names to avoid the underscore, pascal casing, camel casing, etc argument.

Commonly, I’ve seen first and second year out of college developers having a hard time reading anyone elses code especially if the style is not what they are used to.

Some examples of this:

Local variables:
– prefixed with l_
– prefixed iwth _
– all lowercase (global variables in caps)
– prefixed with m_ for member variables
– prefixed with lower case i or m
– prefixed with LOCAL_
– prefixed with local

Refactoring and reordering your code will be more beneficial than fighting about variable naming schemes.

For example:

Providing a constructor with no arguments and then forcing uses to set all of the member variables one at a time even though the class cannot be properly initialized/constructed without setting all of the member variables. This is often done to run a class in some automated unit test runner. This should be refactored itno a constructor that forces values for all of the member variables to be passed in to ensure that any construction of the object results in a fully constructed object.

Example 2: Providing a save to xml method in an object as well as a load from XML even though the object will never be loaded from XML.

If you have existing standards or conventions and don’t get buy in from the team to change them, then perhaps you need to make a stronger case or just subvert your will to the desires of the team.

http://www.alistapart.com/articles/indefenseofeyecandy

You didn’t really think that I was going to let you have the last work on this, did you? Let’s go point by point.

10. There is already a language feature that allows you to scope Intellisense to the current object. I assume you are referring to the “this” keyword. “this” will give you all all of the members of the containing class. As far as I know, there is no “baked-in” Intellisense feature that will give you only the private member fields.

9. The underscore is an awkward key combination on the top row and requires a shift-key. It is especially awkward for left-handers like me, which means that my life expectancy decreases by maintaining your code. This is a bit of a stretch (no pun intended), don’t you think?

8. Personally, it interrupts the flow when reading code rather than enhancing it. Initially, maybe. However, after using it consistently, I have found that it actually improves the readability of my code, providing additional context in a relatively unobtrusive fashion.

7. You don’t receive as much negative feedback when your methods are too long. Can you be more specific?

6. I don’t ever, ever (EVER) find myself wondering, “hmmm, is this variable a parameter or a field?” As hard as we try, we can’t all be Jef Newsom

5. I don’t make mistakes, so your third point is irrelevant. See my response to your sixth point.

4. You make it really fun to take the opposing view. I’ll take that as a compliment.

3. It makes the code ugly. Weak.

2. Really ugly. Really weak.

1. _really, really_ ugly_. _Really, really_ weak_.

As far as the near-perfect code symmetry is concerned, that’s just a pleasant side effect. Your serve.

Kind Regards,
Casey.

First, I agree with Wil that is is helpful if you are reading code using a normal text editor and need to differentiate between parameters and fields. I truly needed that capability in 1996 when I was writing C on Unix using VI. That was the best argument for the use in my opinion.

You also forgot to mention that the real reason that you do it is because of the near-bilateral symmetry. Damn that semi-colon for screwing things up.

_foo = foo_;

I KNOW that that is the REAL reason.

Now, the arguments against.

10. There is already a language feature that allows you to scope intellisense to the current object.

9. The underscore is an awkward key combination on the top row and requires a shift-key. It is especially awkward for left-handers like me, which means that my life expectancy decreases by maintaining your code.

8. Personally, it interrupts the flow when reading code rather than enhancing it.

7. You don’t receive as much negative feedback when your methods are too long.

6. I don’t ever, ever (EVER) find myself wondering, “hmmm, is this variable a parameter or a field?”

5. I don’t make mistakes, so your third point is irrelevant.

4. You make it really fun to take the opposing view.

3. It makes the code ugly.

2. Really ugly.

1. _really, really_ ugly_.

Love,
Jef

No matter what editor you choose, be it VI, Emacs, Notepad, UltraEdit, SourceInsight, or your own hand-rolled version, appending an underscore to parameter names lets you instantly look at a piece of code and know exactly where that variable came from.

Excellent topic Casey!