変数・関数・テーブルやカラムの名前

ネーミングってどうしてる？

WEBサービス部まで受講された方は今まで「変数・関数・DBのテーブルやカラムの名前」ってどうやって付けているでしょうか？

実際の現場では、こういった名前付け（ネーミング）が結構重要になります。

なぜなら、後々何も知らないエンジニアが入ってきた時（あなたもその１人になるでしょう）に他人が書いたソースを見て、どういう仕組みで動いているのか、どういう処理の流れになっているのかを把握する必要があります。

その際に「変数や関数の名前」を見て、まずはパッと処理を判断することになります。

もしこれが変な名前になっているとソースがとても見辛く（追いづらく）なってしまうんです。

例えば足す関数なのに引く処理をやってたら、そりゃあ混乱しますよね。

足す関数だと思って、そのまま既にある誰かが作ったその関数を使ってしまうかもしれませんね。

これは流石にないと思いますが、じゃあこれはどうでしょうか？

ちょっとありえそうな感じですね。

（さすがに現場のエンジニアではやらないですが、初心者はやりがちです）

DBも同じく、数値が入ってそうなカラム名に文字列が入っていたら混乱します。

（phpでMySQLから取得してきた値は全て「文字列」として扱われますし動的型付け言語なので、データを受け取る変数にはどんな型のデータでも入れられます。なのでそういう場合は気にしなくてもいいですが、Java言語などは受け取る変数には型が必ずあるので思わぬとこで違う型のデータが入ってきてしまうとエラーになります）

まぁ、例のように数行のコードの中ならすぐに判別も出来ますが、何百ファイルの中に何千行もコードが書いてあるのが普通の現場です。

その中で、「こういう処理をしたいんだけど同じような処理ってもう関数で作ってあったりしないかな？」と思って探そうとしても、当たりをつけた名前と全然違ければ探すのは困難になります。

そうすると既にあるのに同じ関数を別で作ってしまったり（実際の現場でもよくあることです）、ルールに沿って名前がつけられてないと後から「同じような処理の中身を書き換えたい。削除したい」といった場合に大量のソースの中から検索をかけて修正を加えていくので、「修正漏れ」が発生する原因にもなります。

長い名前は付けない

名前は長くても20文字程度に収まるように設計する。無駄に長い名前は可読性が落ち、入力が面倒で打ち間違いの元になる。言語によっては変数名の長さに制約がある。

しかし現在の言語では制約がないものが多く、IDEの補完機能もあるため無理に短くするルールに縛られる必要はない。

理解できる名前にする

短ければ良いというものでもなく、適切な長さで意味の通じるものにする。また他の要素と混同するような省略の仕方は避ける。

短く済むならわざわざ省略しない

複数の単語を組み合わせる場合はキャメル記法かスネーク記法を使う

//悪い例 $dosaveoptions //良い例 $do_save_options //単語ごとにアンダースコアで繋ぐ書き方をスネーク記法という $doSaveOptions //２単語目以降の先頭文字を大文字にするのをアンダーキャメル記法という。一般的に変数や関数名に使う。 $DoSaveOptions //１単語目以降の先頭文字を大文字にするのをアッパーキャメル記法という。一般的にクラス名に使う。

1 2 3 4 5 6

//悪い例 $dosaveoptions //良い例 $do_save_options //単語ごとにアンダースコアで繋ぐ書き方をスネーク記法という $doSaveOptions //２単語目以降の先頭文字を大文字にするのをアンダーキャメル記法という。一般的に変数や関数名に使う。 $DoSaveOptions //１単語目以降の先頭文字を大文字にするのをアッパーキャメル記法という。一般的にクラス名に使う。

※実際の現場ではキャメル記法がほとんど

慣例としてあるものはその例に習う

略語が一般的なもの

//悪い例 $average //良い例 $avg   //悪い例 $Monday //良い例 $Mon   //悪い例 $number //良い例 $no

1 2 3 4 5 6 7 8 9 10 11 12 13 14

//悪い例 $average //良い例 $avg   //悪い例 $Monday //良い例 $Mon   //悪い例 $number //良い例 $no

真偽値を取るものは先頭にisを付ける

//悪い例 $Login //良い例 $isLogin

1 2 3 4

//悪い例 $Login //良い例 $isLogin

定数の場合は大文字にする

//悪い例 database_path //良い例 DATABASE_PATH

1 2 3 4

//悪い例 database_path //良い例 DATABASE_PATH

以上のルールを混ぜない

せっかく良いルールを作っても統一されていなければ意味がありません。
また、どんなに自分のルールが素晴らしいと思っても、既に決められたルールには従いましょう。

//悪い例 $user_id、$UserEmail、$user-name //良い例 $user_id、$user_email、$user_name

1 2 3 4

//悪い例 $user_id、$UserEmail、$user-name //良い例 $user_id、$user_email、$user_name

対義語を理解する

こちらも間違って使用すると何のことやら分からない変数が出来上がるので注意。

Begin ⇔ End
Start ⇔ Stop
Top ⇔ Bottom
High ⇔ Low
Big ⇔ Small
Create ⇔ Destroy
Previous ⇔ Next
Allocate ⇔ Free
Attach ⇔ Detach
Get ⇔ Set
Get ⇔ Put
Input ⇔ Output
Show ⇔ Hide
Go ⇔ Back
Up ⇔ Down
Upper ⇔ Lower

ネーミングの参考になるサイト

処理内容を入力すると良い感じのネーミングを自動で生成してくれる「Codic」

https://codic.jp/

Qiita「うまくメソッド名を付けるための参考情報」

http://qiita.com/KeithYokoma/items/2193cf79ba76563e3db6

まとめ

フレームワーク部やPHPオブジェクト指向部を受講された方はクラス名やプロパティ名、メソッド名といったものも、このネーミングが大事になります。

さらにネーミングをつける場合「クラス設計」といったもの考えないとなかなかきちんとしたネーミングをつけることが出来ず、エンジニアとしては「ちゃんとやりたい！」と思う人も少なくありません。

しかし、「ちゃんとやる」ということはその分「時間がかかる＝工数がかかる」ことになります。

きちんとしたネーミングをつけることが必ずしも正しいわけではなく、事業として一番大事なのは「利益を上げること」ということを意識して、状況によっては「パパっと作ってしまう」方が大事だということも理解しながら臨機応変に対応していきましょう。