-
7
JAN
2009The Evils of the For Loop
I've never liked the
for…in
loop in Ruby. I cringe every time I see it in examples (Rails seems to put it in views a lot) and I tend to switch it to aneach()
call. It really bugs me.That's mostly just my gut reaction, but if I had to put it into words it's that I fell in love with Ruby's iterators early on and
for
just doesn't seem to fit in well with them. I don't think that's just my emotions talking either, it really doesn't fit in. I'll try to show you why I say that.First, let's see what I'm talking about. We are all pretty comfortable with
each()
, right?(1..3).each { |i| p i } # >> 1 # >> 2 # >> 3
I doubt that surprises anyone. Many of you probably also know that Ruby allows you to write that as:
for i in 1..3 p i end # >> 1 # >> 2 # >> 3
That's almost the same thing. It really does use
each()
under the hood, for example:class MyEachThing def each yield 1 yield 42 yield 2 yield 42 yield 3 end end for i in MyEachThing.new p i end # >> 1 # >> 42 # >> 2 # >> 42 # >> 3
-
2
AUG
2006RegexpChallenge
Just recently I have been working with two different people to improve their regular expression skills. To help me in this endeavor, I built a trivial little script we have been using in IRb. To get started, you construct a new challenge object and add a couple of challenges:
>> reg_chal = RegexpChallenge.new No challenges. => >> reg_chal.challenge("Gray, James", "James", "The names can vary.") => nil >> reg_chal.challenge("abbbbbbbc bc", 10) => nil >> reg_chal.challenge( " \n\t ", nil, ?> "We want to test for non-space data." ) => nil >> reg_chal.challenge( "cogs 9, widgets 12, ...", "12", ?> "The numbers can vary." ) => nil >> reg_chal.challenge( "I'm a simple sentence, with words.", ?> %w[I'm a simple sentence with words] ) => nil
You can ask for challenges to see what you would like to solve:
>> reg_chal.challenges Challenge #0: Input: "Gray, James" Output: "James" Note: "The names can vary." Challenge #1: Input: "abbbbbbbc bc" Output: 10 Challenge #2: Input: " \n\t " Output: nil Note: "We want to test for non-space data." Challenge #3: Input: "cogs 9, widgets 12, ..." Output: "12" Note: "The numbers can vary." Challenge #4: Input: "I'm a simple sentence, with words." Output: ["I'm", "a", "simple", "sentence", "with", "words"] => nil
-
16
JUL
2006String Has Other Methods Besides =~/match() and sub()
Ask anyone who knows me and they will tell you I'm a huge fan of regular expressions. I use them all the time and my
FasterCSV
library is a regular expression powered parser. However, even I know they are not for everything, and lately I keep running into almost comical examples of misuse. Here are some of my favorites.First, we have:
str =~ /=/
That snippet is like calling for a military escort (the regular expression engine) to see you safely to the grocery store down the block. That's fun, but probably overkill. In this case, a call to
include?()
will do the trick:str.include?("=")
That may be more like riding your bike to the grocery store, but it gets the job done and is a bit faster to boot.
Funny example number two. I've seen this before:
str =~ /\Aquit\Z/
Again, the regular expression engine appreciates the love, but you really just want
==
:str == "quit"
Even for some of the fancier stuff, you don't need a full blown regular expression. For example, this:
-
13
JUN
2006Do I Need (These Parentheses()?)
If you came to Ruby via the Learn to Program book or just don't yet have a consistent set of rules for when you do and don't need parentheses in Ruby code, this post is for you.
I have nothing against Learn to Program, just to be clear. A member of my family is learning Ruby from it and it's going pretty well. I recommend it. However, Chris is a little inconsistent with his use of parentheses in the code samples, and worse, he doesn't really give you a good set of rules to decide when to make the choice. No problem. Let me give you the rules.
I'm a chess player. In learning chess, you really go through two phases. First, you learn the rules of strategy. These will make you good because the rules are designed to help you avoid common mistakes. Now, to get great, you go through the second phase: learning when to break the strategy rules. Ruby is exactly the same.
Here's the only rule of strategy you need to learn to get good: methods need parentheses around their arguments.