I'm not a long time Ruby coder, but I have coded for quite some time. I
wanted to ask the groups' opinion on being more explicit with Ruby code.
I like to code like this:
Kernel.puts("Print this string")
instead of this:
puts "Print this string"
To me, the first version is easier to read as I know where puts is
coming from (Kernel) and what it is encapsulating. I just wonder what
more experienced Ruby coders think of this? What would they think if
they saw several hundred lines of code written this way? Do most find
this type of explicitness unnecessary?
I can see how the second version is easier for people new to
programming, but it seems to me once they gain a bit of experience that
they may want to know more about the magic behind it all. So, a more
explicit code style may help them to see exactly how things get done in
Ruby.
Thanks for your thoughts and opinions on this,
Brad
I'm not a long time Ruby coder, but I have coded for quite some time. I wanted to ask the groups' opinion on being more explicit with Ruby code. I like to code like this:
Kernel.puts("Print this string")
instead of this:
puts "Print this string"
To me, the first version is easier to read as I know where puts is coming from (Kernel) and what it is encapsulating. I just wonder what more experienced Ruby coders think of this? What would they think if they saw several hundred lines of code written this way? Do most find this type of explicitness unnecessary?
You write code to express ideas and intentions to other developers. That includes your future self. If you have reason to think this amount of information is appropriate, then go for it.
But I suspect that, fairly soon, you'll internalize many Rubyisms, and then leaving out implicit receivers will seem to enhance, not degrade, communication.
If you think that that readers may have a problem with your code, it may be sufficient to leave comments explaining that all methods have a receiver, but in many cases the receiver may be omitted because the Ruby interpreter is smart enough to infer the correct one. And include a link to a basic tutorial.
The Ruby ground rules are fairly easy to pick up. There are subtleties in their application, of course, but most people do not need much reminder for common cases.
Brad, the two code snippets are not the same. The second sends the :puts message to self. The class of self inherits (possibly over several steps) from Object, which includes the Kernel module. So normally the two code snippets have the same effect, but this doesn't have to be.
If you
a) are sure that the :puts method isn't implemented anywhere on the inheritance chain for your current self object, or
b) explicitly want to prevent eventually calling another :puts method,
then you can code in the explicit form. For me personally, I only would use it in the case of b). a) seems to be too limiting for my taste.
IMHO you make Ruby more verbose than necessary. One of Ruby's
strengths is that it requires less typing and clutter. If someone
wants to find out where that method is coming from there are different
means:
You would make *me* wonder why the "Kernel." is in there. To me that
would convey that there is a different implementation of "puts" that
you want to prevent being called. So in my case it's actually
misleading - not more information. Of course I cannot speak for the
Ruby community but I'd suspect that it's a very widely accepted
convention to just use "puts" and thus your version would cause mild
irritation.
Kind regards
robert
···
2006/5/1, Brad <rtilley@vt.edu>:
I'm not a long time Ruby coder, but I have coded for quite some time. I
wanted to ask the groups' opinion on being more explicit with Ruby code.
I like to code like this:
Kernel.puts("Print this string")
instead of this:
puts "Print this string"
To me, the first version is easier to read as I know where puts is
coming from (Kernel) and what it is encapsulating. I just wonder what
more experienced Ruby coders think of this? What would they think if
they saw several hundred lines of code written this way? Do most find
this type of explicitness unnecessary?
I can see how the second version is easier for people new to
programming, but it seems to me once they gain a bit of experience that
they may want to know more about the magic behind it all. So, a more
explicit code style may help them to see exactly how things get done in
Ruby.
To me, the first version is easier to read as I know where puts is
coming from (Kernel) and what it is encapsulating. I just wonder what
more experienced Ruby coders think of this? What would they think if
they saw several hundred lines of code written this way? Do most find
this type of explicitness unnecessary?
I'm not that experienced Ruby programmer (I've just checked LoC of my
programs (research purpose apps) and it turned out to be 5,000), but I
think the above explicitness is unnecessary. Why should I have to know
that 'puts' is coming from Kernel via Objects every time I write puts?
You can just think of puts as keywords or commands. It is an
abstraction, isn't it?
I can see how the second version is easier for people new to
programming, but it seems to me once they gain a bit of experience that
they may want to know more about the magic behind it all. So, a more
explicit code style may help them to see exactly how things get done in
Ruby.
Studying under the hood is good for becoming seasoned programmer, but
anyone can learn from books or articles on the web as long as one tries
to learn. Moreover, it is not always needed to learn details to be a
good programmer.
As an example, do you think every J2EE programmers understand object
hierarchies involved in transactions/object pooling? The answer is
obviously "No". Nevertheless, people are quite good at writing J2EE
apps.
The same goes with Ruby. Please keep in mind that what we are trying to
solve is not what Ruby is, but domain problems at our hands. That's the
reason why 'puts' is better.
I personally would never put Kernel in front there. If I'm going to
qualify puts, it would be to specify the actual thing doing the putting
(or "receiving" the putting, heh), such as $stderr.puts or
my_opened_file.puts. I think putting Kernel in front draws attention to
something that ought to be left in the background. It might be akin to
seeing all the [serif construction lines][1] for every letter in text.
It also smacks of a lingering attachment to System.out.println.
My personal style with parentheses is to omit them only with
visually-single arguments. In style choices like these, I always try to
aim for clarity, rather than stick to a rule in all cases.
I'm not a long time Ruby coder, but I have coded for quite some time. I wanted to ask the groups' opinion on being more explicit with Ruby code. I like to code like this:
Kernel.puts("Print this string")
instead of this:
puts "Print this string"
One nice thing about using a bare 'puts' in your code is that you can override it as your code matures.
def puts(msg) @log.info(msg)
end
Anyway, even Kernel can be overridden/deleted. A similar hack can be seen in Derby, where you swap YAML into DRb:
Relax, drink a bottle of wine, and all that Java induced trauma will
float away...
(I take it you are a recovering Java programmer?)
John Carter Phone : (64)(3) 358 6639
Tait Electronics Fax : (64)(3) 359 4632
PO Box 1645 Christchurch Email : john.carter@tait.co.nz
New Zealand
Carter's Clarification of Murphy's Law.
"Things only ever go right so that they may go more spectacularly wrong later."
From this principle, all of life and physics may be deduced.
···
On Mon, 1 May 2006, Brad wrote:
I'm not a long time Ruby coder, but I have coded for quite some time. I
wanted to ask the groups' opinion on being more explicit with Ruby code.
I like to code like this:
In this case if I wanted to be more explicit I would use,
$stdout.puts "Print this string"
which is also the same thing, but also explicitly shows where the
printing is going.
Either way I'd probably not be so explicit and just stick with puts,
unless of course I'm doing something like,
def puts_my_stuff_to(thingy, message)
thingy.puts "My cool formated message: <#{message}>!"
end
puts_my_stuff_to $stdout, "Here's my message"
In my short experiance with Ruby, the less explicit I am in general, the
more I have an easier time of it. This is probably not so true in this
case (as far as I know) but getting used to not being explicit,
specifically using duck typing, can help the code be less brittle in
different contexts.
I too am fairly new to Ruby but a long time coder in other languages. I
find that the less that I have to be explicit the better it makes me
feel about my code. But if being more explicit helps you feel better
about your code, then you should probably just do what feels right.
I think that's right. I use to name my for loop control variables "index", but I actually got complaints that the name requires thought while we all recognize "i" instantly. I bet "puts" is pretty much the same in Ruby.
James Edward Gray II
···
On May 1, 2006, at 9:17 AM, James Britt wrote:
But I suspect that, fairly soon, you'll internalize many Rubyisms, and then leaving out implicit receivers will seem to enhance, not degrade, communication.
Moreover, it is not always needed to learn details to be a good
programmer.
Agreed. I spend a quite a lot of effort in learning the basics,
such as good algorithms and good datastructures. Also, when working, I
focus on the modelling of my programs, as in what functionality goes
where, DRY, who needs to know what etc. The inner workings of the tool at
hand, at present Ruby, is not something i delve into until I have to.
The same goes with Ruby. Please keep in mind that what we are trying to
solve is not what Ruby is, but domain problems at our hands.
Very nicely put, I agree wholeheartedly. Heinemer Hansson once said he
"wanted programs, not to be a programmer". I agree to that as well.
All the best
Jon Egil
···
On Tue, 2 May 2006, Minkoo Seo wrote:
--
Jon Egil Strand
Phone: +47 98232340
jes@luretanker.no
