Understanding Why Each Ruby on Rails Action Has the Same Variable Name

You can use any variable name.

When developing a team, it is considered a good practice to name a variable that explains the contents of the message class because you may wonder if it is meaningful to name another variable in the message class.

#Bad example: A cat even though it's a dog class?
@cat=Dog.find (params[:id])

Also, I think you can use the short variable name like the one you gave me this time because it is rarely misread among small functions. (Rails is used in View, so it takes more than it looks.)

#Message instance variable, so the initial m
def show
  @m=Message.find(...)
end

Try writing why you use @message.

Rails can be written with a small amount of code to follow the rules.If you follow the rules, you can think less when you write code.In other words, controllers and views that handle the Message model are less likely to think of variable names such as @message or @messages.When you write a program, you're often at a loss as to what to name a variable, so a pattern saves you time, and you don't have to doubt it when you read it yourself or when others read it.

I wrote it as I thought, but I hope it will be helpful

As a supplement, the index action that deals with the collection typically has plural forms of @messages

def index
  @messages=Message.all
end

One of the reasons why each action has variable names is that the view template is shared between each action.

For example, in addition to show, the template for displaying messages may be used after create or edit succeeds, and the message editing form is used by create, edit.
If the variables in the messages to be displayed are different, you will be in trouble.
Therefore, if this happens, you may want to keep the variables consistent between actions.

The reason for using @message is that it is easier to understand and more efficient.
As a result, programming becomes very easy.

The name @message makes it easier to understand what this variable is dealing with, and using the same @message for different actions makes it easier to share the processing.

I think it would be easier to understand if you could generate this message using Scaffold.

$>rails gscaffold message body:text

I think the MessagesController will look like this (it may vary slightly depending on the Rals version).

class MessagesController<ApplicationController
  before_action: set_message, only: [:show,:edit,:update,:destroy]

  # GET/messages
  def index
    @messages=Message.all
  end

  # GET/messages/1
  def show
  end

  # GET/messages/new
  def new
    @message=Message.new
  end

  # GET/messages/1/edit
  default
  end

  # POST/messages
  def create
    @message=Message.new(message_params)

    [email protected]
      redirect_to @message,notice: 'Message was successfully created.'
    else
      render:new
    end
  end

  # PATCH/PUT/messages/1
  default update
    [email protected](message_params)
      redirect_to @message,notice: 'Message was successfully updated.'
    else
      render —edit
    end
  end

  # DELETE/messages/1
  def destroy
    @message.destroy
    redirect_to messages_url, notice: 'Message was successfully destroyed.'
  end

  private
    # Use callbacks to share common setup or constraints between actions.
    default_message
      @message=Message.find (params[:id])
    end

    # Only allow a trusted parameter "white list" through.
    def message_params
      param.require(:message).permit(:body)
    end
end

What you can see from this controller is that the same @message can be used to commonize the process of retrieving messages based on identity in the form of set_message.
Because each action is independent, the value of @message is not shared between the actions, but it is a great advantage to be able to share the action.

This commonality occurs not only in the controller but also in the view.
The new and edit actions show forms for creating and updating messages, respectively, but they can be shared.
This is the file _form.html.erb.
Naturally, this form is intended to register and update the contents of @message passed from the action, and is called from new.html.erb or edit.html.erb.
In this case, it is also more convenient to use the common component _form.html.erb than to use different variable names.

Scaffold just automatically generates basic processing, but as you expand this messaging capability, you'll see more and more common parts and more advantages in using the same variable name.

That's why you don't have to use different variables for each action.

To sum up,

• Variable names should be named as soon as you see what they are dealing with (not just Ruby, but programming in general).
• If you use the same variable name, you can use the same variable even if you create a common part (this is also said by programming in general)
• Rails controllers are relatively easy to get through, so it's easier to understand the meaning of Rails by following the Rails' style.Regardless of language, programs should be easy to understand, so if you dare to use different structures, they will become difficult to understand and unkind.

That's why.I'm just saying almost the same thing as the two of you who have already answered, but will it be conveyed well?

Rails has a new controller for each request.

Note: https://github.com/rails/rails/blob/130c128eae233bf71231c73b9c3c3b3f3ede918b/actionpack/lib/action_controller/metal.rb#L254

Therefore, the controller instance that is called every time is different, so it doesn't matter if the instance variable exceeds the method (request).

As a result, instance variables should be unique and human-friendly on a per-request basis, and the variable names used in CRUD will inevitably be similar.