Laravel:単語の接続方法(〜Case)と命名規制とベストプラクティス
- 2021.10.12
- php備忘録
- best practice, Laravel, PHP, コーディングルール, スクリプト備忘録, ひとりごと, リーダブルコード, 可読性, 命名規制, 命名規約
Laravel:単語の接続方法(〜Case)と命名規制とベストプラクティス
「ルートはケバブケースの複数形で」と言われケバブケースが出てこなかったので一通りまとめていきます。
ついでに【ベストプラクティス】についても触れていきます。
単語の接続方法【〜Case】
一人で開発していた時は気にした事も無かったのですが、チーム開発な現場に入ると絶対に言われるのがコレです。
「そこはキャメルケースで書いてください」とかね。
まずは【〜Case】をまとめてみます。
呼称 | 具体例 | 説明 |
---|---|---|
キャメルケース | camelCase |
|
パスカルケース | PascalCase |
|
スネークケース | snake_case |
|
コンタクトケース | CONTACT_CASE |
|
ケバブケース | kebab-case |
|
「ケバブ=串焼き」うん、確かにケバブケースは串焼きっぽいけど「誰が名付けたんだろう」と気になってしまうネーミングセンスですね
命名規制とベストプラクティス
Laravelにはフレームワークとしての命名規制があります。(命名規制に触れた過去記事)
そして命名規制の外に「こうした方が可読性が増すよね」という有識者の考えた命名ルールがあります。
このルールの事を【Best Practice(ベストプラクティス)】と言います。
Laravelのベストプラクティス
対象 | 規則 | Good | Bad |
---|---|---|---|
コントローラ | 単数形 | ArticleController | |
ルート | 複数形 | articles/1 | |
名前付きルート | スネークケースとドット表記 | users.show_active | |
モデル | 単数形 | User | |
hasOne または belongsTo 関係 | 単数形 | articleComment | |
その他すべての関係 | 複数形 | articleComments | |
テーブル | 複数形 | article_comments | |
Pivotテーブル | 単数形 モデル名のアルファベット順 | article_user | |
テーブルカラム | スネークケース モデル名は含めない | meta_title | |
モデルプロパティ | スネークケース | $model->created_at | |
外部キー | 単数形 モデル名の最後に_idをつける | article_id | |
主キー | – | id | |
マイグレーション | – | 2017_01_01_000000_create_articles_table | |
メソッド | キャメルケース | getAll | |
リソースコントローラのメソッド | 一覧 | store | |
テストクラスのメソッド | キャメルケース | testGuestCannotSeeArticle | |
変数 | キャメルケース | $articlesWithAuthor | |
コレクション | 説明的、 複数形 | $activeUsers = User::active()->get() | |
オブジェクト | 説明的, 単数形 | $activeUser = User::active()->first() | |
設定ファイルと言語ファイルのインデックス | スネークケース | articles_enabled | |
ビュー | ケバブケース | show-filtered.blade.php | |
コンフィグ | スネークケース | google_calendar.php | |
契約 (インターフェイス) | 形容詞または名詞 | AuthenticationInterface | |
Trait | 形容詞 | Notifiable |
こうやって抽出してみると「やば、直さないと」と思う所がチラホラと…。
特にビューはキャメルケースで書いていました。まぁ、それで指導されてこの記事に至っているのだけど。
ベストプラクティスに従うメリット
可読性の向上が一義です。
その他にはミスの防止などでしょうか。
▼アッパーキャメルケース
1 |
$ActiveUser = ActiveUser::find(¥Auth::User()->id); |
▼ローワーキャメルケース
1 |
$activeUser = ActiveUser::find(¥Auth::User()->id); |
たったコレだけの違いですが、見え方が違うとわかります。
ベストプラクティスでは、こう言った視覚効果まで考えてルール化しているので従った方が可読性が増すんです。
また、チームで開発していると方針としてのルールがないと「なんでもあり」になってしまうので【コードを統制する】と言う意味でもベストプラクティス(またはそれに類するチーム内のコード規約)は重要ですよね。
まとめ
今回紹介しているベストプラクティス以外にもリーダブルコードという超有名な書籍があります。
この書籍については案件探しの面談の中で「読んだことある?」と聞かれたことがありますので、探している方一度目を通す事をお勧めします。ルールに従って、みんなが見やすいコードを書いていきましょう。
-
前の記事
システム屋の視点でAmazonFlexのサービスを考えてみる 2021.10.08
-
次の記事
Laravel:Redis php_network_getaddresses: getaddrinfo failed: Name or service not known [tcp://redis:6379] 2021.10.18
コメントを残す