tanaka's Programming Memo

プログラミングについてのメモ。

Unityの命名規則とエディター設定

2023/8/18 あれこれ調べてprivate変数の前に_を付ける記法はまだ採用が少なかったので元に戻しました。

2023/8/17 情報が古くなったので一部改訂しました。

  • プライベート変数はキャメルケース_からはじまるキャメルケース 2023/8/18に取り消し
  • パブリック変数は原則としてプロパティーにすることを追記
  • 変数は名詞、インターフェースは形容詞、関数は動詞からはじめる、boolは疑問形にする
  • イベントの命名ルールを追記

この記事は、Unity #2のカレンダー | Advent Calendar 2019 - Qiitaの7日目の記事です。

qiita.com

前日の記事は、@ma_shさんのGraphView完全理解した(2019年末版) - Qiitaでした。

qiita.com


色々な言語を渡り歩いていたことで、変数名やら関数名の書き方になんとなくルールはあるけどその時の気分でブレる、というのが最近の状況でした。Unityのアセットでも違うし・・・。

ぼちぼちちゃんとしようと思い、Unityではどんな感じなのかを調べてみました。併せて、Visual Studio Community(多分Codeとか他のエディターでも使える)で自動的に規則をチェックしてくれる設定ファイルも用意してみました。

目次

まず結論

あれこれは後回しにして、今回まとめた内容です。

大文字と小文字のルール

  • Unityで作成するアセットやクラス名、メソッド名、プロパティー名など、原則としてはパスカルケース
    • PascalCase (単語ごとに頭文字を大文字で書く)
  • メンバ変数、ローカル変数、パラメーター(引数)は、キャメルケース
    • camelCase (パスカルケースの頭文字を小文字にした版)
  • インターフェースは頭文字をIにして、パスカルケースで続ける
    • IMyInterface
  • Unity以外で作成する画像や音声データなどは、小文字のスネークケース
    • snake_case (小文字のみで、単語の区切りはアンダースコア_)

Visual Studioなどで、自動的にやるには以下の手順を。

  • Unity用の.editorconfig | たなかゆうを開いて、.editorconfigという名前で、Unityのプロジェクトフォルダー直下に保存
  • Unityからプロジェクトを開いて、何かスクリプトを開く
  • プロジェクトメニューから、既存の項目の追加をクリック
  • コピーした.editorconfigファイルをダブルクリックして追加

以上で、エラー一覧ウィンドウのメッセージのところで、規則違反を確認できます。

命名規則違反の例

名前に使う単語

  • 変数名は名詞。ただし、bool型の場合はiscanをつけて疑問形にtrueやfalseで答える形にする
  • 関数名は動作を表す動詞ではじめる。これもbool型を返すものについてはIsCanHasなどを頭にもってきて疑問形にする
  • インターフェース名は形容詞
  • イベントのデリゲート名は、処理前なら進行形の動詞、処理後なら過去形の動詞を付ける
  • デリゲートをInvoke()するための関数はOnを頭につける

public変数について

原則としてpublicな変数は使わず、値を公開したい場合はプロパティーを使います。

// 読み出しだけなら => か自動実装書式が便利
int _myData;
public int MyData => _myData;

public int MyData2 {get; private set;}

// 読み書きなら自動実装書式
public int MyData3 {get; set;}

これらをまとめたサンプルを以下のリポジトリーで公開しています。

GitHub - am1tanaka/Unity-Code-Style-Guide: A inspirational C# code style guide for Unity projects

以下、お暇ならどうぞ。

命名規則とは

ファイル名やクラス名、変数名などをつける時の規則のことです。

一番の役割は問題を予防するためでしょう。Unityの場合であれば、ファイルやフォルダー名にはユーザーフォルダーも含めて日本語にしない!というのがあります。常に問題になるわけではありませんが、WebGLだとビルドに失敗する爆弾を抱えることになります。Unity1週間ゲームジャムの締め切り間際に時々、断末魔がTLに流れますが、そのような事態を防ぐことができます。

プログラミングの場合は、変数や関数がどのようなものか予想しやすくするということが挙げられます。ぱっとコードを見てなんとなくやっていることが予測できればバグの予防や保守性の向上に繋がります。また、変数や関数名を考えるのが苦手な人は多くて、そういう人たちには命名のヒントになります。

バイブルはUnity Communityに決めた!

まずは宗派を決めます。なるべくオフィシャルの近くで議論されているところがいいなぁということで、Unity Communityのものを柱にすることにしました。

http://wiki.unity3d.com/index.php/Csharp_Coding_Guidelines

調べると大体ここが出てくるので、総本山と見てよさげです(シングルトンのひな形などもあちこちで散見しますが、自分はUnity Communityのものを利用しています)。 → 2023/8/17現在、ページが消えてました。

和訳は @shun-shun123 さんがしてくださっています。

qiita.com

新しいドキュメントがUnity公式から公開されて、2023/8/17にこちらに乗り換えました。

Create a C# style guide: Write cleaner code that scales | Unity

Unityにおける命名規則

個人的には、かっこの位置とか細かいことは全く気にならない(違いに気づけない)ため、Visual Studioさんにお任せです。ということで、重要なのは命名規則のところです。以下に抜粋。

  • ハンガリアン記法は使わない
  • 接頭語(, m, s_, etc)は使わない使うか使わないかを決めて、その方針を一貫させる
  • ローカルとメンバ変数を判断するときは"this"を使う
  • メンバ変数にはキャメルケースを使う(e.g myData)
  • パラメータにはキャメルケースを使う
  • ローカル変数にはキャメルケースを使う
  • 関数、プロパティ、イベント、クラス名にはパスカルケースを使う(e.g MyData)
  • インタフェースの名前は"I"から始める
  • enums, classes, delegatesの先頭は文字で修飾しない

原則としては、マイクロソフトC# プログラミングガイドに従おう、ということだそうです。こちら、とても参考になります。

docs.microsoft.com

そして日本の場合、

  • 日本語や全角文字を使わない

も加えておくのが良いでしょう。せっかく規則を作るのだから、要らぬ混乱の元は断ち切っておくのが吉。

ハンガリアン記法DirectXの頃は使ってたなぁ。その下の「接頭語は・・・」や「enums, classes, delegatesの先頭は・・・」もハンガリアン記法ですよね。昔は今みたいにコードの説明を自動的に表示してくれるなんてしてくれなかったので役立ちましたが、今どきの頭のよいエディターは全部表示してくれるから確かに要らない気がします。時代に合っていてよいですね。インターフェースのIが生き残っているのは趣深い。

パスカルケース

ざっくりとまとめると、基本的にはパスカルケースを採用しています。パスカルケースは、単語の頭文字が大文字であとは小文字で書く方法です。

// :
PascalCase

というような感じです。

キャメルケース

メンバ変数、ローカル変数、パラメータ(引数)にはキャメルケースを使います。キャメルケースとは、最初の文字が小文字のパスカルケースです。

// :
camelCase

となります。ルールはこれだけで、列挙子や定数、プロパティなども、ここに登場しないものはパスカルケースです。統一されていて守りやすい規則でいいですね!

staticと公開範囲はどっちが先?

// こんな順番のと
static public int staticFirst;

// こんな順番のがある
public static int staticSecond;

アセットの中身見てると、ちょいちょい前者の順番を見かけます。そう書いてもVisual Studioさんが逆にしちゃうのでもっぱら後者を使ってます。C# プログラミングガイドでも後者の順番でしたので後者でよさそうです。

docs.microsoft.com

ファイル名の命名規則

Unityで作成するファイルはビルドされてるのでこれでいいのですが、画像や音声など外部から読み込む可能性のあるファイルについては別規則の方がいいかも・・・という気がします。Linuxなどでファイル管理する場合、大文字小文字が入り乱れるのはなんとなく気持ち悪いし・・・。ということで、Unity以外のツールで作成するリソースについては、他の命名規則の方がいいかもしれない、ということで探したところ、クラスメソッドさんの以下の記事がよさそうです。

dev.classmethod.jp

命名規則の必要性などについても、しっかりと書かれております。

ファイル名やレイヤー名はスネークケース

スネークケースとは、単語をアンダースコア(_)でつなげる書き方のことです。上下にうねうねして見えるのが蛇っぽいからとかなんとか。

// :
snake_case

Linuxファイルシステムは大文字と小文字を区別するため、大文字小文字を混ぜたファイル名のつけ方をすると、同じファイルのつもりが別のファイルになってしまっていたというような問題が発生します。さらにその状態で大文字小文字を区別しないWindowsとやり取りするとえらいことになります。ということで、識別がしやすい小文字に統一するのが一般的だと思います。そして、こちらでも日本語は封印されています。

単語の並べ順や単語数は、プロジェクト次第で決めることになると思います。リソース数が数十程度の小さなプロジェクトなら名称_目的や行動[_通し番号]で、あとはフォルダー分けするぐらいでしょうか。

haku_walk_00.png
haku_walk_01.png
block_albedo.png
block_normal.png

何千とか何万のリソースを使うプロジェクトでは、カテゴリーや種類なども含めたり、解像度によってリソースを切り替えたい場合などもそれ用の記載が必要になると思います。プロジェクトの規模や、扱うリソースの複雑さ次第で、適した命名ルールを決めていくことになると思います。綺麗に種類ごとに並ぶような命名方法が使いやすい方法だと思います。

コード規則を自動化するEditorConfig

規則を決めても、守られているかを人力でチェックするのは辛いです。これを自動化してくれるのがEditorConfigです。

editorconfig.org

docs.microsoft.com

仕様に従って作成した.editorconfigという名前のテキストファイルをプロジェクトフォルダーに入れておくことで、命名規則やかっこの位置などについてのチェックをしてくれます。Visual Studioをはじめ、コードエディターなら大体機能を持っていると思います。以下、Visual Studio 2019 Communityで作成した設定ファイルです。

この.editorconfigをUnityのプロジェクトフォルダーの直下に置いておけば、エラー一覧のメッセージに以下のように規則違反があれば表示されるようになります。

命名規則違反の例

ただ置くだけでは機能しないかもしれません。その時は、以下の手順でプロジェクトに読み込みます。

  • プロジェクトメニューから、既存の項目の追加をクリックします
  • コピーした.editorconfigファイルをダブルクリックして追加します

以上でプロジェクトに設定が読み込まれて規則のチェックが動作すると思います。それでも表示されない場合は、エラー一覧ウィンドウのメッセージボタンの右にあるコンボボックスを確認してください。IntelliSenseが含まれていない場合は動作しないので、ビルド+IntelliSenseにしてください。

改行コードの不一致の修正

改行コードがLFやらCR+LFやら混在しているとUnityがwarningを出します。上記の.editorconfigでは改行コードをWindowsに統一する設定をしているので、警告が出たスクリプトVisual Studioで閉じて開けば修正してくれます。

規則をカスタマイズする

この設定ファイルはざっくり作ったもので、運用はこれからなので抜けがあるかも知れません。.editorconfigを直接書き換えるか、Visual Studioで設定を編集することができます。

Unityからソースコードを開いて、ツールメニューからオプションを選んで、左のメニューからテキストエディタ > C# > コードスタイルを開くと、設定を確認できます。

コードスタイルの設定

設定方法はコガネブログさんで紹介されています。

baba-s.hatenablog.com

まとめ

Unityで作成するアセットやファイル、クラス名、メソッド名などは、原則として頭文字を大文字で表すパスカルケースにします。

メンバ変数、ローカル変数、パラメーター(引数)のみは最初の文字が小文字で、それ以外は単語の頭文字を大文字にするキャメルケースにします。

Unity以外で作成する画像ファイルや音声ファイルについては、単語の区切りをアンダースコア(_)で区切って、小文字の英語と数字を使うスネークケースを採用することにしました。

.editorconfigはとても強力です。うっかり名前を付け間違えても教えてくれるので、チームで共有すると便利です。

この方針で運用してみて、何か出てきたら見直していこうと考えています。これまで微妙にブレていた方針が統一されてすっきりしました。

見落としや誤り、こっちの方がいいよ、というところがございましたらお知らせいただければありがたいです!

明日は、@su10さんの番です!!

参考・関連URL