Ruby Best Practices

Appendix C. Ruby Worst Practices

If you’ve read through most of this book, you’ll notice that it doesn’t have much of a “Do this, not that” theme. Ruby as a language doesn’t fit well into that framework, as there are always exceptions to any rule you can come up with.

However, there are certainly a few things you really shouldn’t do, unless you know exactly why you are doing them. This appendix is meant to cover a handful of those scenarios and show you some better alternatives. I’ve done my best to stick to issues that I’ve been bit by myself, in the hopes that I can offer some practical advice for problems you might actually have run into.

A bad practice in programming shouldn’t simply be characterized as some ill-defined aesthetic imposed upon folks by the “experts.” Instead, we can often track antipatterns in code down to either flaws in the high-level design of an object-oriented system, or failed attempts at cleverness in the underlying feature implementations. These bits of unsavory code produced by bad habits or the misunderstanding of certain Ruby peculiarities can be a drag on your whole project, creating substantial technical debt as they accumulate.

We’ll start with the high-level design issues and then move on to the common sticking points when implementing tricky Ruby features. Making an improvement to even a couple of these problem areas will make a major difference, so even if you already know about most of these pitfalls, you might find one or two tips that will go ...