Confident Code

JOY

3.times do
  puts "Hello, Ruby world!"
end

(options[:greet_count] || 3).times do
  begin
    salutation = 
      begin
        Salutation.find(options[:salutation_id] || 1)
      rescue SalutationServerError
        nil
      end
    if salutation.nil?
      salutation = "Hello"
    end
    puts "#{salutation}, Ruby world!"
  rescue IOError => error
    logger && logger.error "I/O error in greeter"
  end
end

• Lives in fear
  

• Uncertain
  

• Prone to digressions
  

• Constantly second-guessing itself
  

• Randomly mixes input gathering, error handling, and business logic
  

• Imposes cognitive load on the reader
  

• Tangents
  

• Digressions
  

• Lack of certainty
  

• …code can have these qualities as well.
  

• A style of method construction
  

• Tells the story well
  

• Says exactly what it intends to do
  

• No provisos or digressions
  

• Has a consistent narrative structure
  

• cowsay.rb
  

• An interface to the "cowsay" program
  

• http://github.com/avdi/cowsay
  

$ echo "Mooo" | cowsay
 ______
< Mooo >
 ------
        \   ^__^
         \  (oo)\_______
            (__)\       )\/\
                ||----w |
                ||     ||

$ echo "Ontogeny Recapitulates Phylogeny"
  | cowsay -e "00"
 __________________________________
< Ontogeny Recapitulates Phylogeny >
 ----------------------------------
        \   ^__^
         \  (00)\_______
            (__)\       )\/\
                ||----w |
                ||     ||

• Debian/Ubuntu
  

  sudo apt-get install cowsay
  

• Mac OS X
  

  sudo port install cowsay
  

  Or:

  brew install cowsay
  

• Windows
  Sorry :-(

require 'lib/cowsay'
cow = Cowsay::Cow.new
puts cow.say "Baaa"
# >>  ______
# >> < Baaa >
# >>  ------
# >>         \   ^__^
# >>          \  (oo)\_______
# >>             (__)\       )\/\
# >>                 ||----w |
# >>                 ||     ||

1. Gather input
2. Perform work
3. Deliver results
4. Handle failure

In that order!

• True duck typing is a confident style
  

• Duck typing doesn't ask "are you a duck?"
  

  object.is_a?(String)
  

• Or even "can you quack?"
  

  object.respond_to?(:each)
  

• Treat the object like a duck
  (If it isn't it will complain)

• Code that switches on type isn't duck typed
  

• "The Switch Smell"
  

• Case statements on type
  

• Checking for method existence
  

• NilClass is a type too
  

• null checks are the most common kind of typecasing
  

• Coerce
  

• Reject
  

• Ignore
  

• Use #to_s, #to_i, Array() liberally
  

• Ruby standard libs do this
  

  require 'pathname'
  path = Pathname("/home/avdi/.emacs")
  open(path) # => #<File:/home/avdi/.emacs>
  

• The "arrayification operator"
  

  Array([1,2,3])      # => [1, 2, 3]
  Array("foo")        # => ["foo"]
  Array(nil)          # => []
  
  # Gotcha:
  Array("foo\nbar")   # => ["foo\n", "bar"]
  

• Before
  

  messages = case message
             when Array then message
             when nil then []
             else [message]
             end
  

• After
  

  messages = Array(message)
  

• When there is no consistent interface
  

• Decorator Pattern
  

• Cleanly adapt objects to a common interface
  

destination = case options[:out]
              when nil  then "return value"
              when File then options[:out].path
              else options[:out].inspect # String?
              end
@logger.info "Wrote to #{destination}"

def cowsink(out)
  case out
  when File then out # nothing special
  when nil then NullSink.new
  else GenericSink.new(out)
  end
end

require 'delegate'
class NullSink
  def path; "return value"; end
  def <<(*); end
end

class GenericSink < SimpleDelegator
  def path; "object: #{inspect}"; end
  # All other methods pass through
end

destination = cowsink(options[:out]).path
# ...
@logger.info "Wrote to #{destination}"

• Not a duck. Not even a bird.
  

• Will eventually cause an error
  

• …but not before doing some damage
  

• May not be clear where the error originated
  

• Confident Code asserts itself
  

• State your needs up-front
  

• At the edges of your interface
  

• Preconditions: Part of Design by Contract
  

• No DbC framework needed
  

• Assertions don't have to be spelled "assert()"
  

def say(message, options={})
  if options[:cowfile] && options[:cowfile] =~ /^\s*$/
    raise ArgumentError, "Cowfile cannot be blank"
  end
  # ...
  if options[:cowfile]
    command << " -f #{options[:cowfile]}"
  end
  # ...
end

def assert(value, message="Assertion failed")
  raise Exception, message, caller unless value
end

# ...

options[:cowfile] and
  assert(options[:cowfile].to_s !~ /^\s*$/)

• Short-circuit on nil message
  

  def say(message, options={})
    return "" if message.nil?
    # ...
  end
  

• Avoids special cases later in method
  

• Some arguments just have to be special
  

• An object to represent the special case
  

• Avoids if, &&, try()
  

# status is either nil or a Process::Status object
unless [0,172].include?(status && status.exitstatus)
  raise ArgumentError,
    "Command exited with status "\
    "#{status.try(:exitstatus)}"
end

status ||= OpenStruct.new(:exitstatus => 0)
unless [0,172].include?(status.exitstatus)
  raise ArgumentError,
    "Command exited with status "\
    "#{status.exitstatus}"
end

• The special case value is usually nil
  

• The special case for nil is usually "do nothing"
  

• A special case of Special Case
  

• Responds to any message with nil (or itself)
  

class NullObject
  def method_missing(*args, &block)
    self
  end

  def nil?; true; end
end

def Maybe(value)
  value.nil? ? NullObject.new : value
end

• Returns self from every call
  

• Nullifies chains of calls
  

  foo = nil
  Maybe(foo).bar.baz + buz 
  # => #<NullObject:0xb7814bd0>
  

• if statement
  

  if options[:out]
    options[:out] << output
  end
  

• Null Object
  

  Maybe(options[:out]) << output
  

• nil is overused in Ruby code
  

• It means too many things
  
  • Error
    
  • Missing Data
    
  • Flag for "default behavior"
    
  • Uninitialized variable
    
  • Default return value for if, unless, empty methods.
    

• Nil checks are the most common form of timid code
  

More precise handling of method options.

collection.fetch(key) { fallback_action }

• Default error
  

  opt = {}.fetch(:required_opt)
  # ~> -:1:in `fetch': key not found (IndexError)
  

• Custom error
  

  opt = {}.fetch(:required_opt) do
    raise ArgumentError, "Missing option!"
  end
  # ~> -:2: Missing option! (ArgumentError)
  

• Using ||
  

  width = options[:width] || 40
  command << " -W #{width}"
  

• Using #fetch
  

  width = options.fetch(:width) {40}
  command << " -W #{width}"
  

• A more explicit default
  

• One less conditional
  

• Where did that nil come from?
  

  @logger = options[:logger]
  # ...
  @logger.info "Something happened" # =>
  # ~> -:3: undefined method `info' for
  #    nil:NilClass (NoMethodError)
  

@logger = options.fetch(:logger){:no_logger_set}
# ...
@logger.info "Something happened" # =>
# ~> -:3: undefined method `info' for
#    :no_logger_set:Symbol (NoMethodError)

def initialize(logger=NullObject.new)
  @logger = logger
end

• Keep the focus on the work
  

• Avoid digressions for error/input handling
  

def slug(text)
  Maybe(text).downcase.strip.tr_s('^a-z0-9', '-')
end

slug("Confident Code") # => "confident-code"
slug(nil)              # => #<NullObject:0xb780863c>

• As exemplified by jQuery
  

  // From "jQuery in Action"
  $("div.notLongForThisWorld").fadeOut().
      addClass("removed");
  

• Single object operations are implicitly one-or-error
  

• Iteration is implicitly 0-or-more
  

• Chains of enumerable operations are self-nullifying
  

• Cowsay#say uses an iterative style…
  

def say(message, options={})
  # ...
  messages = Array(message)
  message.map { |message|
    # ...
  }
  # ...
end

cow.say([]) # => ""

• Help your callers be confident
  

• Return a Special Case or Null Object
  

• Or raise an error
  

• Put the happy path first
  

• Put error-handling at the end
  

• Or in other methods.
  

@io_class.popen(command, "w+") # ...
# ...
status = $? || OpenStruct.new(:exitstatus => 0)
unless [0,172].include?(status.exitstatus)
  raise ArgumentError,
        "Command exited with status "\
        "#{status.exitstatus}"
end

Method whose job is to raise or do nothing

def check_child_exit_status
  result = yield
  status = $? || OpenStruct.new(:exitstatus => 0)
  unless [0,172].include?(status.exitstatus)
    raise ArgumentError,
          "Command exited with status "\
          "#{status.exitstatus}"
  end
  result
end

check_child_exit_status {
  @io_class.popen(command, "w+") # ...
}

@io_class.popen(command, "w+") do |process|
  results << begin
               process.write(message)
               process.close_write
               result = process.read
             rescue Errno::EPIPE
               message
             end
end

def checked_popen(command, mode, fail_action)
  check_child_exit_status do
    @io_class.popen(command, "w+") do |process|
      yield(process)
    end
  end
rescue Errno::EPIPE
  fail_action.call
end

checked_popen(command, "w+", lambda{message}) do 
  |process|
  # ...
end

• It has a coherent narrative structure
  

• It has lower complexity
  

• It's not necessarily shorter
  

• Fewer paths == fewer bugs
  

• Easier to debug
  

• Self-documenting
  "Write code for people first, the computer second"

JOY

• Question!
• Contact!
  • avdi.org / @avdi
• Rate!
  • http://spkr8.com/t/8840