The Ruby Craftsman
Refactoring with Hash Defaults
I’m going to give you a primer on how to set default values when accessing non-existing keys. Then I’ll give you some advice on how this could improve your code.
Set default in the initializer
Set default on an instance
Be aware if this is exposed as public API it may not do what end users are expecting, so either keep the hash with defaults set isolated or be very sure you think about the issues it could cause.
Side note don’t depend on using
nil as an indicator of a key not being present because if the value it’s self is
nil then your code has miss understood the meaning.
If you need to know if a key is realy present use
That feels better.
What about setting a proc
You can set the default to a proc, but that’s not what you would want a proc for.
The first option looks the most natural to Ruby.
Why do you want to do this?
You can read this stuff for yourself in the Ruby documentation, but what I want to bring you is knowledge in how to apply these tools in your own code.
Refactor case statement to data structure.
Let’s say we’ve got a method that returns the sales tax for a certain state. We know there is no sales tax in Oregon and that sales tax is higher in California and were making the assumption about the rest of the US.
Moving things away from conditionals can make adding new branches easier. In some sense, this is removing branch logic from your code and you can think of the hash as data that your code uses as an input. If you’re following a test-driven approach every line in your code should have test coverage, but you won’t always test every possible out come from a data source.
So, let’s put into practice what we just learned and see how it can help us refactor.
Nice, we’ve setup a frozen constant that works the same as the case statement in the previous code.
An alternative to this is to keep the else condition, or better use
#fetch with a default, but still move the specific cases into a data structure.
This hash could get large and when it does you might want to move it to a YAML file. The goal here is to reducing churn of the Ruby file and separating data from logic. If you can make Ruby files unchanging it makes them more stable. When the data needs changing it can be changed independently of the code. If the YAML file was changing all the time I might consider moving that to a database leading to no churn in the repository.
The best solution depends on the use case. I give you the tools it’s your responsibility to use them wisely.
Post edited 2017-11-14 to address Reddit comments