Laravel:単語の接続方法(〜Case)と命名規制とベストプラクティス

Laravel:単語の接続方法(〜Case)と命名規制とベストプラクティス

Laravel:単語の接続方法(〜Case)と命名規制とベストプラクティス

「ルートはケバブケースの複数形で」と言われケバブケースが出てこなかったので一通りまとめていきます。
ついでに【ベストプラクティス】についても触れていきます。

単語の接続方法【〜Case】

一人で開発していた時は気にした事も無かったのですが、チーム開発な現場に入ると絶対に言われるのがコレです。
「そこはキャメルケースで書いてください」とかね。

まずは【〜Case】をまとめてみます。

呼称 具体例 説明
キャメルケース camelCase
  • personalAccessTokenのように表記
  • 先頭の要素語( personal )は小文字で書き始める
  • 先頭以外の要素語(access token )の最初を大文字で書き始める
  • 別名:ローワーキャメルケース
  • Laravelだと関数に利用することが多い
パスカルケース PascalCase
  • PersonalAccessToken のように表記
  • 要素語(personal access token)の最初を大文字で書き始める
  • 別名:アッパーキャメルケース
  • Laravelだとモデルやコントローラーなどのファイル名に利用されている
スネークケース snake_case
  • personal_access_token のように表記
  • アンダースコア で要素語(personal access token)を連結する
  • MySQLのテーブル名に利用される※テーブル名は複数形でparsonal_access_tokens になる
コンタクトケース CONTACT_CASE
  • PERSONAL_ACCESS_TOKEN のように表記
  • 要素語(personal access token)の全てを大文字で書く
  • アンダースコア で要素語(personal access token)を連結する
  • .envなどの設定ファイルの項目で利用される
ケバブケース kebab-case
  • personal-access-token のように表記
  • ハイフン で要素語(personal access token)を連結する
  • Laravelだとbladeファイルやルート(URL)に利用される

「ケバブ=串焼き」うん、確かにケバブケースは串焼きっぽいけど「誰が名付けたんだろう」と気になってしまうネーミングセンスですね

命名規制とベストプラクティス

Laravelにはフレームワークとしての命名規制があります。(命名規制に触れた過去記事
そして命名規制の外に「こうした方が可読性が増すよね」という有識者の考えた命名ルールがあります。
このルールの事を【Best Practice(ベストプラクティス)】と言います。

Laravelのベストプラクティス

対象 規則 Good Bad
コントローラ 単数形 ArticleController ArticlesController
ルート 複数形 articles/1 article/1
名前付きルート スネークケースとドット表記 users.show_active users.show-active, show-active-users
モデル 単数形 User Users
hasOne または belongsTo 関係 単数形 articleComment articleComments, article_comment
その他すべての関係 複数形 articleComments articleComment, article_comments
テーブル 複数形 article_comments article_comment, articleComments
Pivotテーブル 単数形 モデル名のアルファベット順 article_user user_article, articles_users
テーブルカラム スネークケース モデル名は含めない meta_title MetaTitle; article_meta_title
モデルプロパティ スネークケース $model->created_at $model->createdAt
外部キー 単数形 モデル名の最後に_idをつける article_id ArticleId, id_article, articles_id
主キー id custom_id
マイグレーション 2017_01_01_000000_create_articles_table 2017_01_01_000000_articles
メソッド キャメルケース getAll get_all
リソースコントローラのメソッド 一覧 store saveArticle
テストクラスのメソッド キャメルケース testGuestCannotSeeArticle test_guest_cannot_see_article
変数 キャメルケース $articlesWithAuthor $articles_with_author
コレクション 説明的、 複数形 $activeUsers = User::active()->get() $active, $data
オブジェクト 説明的, 単数形 $activeUser = User::active()->first() $users, $obj
設定ファイルと言語ファイルのインデックス スネークケース articles_enabled ArticlesEnabled; articles-enabled
ビュー ケバブケース show-filtered.blade.php showFiltered.blade.php, show_filtered.blade.php
コンフィグ スネークケース google_calendar.php googleCalendar.php, google-calendar.php
契約 (インターフェイス) 形容詞または名詞 AuthenticationInterface Authenticatable, IAuthentication
Trait 形容詞 Notifiable NotificationTrait

こうやって抽出してみると「やば、直さないと」と思う所がチラホラと…。
特にビューはキャメルケースで書いていました。まぁ、それで指導されてこの記事に至っているのだけど。

ベストプラクティスに従うメリット

可読性の向上が一義です。
その他にはミスの防止などでしょうか。

▼アッパーキャメルケース

▼ローワーキャメルケース

たったコレだけの違いですが、見え方が違うとわかります。
ベストプラクティスでは、こう言った視覚効果まで考えてルール化しているので従った方が可読性が増すんです。
また、チームで開発していると方針としてのルールがないと「なんでもあり」になってしまうので【コードを統制する】と言う意味でもベストプラクティス(またはそれに類するチーム内のコード規約)は重要ですよね。

まとめ

今回紹介しているベストプラクティス以外にもリーダブルコードという超有名な書籍があります。
この書籍については案件探しの面談の中で「読んだことある?」と聞かれたことがありますので、探している方一度目を通す事をお勧めします。ルールに従って、みんなが見やすいコードを書いていきましょう。