Naming Conventions

[arcadiorubiogarcia]

Hi all,

I'm quite new to Ruby. One of the things I try to get when I learn a
new language are naming conventions. I hate to write, for instance,
Java code that looks like C++.

My question is: are Ruby's aliases intended for helping beginners
coming from other languages, or you are truly free to choose any of
the provided alternatives. For example:

is Enumerable#collect preferred over Enumerable#map
or is Array#length preferred over Array#size ?

Maybe this is a silly topic, but I haven't seen it explained anywhere.

Thanks is advance

 

[Thomas Adam]

Hi all,

I'm quite new to Ruby. One of the things I try to get when I learn a
new language are naming conventions. I hate to write, for instance,
Java code that looks like C++.

Heh. Not all of that is just down to naming conventions, of course.
What I sometimes do when I am switching to a new language is base a
sample program I might write in #{some_other_language} and then look
at making it more like that language. That said, I know a lot of
people who write perl code that looks like C.

My question is: are Ruby's aliases intended for helping beginners
coming from other languages, or you are truly free to choose any of
the provided alternatives. For example:

It's not about helping the beginner, it's generally about your own
style which you might choose.

is Enumerable#collect preferred over Enumerable#map
or is Array#length preferred over Array#size ?

Either. They can be used interchangeably. I happen to prefer
Enumerable#collect, although you might (if you know perl, for
instance) prefer Enumerable#map.

The choice is yours.

Where the style counts more though is in terms of casing. So for instance:

* Constants start with a capital letter.
* Method names are in snake_case.
* Class names in CamelCase.

Etc, etc. Those sorts of idioms are probably the area you should
concentrate on.

-- Thomas Adam

 

[John Joyce]

The choice is yours.

Yes. You can do as you please.

Where the style counts more though is in terms of casing. So for
instance:

* Constants start with a capital letter.
* Method names are in snake_case.
* Class names in CamelCase.

ModuleNames are also camel cased.

Other tip:
use do and end for multi-line blocks
use {} for single line blocks
It's not a rule, just by convention.

Other other tip:
Rails is not necessarily an example of Ruby. It's an example of
Ruby's tendency to become a DSL.
Many gems will show you different looking but similarly developed not-
typical-Ruby-looking style.
There seems to be a tendency for DSL-like things in Ruby projects as
they get developed.
I think this is a result of Ruby being very very OOPy and very flexible.
So don't be surprised when some things seem to have their own
conventions contrary to "standard" (?!) Ruby

 

[David A. Black]

Hi --

Yes. You can do as you please.


ModuleNames are also camel cased.

Other tip:
use do and end for multi-line blocks
use {} for single line blocks
It's not a rule, just by convention.

Other other tip:
Rails is not necessarily an example of Ruby. It's an example of Ruby's
tendency to become a DSL.
Many gems will show you different looking but similarly developed
not-typical-Ruby-looking style.
There seems to be a tendency for DSL-like things in Ruby projects as they get
developed.
I think this is a result of Ruby being very very OOPy and very flexible.
So don't be surprised when some things seem to have their own conventions
contrary to "standard" (?!) Ruby

On the other hand... Rails does a lot of things in conformity with
traditional Ruby style, which I think is very good and perhaps very
shrewd. The main departure is a lot of method calls without
parentheses. But the Rails code adheres to two-space indenting,
standard use of this_style and ThisStyle in the appropriate places,
and other standard stylistic things that people are often fond of
pushing aside.


David

--
Upcoming training from Ruby Power and Light, LLC:
* Intro to Ruby on Rails, Edison, NJ, October 23-26
* Advancing with Rails, Edison, NJ, November 6-9
Both taught by David A. Black.
See http://www.rubypal.com for more info!

 

[John Joyce]

Hi --



On the other hand... Rails does a lot of things in conformity with
traditional Ruby style, which I think is very good and perhaps very
shrewd. The main departure is a lot of method calls without
parentheses. But the Rails code adheres to two-space indenting,
standard use of this_style and ThisStyle in the appropriate places,
and other standard stylistic things that people are often fond of
pushing aside.


David

--
Upcoming training from Ruby Power and Light, LLC:
* Intro to Ruby on Rails, Edison, NJ, October 23-26
* Advancing with Rails, Edison, NJ, November 6-9
Both taught by David A. Black.
See http://www.rubypal.com for more info!

True True, one must admire the dedication in Rails to consistency!
It's a rare beast that you see more or less what you expect to see as
you dig deeper.

I was simply referring more to the DSL type things, such as Rails'
associations and validations, and of course Active Record itself. But
the beauty is that from the Rails Console, everything feels like any
other irb session and feels like typical Ruby.

Other tools though, like Rake, must be mystical to the Ruby newbie.
Some Ruby gems even seem like DSLs because of Ruby syntax after
people come from something like C or PHP.

 

[David A. Black]

Hi --

True True, one must admire the dedication in Rails to consistency! It's a
rare beast that you see more or less what you expect to see as you dig
deeper.

I was simply referring more to the DSL type things, such as Rails'
associations and validations, and of course Active Record itself. But the
beauty is that from the Rails Console, everything feels like any other irb
session and feels like typical Ruby.

Other tools though, like Rake, must be mystical to the Ruby newbie.
Some Ruby gems even seem like DSLs because of Ruby syntax after people come
from something like C or PHP.

And of course there's the matter of the term DSL itself, and what it
connotes (or doesn't). See for example:
http://dablog.rubypal.com/2007/4/17/the-l-in-dsl-langue-ou-langage


David

--
Upcoming training from Ruby Power and Light, LLC:
* Intro to Ruby on Rails, Edison, NJ, October 23-26
* Advancing with Rails, Edison, NJ, November 6-9
Both taught by David A. Black.
See http://www.rubypal.com for more info!

 

[John Joyce]

And of course there's the matter of the term DSL itself, and what it
connotes (or doesn't).

Nah, not really.
A language is a language.
Film itself is not necessarily a language. Computers are not a
language either.
A film is a language unto itself, but one that only the director can
really claim to understand 100%.
A program can be much the same, particularly in C or Perl.

I think DSL is pretty over-used as an acronym like all other acronyms
that are fashionable in computerese.
But none-the-less, domain specific language is pretty much best
described as metaprogramming, where there is some attempt to create a
programming language or command interface that is for the user within
specific domain of activity and has functionality that is clearly for
that domain only. Ideally DSLs should be easier to learn than the
programming language they're created with.

SQL is probably the best example of a DSL

 

[Rick DeNatale]

or is Array#length preferred over Array#size ?

I prefer length over size, because although Array#size and
Array#length are aliased, there are other classes which give size a
different meaning.

For example Bignum#size returns the number of bytes used in the representation.