G
Gavin Kistner
Following the 'instance variable capitalization' thread, I'm convinced
that I should be trying to learn the Ruby idioms. Now I just need to
learn what they are.
While writing my ValidForm library (http://phrogz.net/RubyLibs/) I
realized that I was mixing camelCase [which I love] with
whatever_you_call_this_case [which I don't, but I see that Ruby uses a
lot of]. (BTW...what *do* you call that naming style? snake_case? That's
what I'll call it until someone corrects me.)
I tried starting to eradicate camelCase, but found that I just couldn't
do it completely[1], and came up with the following idiom for that
particular library[2]:
* '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.
I was very proud of my semi-rational rationale, in finding a way that I
felt was both Ruby-esque, which actually sort of conveyed additional
information with the camelCase vs. snake_case usage. But I realize it's
an idiom I made up completely on my own.
So, to the Question: is the above just a Bad Idea? Is camelCase *ever*
considered appropriate in Ruby?
- Gavin
[1] The problem for me (and this is not to start a flame war, just a
personal exposition) is that camelCase is just so much easier to type,
and (to me) LOOKS like a property.
[2] Whether or not I succeeded in religiously adhering to my proposed
idiom I'm not sure...I got disheartened after a while of global
find/replaces, upon how many pretty camelCases were disappearing.
that I should be trying to learn the Ruby idioms. Now I just need to
learn what they are.
While writing my ValidForm library (http://phrogz.net/RubyLibs/) I
realized that I was mixing camelCase [which I love] with
whatever_you_call_this_case [which I don't, but I see that Ruby uses a
lot of]. (BTW...what *do* you call that naming style? snake_case? That's
what I'll call it until someone corrects me.)
I tried starting to eradicate camelCase, but found that I just couldn't
do it completely[1], and came up with the following idiom for that
particular library[2]:
* '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.
I was very proud of my semi-rational rationale, in finding a way that I
felt was both Ruby-esque, which actually sort of conveyed additional
information with the camelCase vs. snake_case usage. But I realize it's
an idiom I made up completely on my own.
So, to the Question: is the above just a Bad Idea? Is camelCase *ever*
considered appropriate in Ruby?
- Gavin
[1] The problem for me (and this is not to start a flame war, just a
personal exposition) is that camelCase is just so much easier to type,
and (to me) LOOKS like a property.
[2] Whether or not I succeeded in religiously adhering to my proposed
idiom I'm not sure...I got disheartened after a while of global
find/replaces, upon how many pretty camelCases were disappearing.