LoginSignup
22
26

More than 5 years have passed since last update.

Ruby on Railsの命名規則:好きに命名するのか、Railsが予想して命名したのか分からない話

Last updated at Posted at 2018-11-18

いろいろやってくれて助かるんですけど

Ruby on Railsでは開発者がちょっと指定するだけでいろいろ自動的に処理してくれる機能が多くあり、高い開発効率に繋がっています。

Ruby on Railsの命名の種類には①〜③だと考えていますが、なぜか入門者向けのドキュメントにはそれが明言されておらず、読み手が予想するしかないものが多いのです。説明があったとしても結構後のほうにようやく出てくることが多いです。

経験者からしてみれば「いや普通に考えればこうだろ」という内容かと思うのですが、プログラミング未経験者にとってはその”普通に考える”までたどりつくのがとても大変なのです。
同じような人(非常に少ないかもしれませんが)がいたら少しくらい役に立てるかと思うので記録してきます。

①開発者が任意に付ける値

Ruby, Ruby on Railsの予約語やすでに使っている値以外であれば開発者が好きに付けていい値。
その前提で、運用性を考えてコントローラ名などと関連させて命名することが多い(だからドキュメント読むときに②とごっちゃになる)。

変数名

# nは開発者が好きに付けていい値
n = "hello, world"

コントローラ名

# 複数形という規則を守れば開発者が好きに命名してよい
  $ rails generate controller ManyUsers

# スネークケース(many_users)で命名しても作成されるファイルは同じとなる

モデル名

# 単数形という規則を守れば開発者が好きに命名して良い
  $ rails generate model RailsModel

# スネークケース(rails_model)で命名しても作成されるファイルは同じとなる

②開発者の任意でつけられたクラス・メソッド名などからRailsが予想して予約されている値

開発者が一個一個命名しなくてもRailsが勝手に予想してくれるパターン。

# ルーティング
# 例えば、/config/routes.rbに
    resources :boxes
# と記載してルーティング情報を表示すると、
# ルーティングされるPrefixは下記のようにRailsが単数形と複数形を予想して作成する
# "box"みたいな単数形と複数形が他とちょっと違う命名でもちゃんとやってくれた
#     ——————————————————————————————————————————————————————————————
        Prefix Verb   URI Pattern                    Controller#Action
         boxes GET    /boxes(.:format)               boxes#index
               POST   /boxes(.:format)               boxes#create
       new_box GET    /boxes/new(.:format)           boxes#new
      edit_box GET    /boxes/:id/edit(.:format)      boxes#edit
           box GET    /boxes/:id(.:format)           boxes#show
               PATCH  /boxes/:id(.:format)           boxes#update
               PUT    /boxes/:id(.:format)           boxes#update
               DELETE /boxes/:id(.:format)           boxes#destroy
#     ——————————————————————————————————————————————————————————————

テーブルの関連付け

class Micropost < ApplicationRecord
  belongs_to :user
end
class User < ApplicationRecord
  has_many :microposts
end
# 上記を記載すると、Usersテーブル対Micropostテーブルに1対Nの関連付けがなされる。 
# ここで記載した文字列が、関連付けたテーブルを参照するためのモデルのメソッドとなる。

# 加えて、has_many :micropostsを記述することで下記メソッドが自動的に追加される
  <Userモデルのオブジェクト>.micropost_ids
  # user.micropostコレクションに対応するidを配列で得られる。

マイグレーション時のカラム名、テーブル名の指定

$ rails generate migration add_<カラム名>_to_<テーブル名>

この書式で記載すると、オプションで記載する"カラム名"を"テーブル名"テーブルに追加する行が記載される。
例えば下記の感じで

$ rails generate migration add_password_digest_to_users password_digest:string

と記載すると、作成されるマイグレーションファイルに追加先のテーブル名が記載された"add ~"の行が追加される

add_password_digest_to_users.rb
class AddPasswordDigestToUsers < ActiveRecord::Migration[5.1]
  def change
    add_column :users, :password_digest, :string
  end
end

マイグレーションファイルでのカラム追加

class CreateMicroposts < ActiveRecord::Migration[5.1]
  def change
    create_table :microposts do |t|
      t.references :user, foreign_key: true   #<-ここ
    end
  end
end
# 上記を記載すると、Micropostsテーブルにカラム"user_id"が追加され、外部キー制約を付加する。

URL指定の引数

#テストコマンド
redirect_to @user

#getコマンド
get @user

Railsが@<モデル名>と解釈し、
-><モデル名>_url(@<モデル名>)と同じ動きをする
よって、上記のコードは下記と同意

#テストコマンド
redirect_to user_url(@user)

#getコマンド
get user_url(@user)

コールバック

before_〜〜の〜〜の部分でコールバックするトリガーを推測する

class HogehogesController
  #アクションhoge1, hoge2, hoge3を実行する前にアクションbefore_hogeを実行する
  before_action :before_hoge, only: [:hoge1, :hoge2, :hoge3]

・・・

end

コールバック

class HogehogeModel
  #.saveを実行する前にアクションbefore_hogeを実行する
  before_save :before_hoge

  #.createを実行する前にアクションbefore_hogeを実行する
  before_create :before_hoge

・・・

end

③デフォルトでRuby, Railsが予約している、開発者が使用できない値

RubyやRuby on Railsではじめから使用されている名前

Ruby予約語


if
class
return

22
26
2

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
22
26