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 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 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.
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.
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.
But I suspect that, fairly soon, you’ll internalize many Rubyisms,
and then leaving out implicit receivers will seem to enhance, not
degrade, communication.
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.
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.
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.
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.
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”)
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 C. Phone : (64)(3) 358 6639
Tait Electronics Fax : (64)(3) 359 4632
PO Box 1645 Christchurch Email : [email protected]
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.
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
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
