I know the current naming standards of the language. My curiosity is how many programmers prefer it.
Prime example given by a few: snake_case is preferable to Japanese Readers.
-Zach
Eero Saynatkari wrote:
···
Zach wrote:
Alrighty,
I've another question I'd like to pose the Ruby community. Coming
from a Java background, so I'm rather used to "camelCase" as opposed to
what looks to be the standard "ruby_case". (For those who don't know, If
a method is java was named "DoSomething" it would be called
"doSomething" in Java, and likewise "do_something" in Ruby.)
Arguments I've personally witnessed against Camel Case is Acronyms. If I
have an "ABC" in Camel Case it I'd have to would be to break up the
acronym like "aBC" if it appears at the beginning of the word. A lot of
people try to push the word to the end, others say to have the whole
acronym as lowercase "abc", but I think that is just a workaround for
the problem not a solution.
Once I started programming in ruby, I was a little surprised at the use
of the underscore, but I'm wondering the sentiments of the programmers
out there. Do you prefer word breaks by underscore or case? Does is look
more readable? Does anything else irk you with Camel Case and/or Ruby's
preference?
Not trying to incite flame_wars or the like, looking for honest opinions.
The big thing is that Ruby attaches semantic meaning to the naming
scheme: all constants must start with an uppercase letter, so your
classes and modules have CamelCaseNames. Because of this, seeing
something like obj.MethodName or even obj.methodName causes a ruby
programmer an involuntary double-take to ensure it indeed refers to
a method, not a constant. For this reason (and others that have been
battled over pretty much since the keyboard was invented), it is
preferred that the following is used:
* Classes and modules use CamelCase
* Constants use ALL_CAPS
* Methods and variables use underscored_names
If you have a variable that refers, say, to an instance of a class representing a hotel reservation, name it as such:
current_hotel_reservation. Not hr_curr or the like.
Personally, I think that there is a place for short names as I find them much more readable. Verbosity can be a real impediment to readability.
I tend to prefer to adopt the stylistic conventions of the language I am
working in. Rather than try to hold on to some cross-language personal
preference, I find having my code match the style of the libraries that I am
using to be the most aesthetically pleasing.
Gabe
···
On 1/20/06, Zach <zacharooni@comcast.net> wrote:
I know the current naming standards of the language. My curiosity is
how many programmers prefer it.
Prime example given by a few: snake_case is preferable to Japanese
Readers.
-Zach
Eero Saynatkari wrote:
>Zach wrote:
>
>
>>Alrighty,
>>
>> I've another question I'd like to pose the Ruby community. Coming
>>from a Java background, so I'm rather used to "camelCase" as opposed to
>>what looks to be the standard "ruby_case". (For those who don't know, If
>>a method is java was named "DoSomething" it would be called
>>"doSomething" in Java, and likewise "do_something" in Ruby.)
>>
>>Arguments I've personally witnessed against Camel Case is Acronyms. If I
>>have an "ABC" in Camel Case it I'd have to would be to break up the
>>acronym like "aBC" if it appears at the beginning of the word. A lot of
>>people try to push the word to the end, others say to have the whole
>>acronym as lowercase "abc", but I think that is just a workaround for
>>the problem not a solution.
>>
>>Once I started programming in ruby, I was a little surprised at the use
>>of the underscore, but I'm wondering the sentiments of the programmers
>>out there. Do you prefer word breaks by underscore or case? Does is look
>>more readable? Does anything else irk you with Camel Case and/or Ruby's
>>preference?
>>
>>Not trying to incite flame_wars or the like, looking for honest
>>opinions.
>>
>>
>
>The big thing is that Ruby attaches semantic meaning to the naming
>scheme: all constants must start with an uppercase letter, so your
>classes and modules have CamelCaseNames. Because of this, seeing
>something like obj.MethodName or even obj.methodName causes a ruby
>programmer an involuntary double-take to ensure it indeed refers to
>a method, not a constant. For this reason (and others that have been
>battled over pretty much since the keyboard was invented), it is
>preferred that the following is used:
>
> * Classes and modules use CamelCase
> * Constants use ALL_CAPS
> * Methods and variables use underscored_names
>
>
>
>>-Zach
>>
>>
>
>
>E
>
>
>
I know the current naming standards of the language. My curiosity is how many programmers prefer it.
Personally, I like Ruby's naming standards. I prefer snake_case to camelCase in general, so that helps. But an important point is, I think,
that it's better to adopt the naming standards of whatever language
I'm coding in. In Java, I follow Sun's naming conventions. We've seen
posts from Ruby programmers who stick with their own style, regardless
of language. That's their prerogative, but if one is writing library code
to share with the Ruby community, I think it's especially important to be
willing to adopt the Ruby naming conventions. It's always a sinking
feeling (for me anyway) to download what might be a nice open source
Ruby library, and find the author was either unaware of the Ruby naming conventions, or decided to disregard them, thereby putting
unnecessary burden on all users of the library. Makes me want to
scream, "Oh! You inconsiderate miserable b****rd!!!!" - but that is
always tempered by, "But, thanks for the free code!" <grin>
much more readable. Verbosity can be a real impediment to readability.
Well, readability and communication are key.
James
An interesting concept for functional apps (or system) Hungarian in
Ruby. It would be pretty easy to set up the missing_method function to
extract out certain tags from a variable name.
For example,
assume you have a model with an attribute called 'Text'
you could set up missing_method to pick up 'iText' and return
'Text.to_i' or 'hText' could return 'h(Text)' etc...
NOTE: I'm not advocating that this is a good idea, I'm just pointing out
that you could use Hungarian notation in Ruby and actually have it do
something.
Nicely put! I too prefer to use the conventions of the language I am
working in.
I used to use camelCase everywhere when I first got into Java. That
angered a few people. I learned
···
On 1/20/06, Bill Kelly <billk@cts.com> wrote:
It's always a sinking
feeling (for me anyway) to download what might be a nice open source
Ruby library, and find the author was either unaware of the Ruby
naming conventions, or decided to disregard them, thereby putting
unnecessary burden on all users of the library. Makes me want to
scream, "Oh! You inconsiderate miserable b****rd!!!!" - but that is
always tempered by, "But, thanks for the free code!" <grin>
much more readable. Verbosity can be a real impediment to readability.
Well, readability and communication are key.
James
An interesting concept for functional apps (or system) Hungarian in
Ruby. It would be pretty easy to set up the missing_method function to
extract out certain tags from a variable name.
For example,
assume you have a model with an attribute called 'Text'
(A class with an attribute called "text"?)
you could set up missing_method to pick up 'iText' and return
'Text.to_i' or 'hText' could return 'h(Text)' etc...
Why not just call to_i or h in the first place?
David
···
On Tue, 24 Jan 2006, Kevin Olbrich wrote:
--
David A. Black
dblack@wobblini.net
"Ruby for Rails", from Manning Publications, coming April 2006!
NOTE: I'm not advocating that this is a good idea, I'm just pointing out
that you could use Hungarian notation in Ruby and actually have it do
something.
David A. Black said..
Why not just call to_i or h in the first place?
In most cases I expect that it would be better that way, and that would
be my preference as well. I suppose it might be useful for porting
code.
How are you going to assign a variable (iText = ...), and then convince Ruby to treat it as a method (to trigger method_missing())?
James Edward Gray II
···
On Jan 23, 2006, at 12:49 PM, Kevin Olbrich wrote:
An interesting concept for functional apps (or system) Hungarian in
Ruby. It would be pretty easy to set up the missing_method function to
extract out certain tags from a variable name.
For example,
assume you have a model with an attribute called 'Text'
you could set up missing_method to pick up 'iText' and return
'Text.to_i' or 'hText' could return 'h(Text)' etc...
I've seen code that takes find_by_foo( bar ) and converts it into find( :foo => bar ) or some such thing. Is this to save typing (he asked rhetorically)? Expression of intent? Slickitude factor ("Ha! Try THAT, Java droids!" )? (Still rhetorical; please, no flames.)
I showed this as part of a Ruby demo, and at least one person didn't see what that bought you. Fair enough. I tend to like it, though.
hText (though h_text or text_h looks more Rubyish) is just another example of embedding code in message names.
But it can teeter toward DSL: domain-specific logorrhea.
How are you going to assign a variable (iText = ...), and then
convince Ruby to treat it as a method (to trigger method_missing())?
I just tested this with a quick one and found that if you do something
like
object.iTest=5
Then method_missing will get 'iTest=' as the symbol, and 'n' as an
argument. Then it's a simple matter of trimming the 'i' off the front
and returning the result of '(test=n).to_i'.
Gotcha. I thought you were talking about using local variables. I understand now. Thanks.
James Edward Gray II
···
On Jan 23, 2006, at 3:20 PM, Kevin Olbrich wrote:
James Gray wrote:
How are you going to assign a variable (iText = ...), and then
convince Ruby to treat it as a method (to trigger method_missing())?
I just tested this with a quick one and found that if you do something
like
object.iTest=5
Then method_missing will get 'iTest=' as the symbol, and 'n' as an
argument. Then it's a simple matter of trimming the 'i' off the front
and returning the result of '(test=n).to_i'.
