title: Refactoring Long and Too Many Branches Methods for Rubocop
body: <p><em>I provided an update below to some findings...</em></p>
  
  <p>Here's a method I have in my current code:</p>
  
  <pre><code>def query(data_set, conditions)
    query_data_set = data_set.dup
    search_conditions = parse_conditions(conditions)
  
    search_conditions.each do |condition|
      if condition.class == Array
        condition.each do |term|
          if term.class == Symbol
            query_data_set = entity.send term, query_data_set
          else
            query_data_set = search_data_text(query_data_set, term)
          end
        end
      end
  
      if condition.class == Hash
        condition.each do |key, value|
          query_data_set = method("query_#{key}").call(data_set, value)
        end
      end
    end
  
    query_data_set
  end
  </code></pre>
  
  <p>Rubocop hates this for three reasons:</p>
  
  <pre><code>C: Assignment Branch Condition size for query is too high. [17.03/15]
    def query(data_set, conditions)
  
  C: Method has too many lines. [19/7]
    def query(data_set, conditions)
  
  C: Use next to skip iteration.
    search_conditions.each do |condition|
  </code></pre>
  
  <p>I don't EVER want to skip an iteration so I'm not sure why I would use <code>next</code> at all. There is never a case where skipping an iteration would make sense for this bit of code.</p>
  
  <p>So going to the other complaints, you'll see at that the top of this method I have already broken out one action (the call to <code>parse_conditions</code>). There's also a call to <code>search_data_text</code>. My only point here being I have tried to be modular where it seemed to make sense.</p>
  
  <p>Even if I move that large <code>search_conditions.each</code> block to a separate method, Rubocop is going to complain that my new method is too long as well. Which I suppose means adding yet a <em>third</em> method that my <em>second</em> method will call? That seems odd to me. Or perhaps it means I have to not branch so much, I guess. But why is the branching bad? Even if I switch to some other structure (like a case...when), I'm still branching. And I do need to test those conditions because handling is different for a nested array, an array with a symbol, or a hash.</p>
  
  <p>I'm trying to build up my intuition for being able to look at problems like this and figure out an effective and efficient solution .... but it seems what I end up doing is being terribly inefficient and ineffective <em>with my time</em>. That tradeoff is worrying me given that I can't see why my code is bad.</p>
  
  <p>Anyone mind taking a stab at this and helping me see how I can get the above method into a state that maintains some semblance of readability but that fits into the style guidelines that Rubyists prefer?</p>
  
  <p><strong>----------------------</strong>
  <strong>UPDATE</strong>
  <strong>----------------------</strong></p>
  
  <p>About the best I could come up with is this:</p>
  
  <pre><code>def query(data_set, conditions)
    query_data_set = data_set.dup
    parse_conditions(conditions).each do |condition|
      query_data_set = check_conditions(condition, query_data_set)
    end
    query_data_set
  end
  
  def check_conditions(condition, data)
    if condition.class == Array
      condition.each do |term|
        data = entity.send term, data if term.class == Symbol
        data = search_data_text(data, term) unless term.class == Symbol
      end
    end
  
    if condition.class == Hash
      condition.each do |key, value|
        data = method("query_#{key}").call(data, value)
      end
    end
    data
  end
  </code></pre>
  
  <p>That <code>check_conditions</code> method is still too long for Rubocop and still has too high of a branch condition size.</p>
  
  <p>As far as I can see, and nowhere I've checked has been able to show me different, the only thing that can be done would be to perhaps make methods out of the checks for array and hash. In other words, each <code>if</code> condition in <code>check_conditions</code> would get its own method. But that seems needlessly silly to me. I'm basically breaking up logic, passing variables to different methods, just so that I can keep my method count below some arbitrary value.</p>
  
  <p>This feels way wrong to me as a way to do design. But I don't see a way to change my logic such that it still accomplishes what it needs to but does so under seven lines per method.</p>