Forum: Ruby They say I write Ruby like Perl

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
slitt (Guest)
on 2005-12-08 03:16
(Received via mailing list)
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?

Thanks

SteveT

Steve Litt
Author:
   * Universal Troubleshooting Process courseware
   * Troubleshooting Techniques of the Successful Technologist
   * Rapid Learning: Secret Weapon of the Successful Technologist
Webmaster
   * Troubleshooters.Com
   * http://www.troubleshooters.com
slitt (Guest)
on 2005-12-08 03:24
(Received via mailing list)
On Wednesday 07 December 2005 09:13 pm, Steve Litt wrote:
> 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?
>
> Thanks
>
> SteveT

Whoops, the actual code is here:
http://www.troubleshooters.com/projects/Node.rb/do...,
with
test progarm here:
http://www.troubleshooters.com/projects/Node.rb/do...
and test data here:
http://www.troubleshooters.com/projects/Node.rb/do...

./testnode_parse < test.otl | less

Thanks

SteveT

Steve Litt
http://www.troubleshooters.com
slitt@troubleshooters.com
logancapaldo (Guest)
on 2005-12-08 03:24
(Received via mailing list)
On Dec 7, 2005, at 9:13 PM, Steve Litt wrote:

>
>
Well with merely skimming your code, I would suggest replacing
camelCase method names with underscore_style ones. Other than that,
it doesn't seem too perlish to me, I don't see a mess of $'s anyway, ;)
dblack (Guest)
on 2005-12-08 03:36
(Received via mailing list)
Hi --

On Thu, 8 Dec 2005, Steve Litt wrote:

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

For style things (avoiding camelCase for methods and local variables,
two-character indentation, etc.), you can look at (most of :-) the
Ruby code in the standard library.  Also there's a good style guide
at:
http://pub.cozmixng.org/~the-rwiki/rw-cgi.rb?cmd=v...
(not beyond dispute in every detail but very much in harmony with
traditional Ruby style).

Looking a bit at the code itself, I think there's a certain amount of
verbosity that you could cut down on -- and still be nice and clear
(which is an area where Ruby shines).  For example, you have this:

 	def counttabs(s)
 		answer = s.index(/[^\t]/)
 		answer = 0 if not answer
 		return answer
 	end

which could be:

    def counttabs(s)
      s.index(/[^\t]/) || 0
    end

(I'm not sure about the name -- it's not actually counting tabs -- but
I'll leave that to you :-)  Of course there's no imperative to make
things as short as they can be -- but one thing I like about Ruby is
that one's code tends to get more concise *and* to get more clear, as
one works on a project.


David

--
David A. Black
dblack@wobblini.net

"Ruby for Rails", forthcoming from Manning Publications, April 2006!
mike (Guest)
on 2005-12-08 03:40
(Received via mailing list)
On 7-Dec-2005, at 9:23 PM, Steve Litt wrote:

>> Thanks
> http://www.troubleshooters.com/projects/Node.rb/do...
> test.otl

For:

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

You could use these (assuming you use @attributes as the instance
variable in place of @attribs)

attr_accessor :attributes
def has_attributes?
   @attributes.empty?
end

and if you wanted to use a [] notation to access the attributes then
you could say

def []=(key, val)
   @attributes[key] = v
end

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

Hope this helps,

Mike (Perl refugee)


--

Mike Stok <mike@stok.co.uk>
http://www.stok.co.uk/~mike/

The "`Stok' disclaimers" apply.
djberg96 (Guest)
on 2005-12-08 03:44
(Received via mailing list)
Steve Litt wrote:
> > SteveT
> Thanks
>
> SteveT
>
> Steve Litt
> http://www.troubleshooters.com
> slitt@troubleshooters.com

Hi Steve,

Here are some quick pointers:

* No need to subclass Object.  All classes inherit from Object
automatically
* You don't need most of the explict getters and setters.  That's what
attr_accessor is for
* Ditch the camel case
* No need for semicolons
* Rather than method names like "setParent", use "parent=".

Regards,

Dan
leavengood (Guest)
on 2005-12-08 03:53
(Received via mailing list)
On 12/7/05, Steve Litt <slitt@earthlink.net> wrote:
>
> In future software, what could I do to write
> in a more Ruby-like fashion?

This definitely doesn't look like idiomatic Ruby, and here are a few
glaring things I can see:

1. The general naming convention is lowercase with underscores for
variables and methods. You have sort of a mix of "runitalltogether"
variables, i.e. prevsibling, and then the CamelCase methods like
insertSiblingAfterYou. Those should be prev_sibling and
insert_sibling_after_you (though that last one is a bit too long.)

2. Generally when initializing member variables from parameters in
initialize, parallel assignment is used, i.e. "@name, @type, @value =
name, type, value".

3. You have "class Node < Object", which is redundant since classes
subclass object by default:

irb(main):065:0> class Node;end
=> nil
irb(main):066:0> Node.superclass
=> Object

4. There is not a single block used in your code. Ruby without blocks
is like C++ without classes. In other words you can get by, but you
lose A LOT of power and beautiful code. Most of the those loops could
be iterators with blocks, especially this one:

for lineno in 1..lines.length
			line = lines[lineno-1]
...

How about lines.each?

Ryan
ara.t.howard (Guest)
on 2005-12-08 04:13
(Received via mailing list)
On Thu, 8 Dec 2005, Steve Litt wrote:

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

here are some thoughts:

     class Node < Object
             def initialize(nam, type, value)
                     super()
                     @name = nam
                     @type = type
                     @value = value
                     @attribs = {}
                     @parent = nil
                     @prevsibling = nil
                     @nextsibling = nil
                     @firstchild = nil
                     @lastchild = nil
             end

             attr_reader :name, :type, :value
             attr_writer :name, :type, :value
             attr_reader :parent, :prevsibling, :nextsibling,
:firstchild, :lastchild

             def setAttributes(attribs) @attribs = attribs; end
             def getAttributes() return @attribs; end
             def hasAttributes() return @attribs != nil; end
             def setAttribute(key, value) @attribs[key] = value; end
             def getAttribute(key) return @attribs[key]; end
             def hasAttribute(key) return @attribs[key] != nil; end

i would condensed into

   class Node

     ATTRIBUTES = %w(
       name type value attribs parent prevsibling nextsibling firstchild
lastchild
     ).each{|a| attr_accessor a; alias_method "#{ a }?", a}

     def initialize name, type, value, attribs = {}
       @name, @type, @value, @attribs = name, type, value, attribs
     end

don't bother with access control - sometimes it's needed (object
available on
the web) but sometimes it's not.  with it you are saying "my code has no
mistakes - you will not need access to these vars" by saying
'read_only'.  i've
probably fixed about 50 bugs in code where i had to subvert the access
control
by doing

   obj.instance_var_set "@broken", "fixed"

because of this kind of design.  don't use it where it's not critical.

dont' use get/set/has - use attr, attr=, attr?

         def setParent(parent)
                 @parent = parent
                 node = self
                 while node.prevsibling
                         node = node.prevsibling
                 end
                 @parent.firstchild = node
                 node = self
                 while node.nextsibling
                         node = node.nextsibling
                 end
                 @parent.lastchild = node
                 @parent
         end

could be

       def parent= parent
         parent.firstchild = oldest
         parent.lastchild = youngest
         @parent = parent
       end
       def oldest
         node = self
         node = node.prevsibling while node.prevsibling
         node
       end
       def youngest
         node = self
         node = node.nextsibling while node.nextsibling
         node
       end

which isn't shorter - until the next time you write that code.

food for thought.

cheers.

-a
rampant (Guest)
on 2005-12-08 05:14
(Received via mailing list)
2005/12/8, Steve Litt <slitt@earthlink.net>:
> 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?
>

Hi Steve,

From the testing code, you have:

def rvExit(checker, level)
		for i in 0...level
			print "\t"
		end
		print checker.value
		print ", Line ", checker.getAttribute("_lineno"), "\n"
end

Which could be written as:

def reverse_exit(checker, level)
  puts "#{"\t" * level}#{checker.value}, Line #{checker[:_line_number]}"
end

No need for the for loop, using print, getAttribute (use []= instead),
or appending a "\n" manually. And with all that saving, you can afford
to write out full method names!

Take a look at Test::Unit for running your tests:
http://www.ruby-doc.org/stdlib/libdoc/test/unit/rd...

You could use it to automate all your tests, so you wouldn't need
comments like "Change to b and watch what happens".

Other things:

attr_reader :commentchar, :skipblanks
attr_writer :commentchar, :skipblanks

could be:

attr_accessor :comment_char, :skip_blanks

and:

def skipLine?(line)
		regex_comment = Regexp.new("^\\s*" + @commentchar )
		if @skipblanks and line =~ /^\s*$/
			return true
		elsif @commentchar and regex_comment.match(line)
			return true
		else
			return false
		end
end

could be:

def skip_line?(line)
  return true if @skip_blanks and line =~ /^\s*$/
  return @comment_char and /^\s*#{@comment_char}/.match(line)
end

You get the idea :-)

Good thread, thanks!

hth,
Douglas
penryu (Guest)
on 2005-12-08 08:41
(Received via mailing list)
Ryan Leavengood <leavengood@gmail.com> wrote:
> CamelCase methods like insertSiblingAfterYou. Those should be
> prev_sibling and insert_sibling_after_you (though that last
> one is a bit too long.)

This recurring label "CamelCase" (or sometimes "camelCase")
seems to come up a lot, and I can't help thinking "camel" is
a reference to Perl...  This is strange for me, as a veteran
Perl programmer.

I've always read/heard/been told that the preferred method of
naming variables in Perl a_var_name style.  People who used
StudlyCaps or javaCaps were usually accused of having come from
either Visual Basic (or other Win32 tech) or Java, respectively.

Upon looking, I do see some Perl modules using StudlyCaps
(DirHandle, FileCache, ExtUtils, et al), but this is hardly more
prominent than Ruby's MatchData, NilClass, FileTest, or
ObjectSpace.

I guess my comment is two-fold.  One, can we really single out
Perl as the progenitor of this practice?  And two, to state that
this naming scheme is not an endorsed practice for variable
names to my knowledge.

Cheers,
Tim Hammerquist
penryu (Guest)
on 2005-12-08 08:49
(Received via mailing list)
Tim Hammerquist <penryu@saiyix.ath.cx> wrote:
> I guess my comment is two-fold.  One, can we really single out
> Perl as the progenitor of this practice?  And two, to state
> that this naming scheme is not an endorsed practice for
> variable names to my knowledge.

Nor for method names.
blargity (Guest)
on 2005-12-08 08:53
(Received via mailing list)
On Thursday 08 December 2005 01:37, Tim Hammerquist wrote:
> Ryan Leavengood <leavengood@gmail.com> wrote:
> This recurring label "CamelCase" (or sometimes "camelCase")
> seems to come up a lot, and I can't help thinking "camel" is
> a reference to Perl...

Why?  CamelCase simply refers to the humps that appear in the middle of
words
when youUppercaseTheMiddleWord.  At least that's how I've always thought
of
it.  I don't think anyone's pointing fingers at Perl.  Hell, I came from
C++
and my first real Ruby code has all methods named in lowerCamelCase. -_-
dandiebolt (Guest)
on 2005-12-08 09:06
(Received via mailing list)
CamelCase has been sporadically used since ancient times:

  http://en.wikipedia.org/wiki/CamelCase#History

  "CamelCase" is not explicitly mentioned in the style guide but the
examples show upper CamelCase for Class and Modules and lower case with
underscores at word boundaries for variables and methods:

http://pub.cozmixng.org/~the-rwiki/rw-cgi.rb?cmd=v...
dandiebolt (Guest)
on 2005-12-08 10:40
(Received via mailing list)
> Hell, I came from C++ and my first real Ruby code has all methods named in 
lowerCamelCase.

  "There is no place in Ruby where lowerCamelCase is ever used. "
  http://www.rubygarden.org/ruby?RubyStyleGuide

  See Also slide 10 of Schroeder's Ruby Course:

  I Variables and methods should be written in snake_case
  I Class Names should be written in CamelCase
  I Constants should be written ALL_UPPERCASE

  http://ruby.brian-schroeder.de/course/slides.pdf
slitt (Guest)
on 2005-12-08 13:20
(Received via mailing list)
On Thursday 08 December 2005 02:37 am, Tim Hammerquist wrote:
[clip]
> This recurring label "CamelCase" (or sometimes "camelCase")
> seems to come up a lot, and I can't help thinking "camel" is
> a reference to Perl...

Hi Tim,

I had assumed it was called "CamelCase" because it had humps :-)

SteveT

Steve Litt
http://www.troubleshooters.com
slitt@troubleshooters.com
snowzone5 (Guest)
on 2005-12-08 14:22
(Received via mailing list)
Steve Litt wrote on 12/8/2005 7:17 AM:

>>This recurring label "CamelCase" (or sometimes "camelCase")
>>seems to come up a lot, and I can't help thinking "camel" is
>>a reference to Perl...

> I had assumed it was called "CamelCase" because it had humps :-)

the o'reilly "programming perl" book features a camel on the front.
just a guess :)
chrisgame (Guest)
on 2005-12-08 14:30
(Received via mailing list)
Ryan Leavengood wrote:

> 1. The general naming convention is lowercase with underscores for
> variables and methods. You have sort of a mix of
> "runitalltogether" variables, i.e. prevsibling, and then the
> CamelCase methods like insertSiblingAfterYou. Those should be
> prev_sibling and insert_sibling_after_you (though that last one
> is a bit too long.)

Who says? Just a style/convention issue surely. Readability doesn't
suffer, nor does execution.

--
Chris Game

Computers are only human.
dblack (Guest)
on 2005-12-08 15:22
(Received via mailing list)
Hi --

On Thu, 8 Dec 2005, Chris Game wrote:

> suffer, nor does execution.
"Just"? :-)  You're right, though, in the sense that the parser
doesn't enforce traditional style.  You can write Ruby that looks like
lots of other languages.  Then when you go back to those languages,
you can write variable names like_this because you now come from
Ruby....

Or just break the cycle and use the conventions of whatever language
you're using *when* you're using it :-)


David

--
David A. Black
dblack@wobblini.net

"Ruby for Rails", forthcoming from Manning Publications, April 2006!
Debd79ae164c1f28ec6cc6b8e2454840?d=identicon&s=25 Bill G. (agorilla)
on 2005-12-08 15:31
(Received via mailing list)
On 12/8/05, Chris Game <chrisgame@example.net> wrote:
> suffer, nor does execution.
Personally, I think readability does suffer.  The wordier it gets, the
more I have to think.  Why not a simple 'append_sibling'?
58aa8536f985277ebef53fa931863a3e?d=identicon&s=25 James G. (bbazzarrakk)
on 2005-12-08 15:39
(Received via mailing list)
On Dec 8, 2005, at 7:27 AM, Chris Game wrote:

> Who says? Just a style/convention issue surely. Readability doesn't
> suffer, nor does execution.

It's not a syntax rule of Ruby, no.  But part of learning a language
is learning to speak it as the native speakers do.

James Edward Gray II
rjseagraves (Guest)
on 2005-12-08 15:44
(Received via mailing list)
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.
58aa8536f985277ebef53fa931863a3e?d=identicon&s=25 James G. (bbazzarrakk)
on 2005-12-08 15:44
(Received via mailing list)
On Dec 8, 2005, at 8:27 AM, Rich wrote:

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

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
perrin (Guest)
on 2005-12-08 15:44
(Received via mailing list)
On Thu, Dec 08, 2005 at 11:27:23PM +0900, Rich wrote:
> 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.

More to the point, from my point of view, it's easier to type without
being made unreadable (where it == lowerCamelCase) and actually uses
rather less keystrokes.

That being said, however, I tend to be willing to bend to convention on
matters like this: it makes collaboration easier.

--
Chad Perrin [ CCD CopyWrite | http://ccd.apotheon.org ]

unix virus: If you're using a unixlike OS, please forward
this to 20 others and erase your system partition.
francois (Guest)
on 2005-12-08 15:44
(Received via mailing list)
conventions make it easier for collaboration. If you are not interested
in sharing code, or can't forsee anybody else having to maintain your
code - then obviously do as you wish.
but if you were to submit to collaborative projects or you want to learn
from reading other people's code it would be wize to follw the
conventions.
The conventions help readability in the sense that different 'parts of
speach' is obvious to the eye.
joevandyk (Guest)
on 2005-12-08 15:52
(Received via mailing list)
On 12/8/05, Chad Perrin <perrin@apotheon.com> wrote:
> rather less keystrokes.
Don't see how using lowerCamelCase uses less keystrokes than
lower_camel_case.  I pressed 16 keys to type of of them.  :-)
slitt (Guest)
on 2005-12-08 16:00
(Received via mailing list)
On Thursday 08 December 2005 09:29 am, Bill Guindon wrote:
> > suffer, nor does execution.
>
> 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
slitt@troubleshooters.com
francois (Guest)
on 2005-12-08 16:00
(Received via mailing list)
lower<shift>camel<shift>case

lower<shift>-camel<shift>-case

but for the readability i'd type the two extra keystrokes every time!
30804046d28e30e9492f5309a57a6c31?d=identicon&s=25 Daniel S. (dasch)
on 2005-12-08 16:04
(Received via mailing list)
On Wednesday 07 December 2005 09:13 pm, Steve Litt wrote:
> 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
joevandyk (Guest)
on 2005-12-08 16:08
(Received via mailing list)
On 12/8/05, Francois Paul <francois@bagasie.com> wrote:
> 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.
mental (Guest)
on 2005-12-08 16:08
(Received via mailing list)
Quoting Daniel Schierbeck <daniel.schierbeck@gmail.com>:

>  > super()
> You don't need the parantheses

Well, that's one to be careful about.  If you omit the parenthesis
from super(), it will be called with the same arguments you got.

When that's zero arguments, there's no difference, but other times
it can bite you... it's not necessarily a bad idea to parenthesize
up defensively.

-mental
perrin (Guest)
on 2005-12-08 16:54
(Received via mailing list)
On Thu, Dec 08, 2005 at 11:59:35PM +0900, Francois Paul wrote:
> 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 [ CCD CopyWrite | http://ccd.apotheon.org ]

unix virus: If you're using a unixlike OS, please forward
this to 20 others and erase your system partition.
perrin (Guest)
on 2005-12-08 17:02
(Received via mailing list)
On Thu, Dec 08, 2005 at 11:58:17PM +0900, Steve Litt wrote:
>
> 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?

--
Chad Perrin [ CCD CopyWrite | http://ccd.apotheon.org ]

unix virus: If you're using a unixlike OS, please forward
this to 20 others and erase your system partition.
dblack (Guest)
on 2005-12-08 17:02
(Received via mailing list)
Hi --

On Thu, 8 Dec 2005, Rich wrote:

> 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

--
David A. Black
dblack@wobblini.net

"Ruby for Rails", forthcoming from Manning Publications, April 2006!
dblack (Guest)
on 2005-12-08 17:06
(Received via mailing list)
Hi --

On Fri, 9 Dec 2005, Chad Perrin wrote:

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

--
David A. Black
dblack@wobblini.net

"Ruby for Rails", forthcoming from Manning Publications, April 2006!
perrin (Guest)
on 2005-12-08 17:52
(Received via mailing list)
On Fri, Dec 09, 2005 at 01:02:04AM +0900, dblack@wobblini.net wrote:
>
> 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.

--
Chad Perrin [ CCD CopyWrite | http://ccd.apotheon.org ]

unix virus: If you're using a unixlike OS, please forward
this to 20 others and erase your system partition.
clr10.10.randomuser (Guest)
on 2005-12-08 18:08
(Received via mailing list)
[...]

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

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)
slitt (Guest)
on 2005-12-08 18:50
(Received via mailing list)
On Thursday 08 December 2005 10:58 am, Chad Perrin wrote:
> 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
slitt@troubleshooters.com
penryu (Guest)
on 2005-12-08 19:10
(Received via mailing list)
Kevin Brown <blargity@gmail.com> wrote:
> Thursday 08 December 2005 01:37, Tim Hammerquist wrote:
> > This recurring label "CamelCase" (or sometimes "camelCase")
> > seems to come up a lot, and I can't help thinking "camel" is
> > a reference to Perl...
>
> Why?  CamelCase simply refers to the humps that appear in the
> middle of words when youUppercaseTheMiddleWord.  At least
> that's how I've always thought of it.  I don't think anyone's
> pointing fingers at Perl.  Hell, I came from C++ and my first
> real Ruby code has all methods named in lowerCamelCase. -_-

Ah. Now it all makes sense.  Thanks!

Tim Hammerquist
penryu (Guest)
on 2005-12-08 19:10
(Received via mailing list)
tony summerfelt <snowzone5@hotmail.com> wrote:
> Steve Litt wrote on 12/8/2005 7:17 AM:
> > >This recurring label "CamelCase" (or sometimes "camelCase")
> > >seems to come up a lot, and I can't help thinking "camel"
> > >is a reference to Perl...
>
> > I had assumed it was called "CamelCase" because it had humps
> > :-)
>
> the o'reilly "programming perl" book features a camel on the
> front.  just a guess :)

Yeah.  And it's commonly called "the camel book".  Also,
O'Reilly pastes that camel image on just about everything it
does related to perl.  E.g., the image at top, as well as the
favicon.ico, at http://perl.com/ .

I guess it just shows how much perl I have to sift through to
get better at ruby.

Thanks!

Tim Hammerquist
elf (Guest)
on 2005-12-08 19:51
(Received via mailing list)
Patrick Gundlach <clr10.10.randomuser@spamgourmet.com> writes:

> 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 (Guest)
on 2005-12-08 20:45
(Received via mailing list)
On Dec 8, 2005, at 6:42 AM, James Edward Gray II wrote:

>
>
>

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
ezra@yakima-herald.com
rdm (Guest)
on 2005-12-08 20:49
(Received via mailing list)
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 (Guest)
on 2005-12-08 21:01
(Received via mailing list)
Hi --

On Fri, 9 Dec 2005, Rich Morin wrote:

> 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

--
David A. Black
dblack@wobblini.net

"Ruby for Rails", forthcoming from Manning Publications, April 2006!
mreed (Guest)
on 2005-12-08 22:23
(Received via mailing list)
Tim Hammerquist <penryu@saiyix.ath.cx> writes:
>> real Ruby code has all methods named in lowerCamelCase. -_-
>Ah. Now it all makes sense.  Thanks!

Yeah, the term "camelCase" doesn't have anything to do with Perl, and I
don't
even think that the style is particularly prevalent in Perl, but I
haven't
scanned CPAN to see.  It is, on the other hand, the official preferred
style in
Java, used throughout the standard Java class library and by most Java
development shops.  It's also closely associated with Hungarian
Notation, which
is prevalent in Microsoft code (that is, code written by them and code
written
for their platforms) pretty much irrespective of language (VC++, C#, VB,
etc.).
mreed (Guest)
on 2005-12-08 22:31
(Received via mailing list)
Ezra Zygmuntowicz <ezra@yakimaherald.com> writes:
>> 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.

I'd say, rather,
"*Fortunately*, spaces aren't allowed in programming variables."

Spaces *are* allowed in identifiers in AppleScript, while simultaneously
being
used as separator, and the result can be quite confusing.  I pretty much
don't
read AppleScript without using an IDE that underlines recognized
identifiers:
an underlined space means the two underlined words on either side of it
are all
one long identifier, while a non-underlined space means they're two
separate
keywords.
penryu (Guest)
on 2005-12-08 22:35
(Received via mailing list)
Elf M. Sternberg <elf@drizzle.com> wrote:
> So the wording is "Variables are created when they're first
> assigned", as in Python or Perl?

Perl takes this a bit farther, and calls it autovivification.
(It's a very useful feature when needed, but can be confusing.

Aside from the standard "assignmeng" such as:

    $string = "a string";
    @array = qw/ a list of stuff /;

Which both declare and define a scalar varable, and an array,
respectively.

Perl will also do:

    $other_array[3] = "arbitrary stuff";
    $some_hash{name} = "random j. programmer";

The first statement will at once: (1) create an array
@other_array and (2) set it's fourth element to a string.  The
second statement will at once (1) create a hash %some_hash, and
(2) assign a string value to it's "name" key.

This feature is used less since the 'use strict;' pragma has
become such an habitual feature in scripts.

Cheers,
Tim Hammerquist
perrin (Guest)
on 2005-12-08 22:39
(Received via mailing list)
On Fri, Dec 09, 2005 at 04:48:07AM +0900, Rich Morin wrote:
> 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.

--
Chad Perrin [ CCD CopyWrite | http://ccd.apotheon.org ]

unix virus: If you're using a unixlike OS, please forward
this to 20 others and erase your system partition.
penryu (Guest)
on 2005-12-08 22:43
(Received via mailing list)
Rich <rjseagraves@gmail.com> wrote:
> 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.

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.

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

Cheers,
Tim Hammerquist
rjseagraves (Guest)
on 2005-12-08 22:56
(Received via mailing list)
On 12/8/05, Tim Hammerquist <penryu@saiyix.ath.cx> wrote:
> 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 ;-)
Mail (Guest)
on 2005-12-09 03:28
(Received via mailing list)
James Edward Gray II wrote:
> 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.
rdm (Guest)
on 2005-12-09 04:01
(Received via mailing list)
At 11:42 PM +0900 12/8/05, James Edward Gray II wrote:
>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 (Guest)
on 2005-12-09 09:18
(Received via mailing list)
i guess this thread comes to something like:

when in Ruby do as the Rubyists do, or don't if it bugs you.
chneukirchen (Guest)
on 2005-12-09 11:17
(Received via mailing list)
Rich Morin <rdm@cfcl.com> writes:

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

It would remind people too much of Ada.
kero (Guest)
on 2005-12-09 12:35
(Received via mailing list)
>>> 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.

raise BrainDamagedException(Java)

We like UpperCamelCase, but don't like the lowerCamelCaseCompromise.

Part of it is just getting used to, but ...

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

Gray out? No way. Have you ever printed var_with_underscore on a printer
that places your underscore lower than you want? Absolutely unreadable.

I think that the underscore is *not* a space and *not* a dot, but
clearly,
visibly connects the words. Especially in Ruby where "method param" is
perfectly valid, but totally different from the equally valid
"method_param".

When I tried SciTe (I think it was scite) recently, some folding striked
the
this-is-folded-line right through the underscores. That was an immediate
turn-off for me.

Bye,
Kero.

PS: old habits die hard. Accidentally, I came from Java to Ruby, too.
Yes, I
frowned upon the underscores when I started (at the time, we had the
printer
mentioned above at work; a2ps helps). Right now, I think it is 'just a
convention' and should be followed. For completeness, when I started
with
Java, I frowned upon lowerCamelCase. I still do.
slitt (Guest)
on 2005-12-09 13:41
(Received via mailing list)
On Friday 09 December 2005 03:17 am, Francois Paul wrote:
> i guess this thread comes to something like:
>
> when in Ruby do as the Rubyists do, or don't if it bugs you.

Yes, and I'd like to thank everyone who gave me their ideas. Most of the
ideas
I'll use instantly. A few I might not. I see parallel assignment as less
readable than individual assignment statements.

I really love all the shortcuts Ruby gives you to get things done. And I
love
that the shortcuts don't harm encapsulation or other positive code
qualities.

For awhile I was trying to get Node.pm to use two iterators with blocks
instead of the traditional callback routines (actually in addition -- I
want
to keep all features in Node.pm and Node.py), but there's not a yield_a
and
yield_b command, so I couldn't do it with both the entry and exit
callbacks,
and having them each fire at the right time is vital.

Once again, thanks everyone -- it was like Ruby Boot Camp.

SteveT

Steve Litt
http://www.troubleshooters.com
slitt@troubleshooters.com
unknown (Guest)
on 2005-12-12 04:57
(Received via mailing list)
On Dec 9, 2005, at 7:39 AM, Steve Litt wrote:
> For awhile I was trying to get Node.pm to use two iterators with
> blocks
> instead of the traditional callback routines (actually in addition
> -- I want
> to keep all features in Node.pm and Node.py), but there's not a
> yield_a and
> yield_b command, so I couldn't do it with both the entry and exit
> callbacks,
> and having them each fire at the right time is vital.

Just capture the blocks into Proc objects and use Proc#call to invoke
the block:

	def on_entry(&block)
	  @on_entry = block
	end

	def on_exit(&block)
	  @on_exit = block
         end

	def main
	   @on_entry && @on_entry.call( # entry args go here)
	   # do stuff
	   @on_exit && @on_exit.call( # exit args go here)
	end

Maybe this will give you some ideas.


Gary Wright
Eivind Eklund (Guest)
on 2005-12-12 18:58
(Received via mailing list)
On 12/8/05, Rich <rjseagraves@gmail.com> wrote:
> 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.

I'll say why I tend to insist on it: Because more or less any
consistent convention makes it easier to work with code than having
code that is mixed between two or more different conventions.  Ruby
has a convention that is followed a lot, including being in all the
standard libraries.

This means that your code can either be single convention - following
that convention - or it can be multi-convention, by adding your own
style in addition to the standard one.  I consider single convention
to more or less always be better.

Eivind.
Jim McFarland (Guest)
on 2005-12-12 19:13
(Received via mailing list)
On 12/8/05, Rich <rjseagraves@gmail.com> wrote:
> 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.

I was "raised" on C and then went to Java and am now learning Ruby, so
underscores are I what I started with.  In trying to conform to the
Ruby conventions, it is a welcome thing to go back to underscores
instead of camelCase, but that's just my own preference.

later...
jim
This topic is locked and can not be replied to.