Ruby Best Practices

Conclusions

I found myself getting physically tired writing this chapter. If you feel that way after reading it, I don’t really blame you. People will tell you again and again that this sort of coding is extremely hard or fueled by some sort of magic. Others will tell you it’s the bee’s knees and that you should use it all the time, everywhere, whenever you can. Neither statement is true.

The truth of the matter is that taken individually, each of Ruby’s dynamic features is relatively straightforward, and can be a valuable tool if used properly. But looking at all of this stuff and trying to use it as much as possible in your code would be absolutely overwhelming.

My general rule of thumb is to ignore all of these advanced Ruby features until my code illustrates a need for them. If I write several method calls that appear to do almost the same thing with a different name, I might be able to leverage method_missing. If I want to endow certain objects with some handy shortcuts, but leave the option of instantiating a simple, unadorned core object, I might look into mixing in some singleton methods using extend. By the end of the day, in a large or complicated application, I may end up using a large subset of the techniques discussed here. But if I started out by thinking about what dynamic features my code needed rather than what requirements it must satisfy, development would come to a confusing, grinding halt.

So here’s my advice about making use of the information in this chapter: ...