They say I write Ruby like Perl

[Daniel Schierbeck]

Hi all,

I wrote some hierarchy handling classes in Node.rb
(http://www.troubleshooters.com/projects/Node.rb/index.htm), and I've been
told I write Ruby in Perl style. In future software, what could I do to
write in a more Ruby-like fashion?

Notice that I've substituted your tabs with two spaces and that I've
changed you method names to lower_case instead of camelCase

class Node < Object

No need to write `< Object', since all objects inherit from Object

super()

You don't need the parantheses

@parent = nil
@prevsibling = nil
@nextsibling = nil
@firstchild = nil
@lastchild = nil

Variables are created when they're first referenced, and are `nil' by
default, so these lines make no difference.

attr_reader :name, :type, :value
attr_writer :name, :type, :value

This will do the same:
attr_accessor :name, :type, :value

def setAttributes(attribs) @attribs = attribs; end
def getAttributes() return @attribs; end

This will do the same:
attr_accessor :attribs

def hasAttributes() return @attribs != nil; end

def has_attribs?
# Hash#empty? returns true if the hash has no elements
not @attribs.empty?
end

def setAttribute(key, value) @attribs[key] = value; end
def getAttribute(key) return @attribs[key]; end

def []=(key, value)
@attribs[key] = value
end

def [](key)
@attribs[key]
end

def hasAttribute(key) return @attribs[key] != nil; end

def has_attrib?(key)
@attribs.has_key? key
end


That's just some of the things though.

Cheers,
Daniel

 

[Steve Litt]

Personally, I think readability does suffer. The wordier it gets, the
more I have to think. Why not a simple 'append_sibling'?

This is a special case of the Node.pm/Node.py/Node.rb tool. I wanted the
application programmer (the guy *using* the tool as opposed to the guy
authoring it (me)) to be able to know exactly what the method does, at a
glance. I wanted it to be abundently clear that it was appended to the
current object, and not to something else. For instance, if the programmer
got a little confused he might think the object was what was being inserted
(perhaps inserted into the argument???) I was trying to have the code serve
as documentation.

Looking at it from hindsight, I probably could have called them
append_sibling() and prepend_sibling(), and figured it would be obvious that
the argument was what was being inserted, and the object was what the
argument was being appended or prepended to.

Unfortunately I cannot change this at this point because there's a lot of code
using Node.pm, and possibly some using Node.py, so I can't change it without
breaking a lot of programs, and I want to keep the method calls in Node.pm,
Node.py and Node.rb as similar as possible.

However, the next *independent* software I write, I'll definitely spend some
time thinking of more succinct ways to create descriptive variable names.
Yep, in hindsight, insert_sibling_after_you might have been overkill.

Incidentally, if you ever want to really understand a problem domain, one way
is write it in three different languages, and get feedback in all three

Thanks

SteveT

Steve Litt
http://www.troubleshooters.com
(e-mail address removed)

 

[Francois Paul]

lower<shift>camel<shift>case

lower<shift>-camel<shift>-case

but for the readability i'd type the two extra keystrokes every time!

 

[Joe Van Dyk]

lower<shift>camel<shift>case

lower<shift>-camel<shift>-case

but for the readability i'd type the two extra keystrokes every time!

doh, you're right. i need my coffee.

 

[Chad Perrin]

lower<shift>camel<shift>case

lower<shift>-camel<shift>-case

but for the readability i'd type the two extra keystrokes every time!

Thanks for saving me the extra typing.

Hmm. By posting this, I don't think I've saved anything.

Anyway: As I said, I don't find it any less readable. I think that, in
general, lowerCamelCase vs. snake_case (or whatever we're calling it
today) readability is a matter of personal preference.

 

[Chad Perrin]

Incidentally, if you ever want to really understand a problem domain, one way
is write it in three different languages, and get feedback in all three

That's going in my quote file, in this form:
"If you ever want to really understand a problem domain, one way is
write it in three different languages, and get feedback in all three."
- Steve Litt

Objections?

 

[dblack]

Hi --

I'd be interested to know *why* it is a language convention, and more
important why it is a lanaguage convention that from this thread it
seems rubyists vigorously insist upon? For those of us who were
"raised" with a language like Java (or as some on this list may say,
brain damaged ;-), lowerCamelCase seems more pleasing to the eye than
identifiers_with_underscores.

When using Ruby, it's best to think of yourself as "raised with Ruby".
It saves all kinds of trouble

Anyway, underscore names are a convention in Ruby partly because Matz
dislikes cAmElCaSe But that's just the origin (or perhaps a
"creation myth"). There are now many years, and millions of lines of
code, written in the traditional style or something close to it.

At to what a given person does: I guess it's a matter of whether you
feel that these things are absolute or relative. Or, perhaps, whether
you can put aside the absolute interpretation for the sake of
consistency with the traditions. I tend to try to use the conventions
of whatever language I'm using. Even though I hate the look of
camelCase variable names, I've used them in languages where it would
have seemed doctrinaire or "culturally" weird not to.

Part of it, I think, is coming to believe that Ruby is not a sort of
clearing-house for conventions and practices from other languages, but
is itself a language, with people "raised" in it, people who "come
from" it, and so forth. Still -- the parser will allow camelCase, all
the extra semi-colons you want, printf("%s\n",str); and all the rest
of it. In that sense it's an inclusive language -- but it's not a
fledgling project, and a set of conventions does exist.


David

 

[dblack]

Hi --

Thanks for saving me the extra typing.

Hmm. By posting this, I don't think I've saved anything.

Anyway: As I said, I don't find it any less readable. I think that, in
general, lowerCamelCase vs. snake_case (or whatever we're calling it
today) readability is a matter of personal preference.

Definitely. "Readability", in my opinion, has turned out to be a
worse-than-useless concept in discussions of style.

So it comes down to one's take on Ruby conventions, I guess.


David

 

[Patrick Gundlach]

[...]

Variables are created when they're first referenced, and are `nil' by
default, so these lines make no difference.

mostly right, but here is one exception:

#!/opt/ruby/1.8/bin/ruby -w

if @foo==:bar
puts "hello"
end

gives a warning.

Patrick

(and there is another exception that vnpenguin@gmail recently came across)

 

[Chad Perrin]

Definitely. "Readability", in my opinion, has turned out to be a
worse-than-useless concept in discussions of style.

So it comes down to one's take on Ruby conventions, I guess.

Well . . . there are some pretty much objective measures of readability.
Ruby, thankfully, tends to come out smelling pretty good on that score,
both in terms of the sort of code Ruby syntax encourages and in terms of
the common Ruby stylistic conventions. I do tend to agree, though, that
at least half the time when someone says "readable" what he really means
is "I like it." Python is my perfect example of that: Python hackers
all seem to think that Python is God's gift to readability, but it
frankly makes my eyes bleed.

 

[Steve Litt]

That's going in my quote file, in this form:
"If you ever want to really understand a problem domain, one way is
write it in three different languages, and get feedback in all three."
- Steve Litt

Objections?

None at all -- use it in good health, as long as others are also allowed to
use it

SteveT

Steve Litt
http://www.troubleshooters.com
(e-mail address removed)

 

[Elf M. Sternberg]

[...]

Variables are created when they're first referenced, and are `nil' by
default, so these lines make no difference.

mostly right, but here is one exception:

#!/opt/ruby/1.8/bin/ruby -w

if @foo==:bar
puts "hello"
end

gives a warning.

So the wording is "Variables are created when they're first
assigned", as in Python or Perl?

Elf

 

[Ezra Zygmuntowicz]

We feel exactly the opposite. That's your *why*.

The human eye picks out words by shape. We use spaces between
words to separate those shapes into easily digested chunks.
OneLongWord is not a shape we are use to, so we have to stop and
think. Unfortunately, spaces aren't allowed in programming
variables. The _ character is allowed though and the next best
thing, so we go with that.

This is all my opinion, of course.

James Edward Gray II

I have also heard that the underscore_name technique is easier for
Japanese folks to read and since ruby was written by Matz, that is
one reason to follow this convention.

Cheers-

-Ezra Zygmuntowicz
Yakima Herald-Republic
WebMaster
http://yakimaherald.com
509-577-7732
(e-mail address removed)

 

[Rich Morin]

Taking things a bit further, is there any reason why one shouldn't
use both capitalization and underscores in class names, as:

A_Class_Name

Would it confuse either the interpreter or a possible reader?

-r

 

[dblack]

Hi --

Taking things a bit further, is there any reason why one shouldn't
use both capitalization and underscores in class names, as:

A_Class_Name

Would it confuse either the interpreter or a possible reader?

Underscores are allowed in constant names, but they're usually used
when both parts are all uppercase, which is usually not true of class
names. So A_Class_Name would be parsed, and probably understood by
humans, but it sort of a pastiche of different styles or conventions.


David

 

[Chad Perrin]

Taking things a bit further, is there any reason why one shouldn't
use both capitalization and underscores in class names, as:

A_Class_Name

Would it confuse either the interpreter or a possible reader?

Probably not, but it would confuse the heck out of my fingers.

 

[Rich]

As Ezra stated elsewhere (and as frequently stated in the Perl
community), it's much more difficult for non-native English
speakers to read squishedCaps, and for that matter, it's not
always terribly simple for native English speakers to do so.

I can personally attest to this phenomenon, especially from
reading Japanese. After a semester of the language, and some
additional self-study, I can now (usually) tell the difference
between katakana, hiragana, and kanji in a sentence. And since
a common Japanese sentence won't contain any spaces at all, and
the fact that many Japanese words contain both kanji and
hiragana together, I gain more and more respect for any
non-English speakers reading my code.

I didn't think about that. I suppose Ruby's multi-lingual origins and
usage would rightly demand this sort of thing.

Which is more pleasing is apparently a matter of personal
preference. Which we should *use* isn't necessarily such
a selfish decision.

I'd have never considered an aesthetic judgement to be selfish, though
I suppose rendering my code unreadable by many over one could be ;-)

 

[Jonas Hartmann]

We feel exactly the opposite. That's your *why*.

The human eye picks out words by shape. We use spaces between words to
separate those shapes into easily digested chunks. OneLongWord is not
a shape we are use to, so we have to stop and think. Unfortunately,
spaces aren't allowed in programming variables. The _ character is
allowed though and the next best thing, so we go with that.

This is all my opinion, of course.

I share this, and I think ruby capable editors could be told to gray out underscores within variable and method names. (so that they are visible but can be easily ignored while reading).

just my 0.2 eurocent.

 

[Rich Morin]

The human eye picks out words by shape. We use spaces between words
to separate those shapes into easily digested chunks. OneLongWord is
not a shape we are use to, so we have to stop and think.
Unfortunately, spaces aren't allowed in programming variables. The _
character is allowed though and the next best thing, so we go with that.

What he said. Also, we need to optimize for the "read" case:

* Code is written once, but may be read many times.

* The reading may be done under great stress and time pressure.

* If information is discarded in the writing process, it may
not be possible to retrieve it in the reading process.

-r

 

[Francois Paul]

i guess this thread comes to something like:

when in Ruby do as the Rubyists do, or don't if it bugs you.