Simon Strandgaard wrote:
> Ruby does already enforce CamelCase for class/modules.

Well, it enforces a leading capital, CamelCase is just a convention.

> 'camelCase' for variables/methods is easy to confuse with
> ClassNames. Its hard to distinguish for newcomers if they 
> should use 'under_score' syntax or 'camelCase' syntax. If 

Are you sure it is confusing to newcomers?  Most natural languages use a 
leading capital to distinguish different types of things.  Nouns/proper 
nouns vs. other parts of speech, beginning of sentences,etc.

> In Ruby2 it would be nice to get rid of 'camelCase', so
> that 'under_score' naming is enforced by the language.

Have you ever used a wiki where links are created when you enter words 
in a particular version of CamelCase?  It's pretty restrictive.  For 
example, the one I've used recently won't let me use a link named 
CProgrammingTips, because it has two adjacent caps.  Instead I have to 
use the potentially confusing name CeeProgrammingTips.  Because of this, 
I think it's a bad idea to enforce something like this unless it's 
really necessary to the parser.

I also think it's a bad idea to auto-translate between snake_case and 
camelCase.  What happens when a newbie is reading someone's library and 
see things declared in snake_case, but the code using that library uses 
camelCase?  It also makes it hard to grep for usage of a particular 
method/variable.

> Should I submit an RCR about this ?
> Resistance ?  any good reasons to use camelCase ?

Good reasons to use camelCase: to distinguish between 
variable-like-things and subroutine-like-things.

Take "run_once".  Is that a boolean flag saying that something should 
only run once, or is it a method that does one run of a multi-run 
action?  What about "skip_whitespace".  Is that a method that skips over 
whitespace or a flag that indicates whether whitespace should be 
skipped?  What about "read_buffer"?  Is that a buffer where data you 
read is stored, or a method to extract something from a buffer?

If we see something named "ReadBuffer" we know that it's a class.  We 
also can make some educated guesses about how it's used, what it does, etc.

Using camelCase allows you to see at a glance whether a given token does 
something (subroutine-like), or whether it returns something 
(variable-like).  For years, I've used the convention that 
subroutine-like-things use camelCaseWithLeadingLowercase and 
variable-like things use snake_case_with_all_lowercase.  Constants are 
UPPERCASE_WITH_UNDERSCORES and classes are CamelCaseWithLeadingCaps.

In C, this convention is particularly helpful in understanding code that 
passes function pointers into other functions.  If I see a line of code 
like this:

sort(data, alphaSort);

I can tell at a glance that alphaSort is a function that sort will call 
as it works.  I can tell it isn't a constant that indicates the type of 
sort to use.  I can also tell it isn't a variable, even though most 
things passed to functions are constants or variables.

I don't think that every function needs to have an uppercase letter in 
it somewhere, it's pretty obvious that 'sort' is a function/method.  I 
also don't think that every variable / accessor needs to have an 
underscore.  Person.age is almost certainly not a method to cause a 
person to get older!

If people don't find my arguments convincing, and want to continue using 
lowercase_with_underscores for both methods and variables, that's fine 
with me.  I'll have to work a bit harder to understand your code, but as 
long as you don't start using CamelCaseWithLeadingCaps for variables, 
classes, methods and constants then I think I can figure things out. 
But please, don't force me to make my own personal code less legible for me.

Ben