A Stylish Critique
Before getting started, I feel compelled to point out that my dictionary defines a critique as "a detailed analysis and assessment of something." It seems like we often assume the worst of that word, but that's not how I intend it here.
The Ruby community seems to be talking about style guides lately. So let's talk about them.
The fact is that you will have many choices if you go looking for style guides for our favorite language. You can pick from:
- The old stuff
- Google's way
- GitHub's popular guide
- Guides from respected Rubyists, like Dan Kubb
- One of the many forks of the popular guides on GitHub
- And many more
It's obvious that Rubyists care about this topic. Let's see what's out there and consider what really is and is not useful from these guides.
What is a style guide really, and why do we even have them?
Defining style guides is surprisingly tough. I suspect they started out as formatting rules for code, but they have evolved pretty far beyond that now.
Most guides include general conventions that the author feels are important when writing the language in question. This can go all the way down to how to use certain constructs, opinions on what the author considers idiomatic, and syntax to outright avoid.
There's a great little trick you can do to improve the readability of your code. A common problem is dealing with methods that have a boolean flag arguments. Here's an example I ran into just today in a Rails application:
def rating_stars(..., clickable = false) # ... end
The problem with this is that you typically see calls like this scattered around the application:
<%= rating_stars(..., true) %>
Would you know what
truedid there if I hadn't shown you the name of the variable first? I didn't. I had to go hunting for that method definition.
Ironically the opposite problem, a magical dangling
false, is much more rare in my experience. That's typically the default for these kind of arguments and it just makes more sense and reads better to leave it out.
Anyway, the point is that we can typically improve the ease of understanding the common case. Remember that in Ruby
nilare false while everything else is true. That means that truth is very loosely defined and we can pass a lot of things for our boolean flag value. For example, after looking up the method and understanding what was needed, I chose to call it like this:
DSL Block Styles
There's an argument that rages in the Ruby camps: to
instance_eval()or not to
instance_eval(). Most often this argument is triggered by DSL discussions where we tend to want code like:
configurable.config do width 100 mode :wrap end
You can accomplish something like this by passing the block to
selfto an object that defines the
mode()methods. Of course changing
selfis always dangerous. We may have already been inside an object and planning to use methods from that namespace:
class MyObject include Configurable # to get the config() method shown above def initialize config do width calculate_width # a problem: may not work with instance_eval() end end private def calculate_width # the method we want to use # ... end end
In this example, if
width()comes from a different configuration object, we're in trouble. The
instance_eval()will shift the focus away from our
MyObjectinstance and we will get a
NoMethodErrorwhen we try to call
calculate_width(). This may prevent us from being able to use
Configurablein our code.
Do 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.