Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Ruby > Naming Conventions

Reply
Thread Tools

Naming Conventions

 
 
arcadiorubiogarcia@gmail.com
Guest
Posts: n/a
 
      10-18-2007
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

 
Reply With Quote
 
 
 
 
Thomas Adam
Guest
Posts: n/a
 
      10-18-2007
On 18/10/2007, http://www.velocityreviews.com/forums/(E-Mail Removed)
<(E-Mail Removed)> wrote:
> 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

 
Reply With Quote
 
 
 
 
John Joyce
Guest
Posts: n/a
 
      10-18-2007
>
> 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

 
Reply With Quote
 
David A. Black
Guest
Posts: n/a
 
      10-18-2007
Hi --

On Thu, 18 Oct 2007, John Joyce wrote:

>>
>> 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


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!

 
Reply With Quote
 
John Joyce
Guest
Posts: n/a
 
      10-18-2007

On Oct 18, 2007, at 9:27 AM, David A. Black wrote:

> Hi --
>
> On Thu, 18 Oct 2007, John Joyce wrote:
>
>>> 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

>
> 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.

 
Reply With Quote
 
David A. Black
Guest
Posts: n/a
 
      10-18-2007
Hi --

On Fri, 19 Oct 2007, John Joyce wrote:

>
> On Oct 18, 2007, at 9:27 AM, David A. Black wrote:
>
>> Hi --
>>
>> On Thu, 18 Oct 2007, John Joyce wrote:
>>
>>>> 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

>>
>> 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.


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/...gue-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!

 
Reply With Quote
 
John Joyce
Guest
Posts: n/a
 
      10-18-2007
>
> 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

 
Reply With Quote
 
Rick DeNatale
Guest
Posts: n/a
 
      10-18-2007
On 10/18/07, (E-Mail Removed) <(E-Mail Removed)> wrote:

> 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.

--
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
while executing my client program i get the exception javax.naming.LinkException: [Root exception is javax.naming.LinkException: [Root exception is javax.naming.NameNotFoundException: remaining if plz anybody know how to solve this problem then mahesh Java 0 03-08-2007 12:26 PM
Web.conf debug attribute creates different control naming conventions .NET 1.1 Roy Assaly ASP .Net 1 04-10-2006 07:59 PM
Me vs. .NET HTML Control naming conventions Josh Wolf ASP .Net 2 03-31-2006 12:37 PM
Namespaces and Naming conventions Floppy Jellopy ASP .Net 4 07-21-2005 01:36 PM
Naming conventions for ASP.NET objects? =B= ASP .Net 4 09-06-2004 09:05 AM



Advertisments