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
