While working in some legacy code yesterday, I had an insight that I can't believe took me so long to figure out. I've always thought it odd that some people insist on differentiating member variable names by some naming convention, such as by prefixing the name with an 'm', as in:

       ...
    private String mFoo;
       ...

I've never been a big fan of overloading variable names with type or scope information because I think it makes it harder to read the variable names, and by extension, the code. To me, the extra "information" is noise, so it lowers the S/N ratio of the code. The inclusion of scope information seems especially unnecessary(and therefore especially noisy) to me, and yesterday I figured out why: it's because I tend to factor my methods into very small, cohesive units.

I assert that where this convention exists you will also find code with long, uncohesive methods.

Why? Because methods that are very small don't have many local variables compared to long-winded, uncohesive methods. Therefore, there can be very little confusion about where a given variable was declared, and therefore no need to communicate the scope in the variable name. Long methods tend to use more variables from multiple scopes (simply because they're long), so to keep things clear, the programmer uses naming conventions to communicate scope that would otherwise be pretty obvious.

This is another argument for short methods, similar to the refactoring that states that a block of code prefaced by a comment should probably be replaced with a well-named method call.

In other words, program by intention - make your code say what it's doing.