Gavin Kistner wrote:
> * 'Verb' methods (named like they do something, and generally called 
> with parameters, or where the action they produce is more important than 
> their return value) I named using snake_case.
> 
> * 'Noun' methods (aka 'property' methods...methods which behave like 
> getters and setters of an internal instance variable [whether or not 
> they actually do] which are called explicitly to get a return value or 
> with a foo= assignment method to set a value) I named using camelCase.

For what it's worth, this is the opposite of how I do it, and here's why:

* If it looks and acts like a variable, I name it like a variable, for 
which I use 'snake_case'.

* If it is a verb method that does something, that's where camelCase 
makes sense to me.

I think it's important to visually distinguish the different types of 
things in a program.  To do this, I use ALL_CAPS_WITH_UNDERSCORES for 
constants, all_lowercase_with_underscores for variables, and 
variable-like attribute accessors.  I use CamelCaseWithLeadingCap for 
class like things, and finally I useCamelCaseWithLeadingLowercase for 
methods that do something.

That makes it easy to glance at a 'word' and see what it is and what it 
does.

On top of that, I'm careful in how I name things.  Constants, variables 
and classes are nouns, methods are active verbs.  The reason I think 
camelCase is useful to distinguish methods from variables/accessors is 
when it comes to things named 'read_number'.  Is that a variable that 
stores the number of times something was read?  Is it a method that 
instructs something to read a number?  The only way I know of to make 
that unambiguous is camelCase.  readNumber is the method, read_number is 
the variable.  Voila.

Maybe that's just me tho.

Ben