book

Effective Ruby: 48 Specific Ways to Write Better Ruby

by Peter Jones

September 2014

Intermediate to advanced

240 pages

7h 2m

English

Addison-Wesley Professional

Read now

Unlock full access

Ruby Implementations and VersionsA Note about StyleWhere to Get the Source Code
Item 1: Understand What Ruby Considers to Be TrueItem 2: Treat All Objects as If They Could Be nilItem 3: Avoid Ruby’s Cryptic PerlismsItem 4: Be Aware That Constants Are MutableItem 5: Pay Attention to Run-Time Warnings

Item 6: Know How Ruby Builds Inheritance HierarchiesItem 7: Be Aware of the Different Behaviors of superItem 8: Invoke super When Initializing SubclassesItem 9: Be Alert for Ruby’s Most Vexing ParseItem 10: Prefer Struct to Hash for Structured DataItem 11: Create Namespaces by Nesting Code in ModulesItem 12: Understand the Different Flavors of EqualityItem 13: Implement Comparison via “<=>” and the Comparable ModuleItem 14: Share Private State through Protected MethodsItem 15: Prefer Class Instance Variables to Class Variables
Item 16: Duplicate Collections Passed as Arguments before Mutating ThemItem 17: Use the Array Method to Convert nil and Scalar Objects into ArraysItem 18: Consider Set for Efficient Element Inclusion CheckingItem 19: Know How to Fold Collections with reduceItem 20: Consider Using a Default Hash ValueItem 21: Prefer Delegation to Inheriting from Collection Classes
Item 22: Prefer Custom Exceptions to Raising StringsItem 23: Rescue the Most Specific Exception PossibleItem 24: Manage Resources with Blocks and ensureItem 25: Exit ensure Clauses by Flowing Off the EndItem 26: Bound retry Attempts, Vary Their Frequency, and Keep an Audit TrailItem 27: Prefer throw to raise for Jumping Out of Scope
Item 28: Familiarize Yourself with Module and Class HooksItem 29: Invoke super from within Class HooksItem 30: Prefer define_method to method_missingItem 31: Know the Difference between the Variants of evalItem 32: Consider Alternatives to Monkey PatchingItem 33: Invoke Modified Methods with Alias ChainingItem 34: Consider Supporting Differences in Proc ArityItem 35: Think Carefully Before Using Module Prepending
Item 36: Familiarize Yourself with MiniTest Unit TestingItem 37: Familiarize Yourself with MiniTest Spec TestingItem 38: Simulate Determinism with Mock ObjectsItem 39: Strive for Effectively Tested Code
Item 40: Know How to Work with Ruby DocumentationItem 41: Be Aware of IRB’s Advanced FeaturesItem 42: Manage Gem Dependencies with BundlerItem 43: Specify an Upper Bound for Gem Dependencies
Item 44: Familiarize Yourself with Ruby’s Garbage CollectorItem 45: Create Resource Safety Nets with FinalizersItem 46: Be Aware of Ruby Profiling ToolsItem 47: Avoid Object Literals in LoopsItem 48: Consider Memoizing Expensive Computations

Content preview from Effective Ruby: 48 Specific Ways to Write Better Ruby

4. Exceptions

Sometimes an error condition is bad enough that it seems flat-out rude to return nil from a method. When things get this mucked up it’s best to unwind the stack and provide details describing the failure.

Purists (of which I’m a card-carrying member) believe that exceptions should rarely be used...mostly to give a meaningful apology to the user (followed promptly by crashing the program and discarding all her hard work).

Ruby programmers tend to be more liberal with exceptions. A number of routine error conditions are encoded into standard exception classes and used to report specific failures. Fortunately, the most common exception classes contain enough information that it’s practical to rescue the exception and recover from the ...