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?
[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.
···
–
(-, /\ / / //
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
Hi –
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.
You can get at least a good rough idea from the source. From
/usr/local/lib/ruby/1.8:
$ ruby -ne ‘print if /\b[a-z]+[A-Z]/.match($)’ find -name "*.rb" | wc -l
862
$ ruby -ne 'print if /\b[a-z]+[a-z]/.match($_)’ find -name "*.rb" | wc -l
19943
[…]
So, to the Question: is the above just a Bad Idea? Is camelCase ever
considered appropriate in Ruby?
I’ll tell you why I dislike it. There’s the ugliness and the way I
hear it in my head (LOUD!), but obviously that’s all a matter of
taste and not worth going into. Beyond that, I dislike it because it
implies that Ruby doesn’t already have stylistic conventions and
traditions, let alone perfectly good ones. I don’t know… I guess
it’s related to my general feeling that Ruby comes in for much more
than its share of being treated like a preliminary draft of a language
rather than like a language with a culture, stylistic and otherwise.
(Reality check: I really do know that there’s no direct correlation
between using camelCase and viewing or “treating” Ruby in any
particular way. But it still triggers that “Why isn’t Ruby ‘allowed’
to just be itself?'” reaction in me, a bit.)
I’d find it easier to reconcile myself to camelCase if I felt that
this area was also in flux in other languages. But I don’t think it
is; I don’t think many people write under_score variables in Java, for
instance, nor that the choice is looked at as an even one.
David
···
On Mon, 23 Feb 2004, Gavin Kistner wrote:
–
David A. Black
dblack@wobblini.net
Hi,
At Tue, 24 Feb 2004 09:51:19 +0900,
David A. Black wrote in [ruby-talk:93516]:
You can get at least a good rough idea from the source. From
/usr/local/lib/ruby/1.8:
$ ruby -ne ‘print if /\b[a-z]+[A-Z]/.match($_)’ find -name "*.rb" | wc -l
862
They all aren’t method names; regexps, string literals, local
variables, or comments.
···
–
Nobu Nakada
Chunky bacon!
From: “David A. Black” dblack@wobblini.net
Sent: Tuesday, February 24, 2004 9:51 AM
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.
You can get at least a good rough idea from the source. From
/usr/local/lib/ruby/1.8:
$ ruby -ne ‘print if /\b[a-z]+[A-Z]/.match($)’ find -name "*.rb" | wc -l
862
$ ruby -ne 'print if /\b[a-z]+[a-z]/.match($_)’ find -name "*.rb" | wc -l
19943
Hmm.
0$ egrep -r ‘def +[a-z]+[A-Z]’ lib
lib/cgi.rb: def nOE_element_def(element, append = nil)
lib/cgi.rb: def nO_element_def(element)
lib/parsearg.rb:def printUsageAndExit()
lib/parsearg.rb:def setParenthesis(ex, opt, c)
lib/parsearg.rb:def setOrAnd(ex, opt, c)
lib/parsearg.rb:def setExpression(ex, opt, op)
lib/parsearg.rb:def parseArgs(argc, nopt, single_opts, *opts)
lib/xmlrpc/create.rb: def methodCall(name, *params)
lib/xmlrpc/create.rb: def methodResponse(is_ret, *params)
lib/xmlrpc/httpserver.rb: def writeTo(port)
lib/xmlrpc/parser.rb: def removeChild(node)
lib/xmlrpc/parser.rb: def childNodes
lib/xmlrpc/parser.rb: def hasChildNodes
lib/xmlrpc/parser.rb: def nodeType
lib/xmlrpc/parser.rb: def nodeValue
lib/xmlrpc/parser.rb: def nodeName
lib/xmlrpc/parser.rb: def parseMethodResponse(str)
lib/xmlrpc/parser.rb: def parseMethodCall(str)
lib/xmlrpc/parser.rb: def removeWhitespacesAndComments(node)
lib/xmlrpc/parser.rb: def nodeMustBe(node, name)
lib/xmlrpc/parser.rb: def hasOnlyOneChild(node, name=nil)
lib/xmlrpc/parser.rb: def dateTime(node)
lib/xmlrpc/parser.rb: def methodResponse(node)
lib/xmlrpc/parser.rb: def methodName(node)
lib/xmlrpc/parser.rb: def methodCall(node)
lib/xmlrpc/parser.rb: def parseMethodResponse(str)
lib/xmlrpc/parser.rb: def parseMethodCall(str)
lib/xmlrpc/parser.rb: def startElement(name, attrs=)
lib/xmlrpc/parser.rb: def endElement(name)
lib/xmlrpc/parser.rb: def methodResponse_document(node)
lib/xmlrpc/parser.rb: def methodCall_document(node)
lib/xmlrpc/parser.rb: def createCleanedTree(str)
lib/xmlrpc/parser.rb: def methodResponse_document(node)
lib/xmlrpc/parser.rb: def methodCall_document(node)
lib/xmlrpc/parser.rb: def createCleanedTree(str)
lib/rss/xmlparser.rb: def startElement(name, attrs)
lib/rss/xmlparser.rb: def endElement(name)
lib/rss/xmlparser.rb: def xmlDecl(version, encoding, standalone)
lib/rdoc/markup/simple_markup/lines.rb: def isBlank?
0$
(Only checked method name)
Back to the topic, here is the coding convention for library
which is bundled with ruby. [ruby-talk:62890], [ruby-talk:62894].
- use two-space indentation, no TABs
- use RDoc
- shouldn’t use camelCase for variable names and method names
- use camelCase for class names and module names
- use upper case separated by ‘_’ for constants
Library users never want to mix under_scoer and camelCase. So,
- Overturn the matz and rubyists’s way, then rewrite all libs, or
- Please use under_score name for users.
Regards,
// NaHi
traditions, let alone perfectly good ones. I don’t know… I guess
it’s related to my general feeling that Ruby comes in for much more
than its share of being treated like a preliminary draft of a language
rather than like a language with a culture, stylistic and otherwise.
.
.
.
I’d find it easier to reconcile myself to camelCase if I felt that
this area was also in flux in other languages. But I don’t think it
is; I don’t think many people write under_score variables in Java, for
instance, nor that the choice is looked at as an even one.
I don’t see this as that much of a factor, personally. It really boils
down to aestetics. The ripe_with_underscores_everywhere style is
pervasive in the Perl world, as well, but there are quite a few people who
program in Perl who use CamelCase either because that’s just what they are
used to, or because they think that CamelCase, at least in certain
instances, looks better or is easier to read.
I personally have less discipline on this subject than I probably should
have, but generally I use CamelCase for verbs and underscore_case for
nouns. It’s easier for me to read a page of code if there is something
like CamelCase jumping out at me when methods are being invoked. It’s
personal preference and making the choice that is most efficient for my
uses. I imagine the same can be said for people like yourself who abhor
CamelCase. I imagine that if you were writing Java code, your inclination
would be to use underscore_case (or snake_case; I kind of like that term),
because that is what feels better on your brain, yes?
Kirk Haines
···
On Tue, 24 Feb 2004, David A. Black wrote:
This is another perfect example of something that is a religious issue.
One can make good arguments for using spaces for indentation, and one can
make good arguments for using tabs for indentation. When one is down in
the trenches churning out a solution for a client, what matters most is
that one be consistent with whatever one chooses, as there are always
going to be people who both agree and disagree with the choice. Better to
just make the choice and then get on with getting the work done.
Kirk Haines
Formerly a space-indenter, now a committed tab-indenter.
···
On Tue, 24 Feb 2004, NAKAMURA, Hiroshi wrote:
Back to the topic, here is the coding convention for library
which is bundled with ruby. [ruby-talk:62890], [ruby-talk:62894].
- use two-space indentation, no TABs
Kirk Haines wrote:
traditions, let alone perfectly good ones. I don’t know… I guess
it’s related to my general feeling that Ruby comes in for much more
than its share of being treated like a preliminary draft of a language
rather than like a language with a culture, stylistic and otherwise.
.
.
.
I’d find it easier to reconcile myself to camelCase if I felt that
this area was also in flux in other languages. But I don’t think it
is; I don’t think many people write under_score variables in Java, for
instance, nor that the choice is looked at as an even one.
I don’t see this as that much of a factor, personally. It really boils
down to aestetics. The ripe_with_underscores_everywhere style is
pervasive in the Perl world, as well, but there are quite a few people who
program in Perl who use CamelCase either because that’s just what they are
used to, or because they think that CamelCase, at least in certain
instances, looks better or is easier to read.
I personally have less discipline on this subject than I probably should
have, but generally I use CamelCase for verbs and underscore_case for
nouns. It’s easier for me to read a page of code if there is something
like CamelCase jumping out at me when methods are being invoked. It’s
personal preference and making the choice that is most efficient for my
uses. I imagine the same can be said for people like yourself who abhor
CamelCase. I imagine that if you were writing Java code, your inclination
would be to use underscore_case (or snake_case; I kind of like that term),
because that is what feels better on your brain, yes?
Kirk Haines
camel_case
camelCase
mas or menos
9 is less than 10 is about the only good argument that is not subjective
that i can see
…well except for the fact that ruby/matz likes ‘snake_case’
10 is less than 9!
···
On Tue, 24 Feb 2004, David A. Black wrote:
Kirk Haines wrote:
This is another perfect example of something that is a religious issue.
One can make good arguments for using spaces for indentation, and one can
make good arguments for using tabs for indentation.
FWIW, I have yet to hear a good reason for hard tabs. 
As soon as a
single space is used anywhere on a line after tabs, the tabs mean
nothing and will cause the indentation to be mismatched on someone
else’s system. With spaces, the indentation is always correct.
I agree that what matters is consistency, and what_works_for_you. (See,
I’m getting the hang of it already!
I didn’t mean (too much) to start a religious debate. The thing is, I’m
a blank slate when it comes to Ruby. Sure, I have a bit of baggage from
past languages, but I’m starting fresh and I want to be clean.
Further, consistency is important not just within my own code, but
within the community if I plan on ever contributing back. So I want to
learn to be consistent with whatever prevalent pseudo-standard may
exist.
Although the topic is ripe for a holy war, and some (including
myself) certainly prefer camelCase in some instances, it appears that
the vast majority use snake_case for everything but
ClassAndModuleNames. (Which really, I never thought was in any doubt; I
can’t imagine a class name with an underscore.)
So…as proud as I was of my nouns/verbs rationale for including
camelCase in method names, I will henceforth use snake_case only for
method names, UpperCamelCase for class/module names, and
SHOUTING_AT_THE_TOP_OF_MY_LUNGS case for constants.
Despite the touchy subject, thank you all for your feedback.
(And don’t even get me started on the tabs issue! :p)
···
On Feb 23, 2004, at 7:11 PM, Kirk Haines wrote:
This is another perfect example of something that is a religious
issue. One can make good arguments for using spaces for indentation,
and one can make good arguments for using tabs for indentation. When
one is down in the trenches churning out a solution for a client, what
matters most is that one be consistent with whatever one chooses, as
there are always going to be people who both agree and disagree with
the choice. Better to just make the choice and then get on with
getting the work done.
–
(-, /\ / / //
Whenever I have been in a position to make code formatting standards, I have
absolutely forbidden tabs for indentation. They’re too problematic. The
default tabspacing is too large (8), and because everyone can configure
things differently (2, 3, 4, 8, …) it turns into a problem when people
have “smart” editors that mix tabs and spaces.
The trick here, though, is that Ruby has a style: two-space indentation, no
tabs. If you write a library that you want included in the standard library,
you need to conform to the style there.
-austin
···
On Tue, 24 Feb 2004 11:11:37 +0900, Kirk Haines wrote:
On Tue, 24 Feb 2004, NAKAMURA, Hiroshi wrote:
Back to the topic, here is the coding convention for library which is
bundled with ruby. [ruby-talk:62890], [ruby-talk:62894].
- use two-space indentation, no TABs
This is another perfect example of something that is a religious issue.
One can make good arguments for using spaces for indentation, and one can
make good arguments for using tabs for indentation. When one is down in
the trenches churning out a solution for a client, what matters most is
that one be consistent with whatever one chooses, as there are always
going to be people who both agree and disagree with the choice. Better
to just make the choice and then get on with getting the work done.
–
austin ziegler * austin@halostatue.ca * Toronto, ON, Canada
software designer * pragmatic programmer * 2004.02.25
* 12.02.00
I somewhat do convention changes with Delphi when I have to use Delphi. The
convention for a Delphi object is something like:
Type
TMyObject = Class
Private
FFieldName: String;
End;
(I’ve already made one other convention change here. Most Delphists would
put Type, Class, Private, String, and End in lowercase. I maintain that
keywords in Pascal should be capitalised, because that’s how I learned how
to program Pascal.)
When I write delphi, I do:
Type
TMyObject = Class
Private
_fieldname: String;
End;
This is similar to how I specify private instance variables in C++ and Java
and is a convention I picked up some years ago as it marks a variable as a
private instance variable just as surely as @var does in Ruby.
-austin
···
On Tue, 24 Feb 2004 20:16:55 +0900, David A. Black wrote:
No. What feels better to my brain is observing the stylistic conventions
and traditions of a given language, and what I dislike is the fact that
Ruby seems to have been singled out for a kind of “oh, just do whatever
you want” treatment, when the conventions are perfectly evident, clear,
and consistent.
–
austin ziegler * austin@halostatue.ca * Toronto, ON, Canada
software designer * pragmatic programmer * 2004.02.25
* 12.14.36
LOL. I’m a convert from spaces to tabs. With tabs, I don’t have to
hassle with what someone else’s notion of proper indentation width is. I
just set my preference in the editor and that is what I see. Someone else
can set a different preference if they like.
Tabs are also faster for me. It’s a tangible difference when I am writing
a lot of code, and when I am really into a coding groove it’s always my
fingers that are the limiting factor to how fast I can produce the code,
so every little bit helps.
Spaces mixed with tabs can mess the indentation up (though not
necessarily), but I don’t find that to be a significant factor, for me.
If there are spaces mixed with tabs, I’ve been sloppy, and I fix it. It
rarely affects me adversely, though, whereas the freedom to adjust
indentation through editor settings and the speed increase that I get from
it helps me. If I had a neural interface that reduced the bottleneck that
my fingers impose on me, tabs would lose much of their advantage over
spaces, for me.
As in most of these issues, it’s completely subjective.
Kirk Haines
···
On Tue, 24 Feb 2004, Patrick Bennett wrote:
FWIW, I have yet to hear a good reason for hard tabs. As soon as a
single space is used anywhere on a line after tabs, the tabs mean
nothing and will cause the indentation to be mismatched on someone
else’s system. With spaces, the indentation is always correct.
Don’t go there.
Jason Voegele
I like tabs.
http://derkarl.org/why_to_tabs.html
···
On Monday 23 February 2004 10:32 pm, Patrick Bennett wrote:
FWIW, I have yet to hear a good reason for hard tabs. As soon as a
single space is used anywhere on a line after tabs, the tabs mean
nothing and will cause the indentation to be mismatched on someone
else’s system. With spaces, the indentation is always correct.
Speaking of tabs, I have a colleague that uses emacs. Using
ruby-mode.el, indents two spaces, unless he tabs
4 times. Then the 8 spaces are converted to a hard tab.
Is there a way to prevent this from happening? Particularly, is
there a way for ruby-mode.el to do this so he does not have to
permanently change his tab setting in emacs.
Thanks
···
On Tuesday, 24 February 2004 at 12:32:46 +0900, Patrick Bennett wrote:
FWIW, I have yet to hear a good reason for hard tabs. As soon as a
single space is used anywhere on a line after tabs, the tabs mean
nothing and will cause the indentation to be mismatched on someone
else’s system. With spaces, the indentation is always correct.
–
"I went to a job interview the other day, the guy asked me if I had any
questions , I said yes, just one, if you’re in a car traveling at the
speed of light and you turn your headlights on, does anything happen?
He said he couldn’t answer that, I told him sorry, but I couldn’t work
for him then.
– Steven Wright
Gavin Kistner gavin@refinery.com writes:
Further, consistency is important not just within my own code, but
within the community if I plan on ever contributing back. So I want to
learn to be consistent with whatever prevalent pseudo-standard may
exist.
True. However, the standard only matters at the interface level.
As long as you use snake_case for your methods and PUBLIC_CONSTANTS,
you’re free to use camelCase for private local variables if you like.
-Mark
And I agree with you here. If I were writing code that was going to be in
the standard library, I’d go through the pain of conforming my style to
the described “Ruby” style so that it fits in with the rest of the code.
When writing the code that keeps my family fed, though, it is far too hard
to make sure my Perl adhere’s the the described Perl community’s style,
and my Java to the described Java community’s style, and my Ruby to Ruby
style, and my Bash scripts to yet a different style, and my C to…
It’s too many completely arbitrary styles. Far better for me to use the
style that fits best with the way I work and the way that I read code and
to do so consistently across everything that I have to produce and to
maintain.
If anything that I write ever becomes interesting enough to other people
that I have people actually using it and looking at the code, then I will
find it worthwhile, for those items, to make a pass through them
converting the abhorred camelCase to snake_case and tabs to spaces and
everything else necessary to fit into the described Ruby style.
Thanks for the discussion. It’s been fun.
Kirk Haines
···
On Thu, 26 Feb 2004, Austin Ziegler wrote:
The trick here, though, is that Ruby has a style: two-space indentation, no
tabs. If you write a library that you want included in the standard library,
you need to conform to the style there.