Ruby Best Practices

Conclusions

This appendix doesn’t come close to covering all the trouble that you can get yourself into with Ruby. It does, however, cover some of the most common sources of trouble and confusion and shows some much less painful alternatives.

When it comes to design, much can be gained by simply reducing complexity. If the path you’re on seems too difficult, odds are that it can be made a lot easier if you just think about it in a different way. As for “clever” implementation tricks and shortcuts, they can be more trouble than they’re worth if they come at the expense of clarity or maintainability of your code.

Put simply, the worst practices in Ruby are ones that make you work much harder than you have to. If you start to introduce code that seems really cool at first, but later is shown to introduce complicated faults at the corner cases, it is generally wise to just rip it out and start fresh with something a little less exciting that’s more reliable.

If you maintain the balancing act between creative approaches to your problems and ones that work without introducing excess complexity, you’ll have a very happy time writing Ruby code. Because Ruby gives you the power to do both good and evil, it’s ultimately up to you how you want to maintain your projects. However, code that is maintainable and predictable is much more of a joy to work with than fragile and sloppy hacks that have been simply duct-taped together.

Now that we have reached the very end of this book, I trust that you ...