Are multiple before_action calls bad code style?
<p>I'm working on an app with controller that have lots of before_actions. Most of them are connected with each other by instance variables that they set. For example:</p>

<pre><code>def first_action
  @first_variable = Something.new
end

def second_action
  if @first_variable
    @second_variable = Other.new
  end
end
</code></pre>

<p>Controller looks like this:</p>

<pre><code>class ExampleController &lt; ApplicationController
  before_action :first_action, only: [:index, :show, :create]
  before_action :second_action, only: [:index, :show, :create]
  before_action :third_action, only: [:index, :show, :create]
  before_action :fourth_action, only: [:index, :show, :create]
  before_action :fifth_action, only: [:index, :show, :create]
  before_action :sixth_action, only: [:index, :show, :create]
  before_action :seventh_action, only: [:index, :show, :create]

  def index
    # some code
  end

  def show
    # some code
  end

  def create
    # some code
  end

  private

  # all of the before_action methods
end
</code></pre>

<p>It's really hard to understand from mine point of view. Each of those method has lots of code. Additionaly there are controllers that inherits from this one and also use part or all of those actions.</p>

<p>I heard that it's better to be explicit about loaded variables in each method but this:</p>

<pre><code>class ExampleController &lt; ApplicationController

  def index
    first_action
    second_action
    third_action
    fourth_action
    fifth_action
    sixth_action
    seventh_action
    # some code
  end

  def show
    first_action
    second_action
    third_action
    fourth_action
    fifth_action
    sixth_action
    seventh_action
    # some code
  end

  def create
    first_action
    second_action
    third_action
    fourth_action
    fifth_action
    sixth_action
    seventh_action
    # some code
  end

  private

  # all of the before_action methods
end
</code></pre>

<p>doesn't look much better. Is there a way to refactor it for more readability or should I stick with current solution?</p>