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...

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 (...

Static vs Relative vs Absolute vs Fixed

Static: the default position. Everything starts from top to bottom nicely according the document flow. Relative: still within normal flow of document. But accept offset position, relative to its original document flow position Absolute: out of normal flow. It doesn't interact with elements around it anymore. The reference point will be parent element that has relative positioning, if not, reference body element. Accepts offset position Fixed: out of normal flow. The element sticks to a corner of the page even if user scrolls. Reference the windows view.