Confident Code

• A style of Code Construction
  

The opposite of timid code. Duh.

First, a story…

• Tangents
  

• Digressions
  

• Lack of certainty
  

• …code can have these qualities as well.
  

• 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
  

• 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 `cauldron stir cowsay`
  # or whatever you Mac kids are using now
  

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

• Contrived for the sake of example
  

• Drawn from real production code crap I've written
  

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

In that order!

• To be confident, we must be sure of our inputs
  

• 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)

• Some objects need a little help discovering their duck nature
  

• Typecasing: Code that switches on the type of an object
  

• The opposite of duck typing
  

• A reaction to input variance
  

• nil checks are the most common typecase
  

• It doesn't have to be this way.
  

• 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"]
  

Object.new.to_a
# => [#<Object:0xb78a665c>]
# !> default `to_a' will be obsolete

• 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
  

• Wraps an object and adds a little extra
  

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}"

require 'delegate'
# ...
class WithPath < SimpleDelegator
  def path
    case __getobj__
    when File then super
    when nil then "return value"
    else inspect
    end
  end
end

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

• Dynamically #extend objects
  

  obj.extend(MyMethods)
  

• Dynamically add methods
  

  def obj.foo
     # ...
  end
  

• 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
  

• Preconditions: state your demands up-front
  

• 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*$/)

• Exception skips default rescue
  

  begin
    raise Exception, "Can't catch me!"
  rescue # rescues StandardError
    puts "Rescued!"
  end
  # ~> -:2: Can't catch me! (Exception)
  

• Third argument to raise sets stack trace
  

  raise Exception, message, caller
  

• Assertions are documentation
  

• FailFast
  http://github.com/avdi/failfast

• Guard Clause
  

• Special Case
  

• Null Object
  

• 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 OO way to deal with special cases
  

• An object to represent the special case
  

• Avoids if, &&, try()
  

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

# $? is either nil or a Process::Status object
def check_child_exit_status!(status=$?)
  status ||= OpenStruct.new(:exitstatus => 0)
  unless [0,172].include?(status.exitstatus)
    raise ArgumentError,
          "Command exited with status"\
          "#{status.exitstatus}"
  end
end

"A Null Object is an object with defined neutral ("null") behavior." (Wikipedia)

• 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)
  

• Should be in the standard library
  

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        # => nil
  

• 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
  

post_id = params[:post_id]
post    = if params[:blog]
            blog = get_blog(params[:blog])
            blog.posts.find(:first, post_id)
          end
post.date     # =>
# ~> -:4: undefined method `date' 
#    for nil:NilClass (NoMethodError)

Kill it with fire.

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

class NullObject
  def initialize
    @origin = caller.first
  end
  # ...
end

nil

foo = NullObject.new
bar = foo.bar
baz = bar.baz
# Now let's see where that nil originated
baz

#<NullObject:0x7fcace309800 @origin="(irb):68:in `new'">

• Keep the focus on the work
  

• Avoid digressions for error/input handling
  

• Program Intently and Expressively
  

• Say what you mean!
  

• Conditionals give you more to think about
  

• Reserve conditionals for business logic
  

• Minimize conditionals for error, input handling
  

• Isolate error/input handling from program flow
  

• Business logic
  

  if post.published?
    # ...
  end
  

• Business logic?
  

  if post
    # ...
  end
  

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.
  

def foo
  # ...
rescue => error # --- business/failure divider ---
  # ...
end

• Neatly divides method into "work" and "error handling"
  

• Bouncer Method
  

• Checked Method
  

• 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
  

# Before:
@io_class.popen(command, "w+") # ...
# ...
if $? && ![0,172].include?($?.exitstatus)
  raise ArgumentError,
        "Command exited with status #{$?.exitstatus.to_s}"
end

# After:
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, mode) 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"

• A style, not a set of techniques
  

• Consistent narrative structure
  

• Handle input, perform work, deliver output, handle failure.
  

• PIE: Program Intently and Expressively
  

• Avoid digressions
  

• State your demands up front
  

• Terminate nils with extreme prejudice
  

• Isolate error handling from the main flow
  

• Book!
  • ExceptionalRuby.com
  • 25% off: RAILSCONF11
• Rate!
  • http://spkr8.com/t/7473
• Contact!
  • avdi.org / @avdi