Skip to main content
The Assignment Branch Condition size warning is a complexity warning; your method is too complex. This is stated in convoluted language, but it's actually just a measurement of how many assignments, branches, and conditions you have in your method (a "branch" is a method call). To compute this metric, rubocop computes the number of assignments (call it A), the number of branches (B), and the number of conditions (C), then computes Math.sqrt(A**2 + B**2 + C**2). If the resulting value is greater than some size (18 by default), the method is said to exceed the Abc size, and rubocop complains.
Fixing this is a matter of eliminating assignments, branches, and conditions from your method, either by simplifying the code, or by doing some sort of refactoring.
Note that ruby tends to hide a lot of method calls (branches). For instance, if you have a getter defined in your class, every reference to that getter is a method call, even though it looks like a simple variable. Additionally, every indexing operation (e.g., array[1]) is a method call. These two hidden method calls are a major source of Abc complaints in ruby programs.
So, for example, if you have this class:
class Example
  attr_reader :something

  def initialize
    @something = [...]
  end

  def print_something
    if something.size == 0
      puts "something has just 1 item: #{something[0]}"
    elsif something.size == 1
      puts "something has 2 items: #{something[0]} #{something[1]}"
    else
      puts "something has #{something.size} items: #{something.join(' ')}"
    end
  end
end
rubocop will complain about the Abc size for print_something. This is primarily because we are calling the something getter 7 times, calling the [] method on something 3 times, calling something.size 3 times, and calling something.join once. That's enough to account for 14 Abc size units. (We also need to count 2 conditions, 3 calls to puts, and one call to join).
A simple fix in this case is to eliminate all of the calls to the something getter by just accessing @something directly, or by savingsomething to a local variable, and then using that variable instead of the getter.
value = something
if value.size == 0
  ...

Comments

Popular posts from this blog

Problem Solving - Refactored

I am going to outline how I approach problem solving. The relative importance and the amount of effort/time required for each is stated as a percentage beside each topic. I borrowed some idea from George Polya's How to Solve It Thoroughly Understand the Problem (30%) When encountering hard problem , you need to deeply understand the problem at hand. Take a paper and list down all known facts and data and what the question is trying to find. Sketch out the problem if applicable. Visualize the problem in your head. A lot of times, we only have to understand the problem well, then the solution will obvious. Have a Plan (20%) You need to have an outline of how you are going to tackle the problem. You need to have a logical pathway that will ultimate produce outcome (nothing to do with coding syntax yet). Without a plan, you are just randomly poking around and got lucky. No hard problem ever gets solved without a plan. Plan using pseudo-code, pen & paper or flowchart. Use wh

My Burnout Experience

I want to share with you my experience of burning out. After registering with Launch School, I am extremely excited about my programming journey. I studied for 10 to 12 hours a day, memorizing fact, trying out practice problems, understanding programming concepts. It was fun and exciting and I love seeing myself growing from nothing in programming to something more. After about 3 months, thing starts to change. I started noticing myself paying less attention to details. I find myself skimming through the course material. I skip "Further Exploration" in the practice problem. I am more interested to study just to pass the assessment rather than truly mastering the concept. It was a gradual burning out process but I continue to study for 10 to 12 hours a day through sheer grit. It felt like doing house chore or working a day job that you don't like. One particular morning I woke up, and I remember this deep feeling of dread because I can anticipate that the next 10 to 1

Sharing my Weakness

It makes sense to know about your weakness and do something about it. Here are my known weaknesses uncovered during my time in Launch School. 1. I don't like to refactor my code   - Your first draft will not be perfect. It works but it may not be efficient/readable/best practices. You final code will almost always be better than your first draft. - It is easier to separate the task between writing code that works and refactor later to make it efficient/readable/best practices. - If you refactor your code often, over time you will discover your bad habits and change it. 2. I don't like to read other people's code - There are more good programming practices in other people than in you (especially for beginners like me). - To be good , you need to know more than one pathways to solve a programming problem (and there are always more than one way). Then you can judge their merit. - Reason for dislikes    1. It is considerably harder to read code than to write one (be