【プログラミング全般】命名の方法について

Question

こんにちは。

プログラミングにおいて、クラスや関数、変数の命名は重要な要素です。
私は個人でゲームアプリ開発をしていて、プログラミングの経験はあまり多くはなく、オブジェクト指向の恩恵を強く感じた事は無いです。
自分で作って自分で見直したり修正をするだけですが、それでもある程度はグローバルな命名ルールを下に設計・命名した方が、後々良いと考えて質問させていただきます。

私がプログラミングや設計（オブジェクト指向言語）をしている時に、命名で迷うのは２パターンあります。

（１）：◯◯Managerや◯◯Controllerなど
この２つは、どちらか片方だけにするべきなのでしょうか？
個人的には、ゲーム開発において特定のキャラクターの振る舞いを表すクラスは、ManagerではなくControllerにしています。特に、座標移動をする場合はマネージメントというよりコントロールだと思うからです。

オブジェクト指向的に分割しすぎるのは可読性の低下を招くので良くないというのは間違った考えでしょうか？
オブジェクト指向に適した設計をしていけば、ManagerクラスやControllerクラスは良くないという話は聞いた事があります。絶対神のクラスとまでは行かずとも、八百万の一柱くらいになるのは確かだと思います。
しかし、せっかくの高水準言語なのですから、人間の認知に近い・人間にとってイメージしやすいクラス分割をする方が、可読性が良くなるのではないでしょうか？

（２）：上記（１）の◯◯の部分や関数名
単に英語力の問題に近いかもしれません。
しかし、例えばStateのように、この世界の用語を使ったりしてフレームワーク的（パターン的）な意味合いを込めて命名することも多いと思います。
みなさんはこの辺どうしているのでしょうか。積み重ねた経験でしょうか？

みなさんの考えをお聞かせください。
また、参考にされている書籍やWebサイト等ございましたら、紹介していただけると嬉しいです。
よろしくお願いいたします。

Answer 1

わたしも英語が苦手なのでこちらのサイトをよく使ってます。
codic.jp

Comments

[Chironian]

このサイト知りませんでした。これは便利そうです。ありがとう。

[Boemusan]

便利なサイトのご提案ありがとうございます！

しばらく、単語的に迷った時には使ってみようと思います。

Answer 2

こんにちは。

ManagerクラスやControllerクラスは良くないという話は聞いた事があります。

「◯◯Managerクラスや△△Controllerクラスという命名は良くない」という一般化は、狭い世界の例を引き合いに出して、それが妥当でない世界の存在を知らないまま、一般化するという人がよく犯すミスの１つと思います。井の中の蛙ってやつです。（私も人のことは言えません。油断するとやっちゃいそうになります。）

例えば、多くの要素がCharactor、Item、Fieldに分類できるプログラムで
CharactorController、ItemManager、FieldManagerのような命名は妥当かもしれません。

オブジェクト指向的に分割しすぎるのは可読性の低下を招くので良くないというのは間違った考えでしょうか？
せっかくの高水準言語なのですから、人間の認知に近い・人間にとってイメージしやすいクラス分割をする方が、可読性が良くなるのではないでしょうか？

大賛成です。
人が理解しやすいように分割することが重要です。
分割することでクラス間I/Fが無駄に発生するようですと、可読性はかなり劣化します。
I/Fは単純でも、折角１画面に収まっているものを無駄に細かく分割すると、やはり可読性は劣化します。

特に後者については、適切な命名をすればその内容を確認する手間が省けるので可読性が上がる旨の意見を公表している人も少なくないです。分かりやすく命名することは重要ですが、誤解のない命名は不可能ですから内容確認は必要です。（特にデバッグ時。）

（２）：上記（１）の◯◯の部分や関数名

正直、なかなか難しいです。意味が理解できる名前は非常に重要なのですが、長すぎる名前は逆に可読性を大きく落とすので難しいです。
従って、長くても単語２～３個程度でそのクラスやメソッドの最大の特徴を表現できていることが重要です。しかし、特徴は他のものと比較して発生します。開発当初は左上座標しか必要なかったからPoint getPosition();で良かったのに、右下座標も必要になったとします。すると、妥当な命名はPoint getTopLeft();、Point getBottomRight();のようなイメージになると思います。

つまり、妥当な名前は他との関係において決まるので、プログラムの開発に伴い変化する前提で考えています。時々リファクタリングしつつ妥当な名前に変えるという柔軟な対応してます。（別の表現では行き当たりばったりとも言います。）

Comments

[Boemusan]

ご回答いただきありがとうございます。
井の中の蛙というのはおっしゃる通りだと思います。正直初めて聞いた時、その人の業務・業界における凝り固まった考え方なのでは？と思ってしまいました。
オブジェクト指向と言っても、結局は開発環境や言語によって使用が異なるため、それぞれに異なる実装が必要になります。
そして私も、比較的ゲームやアプリ、Webの方に近く、開発規模は小さいです。
この世界は開発環境・ツールの進化がめざましく、使用する言語や環境が人間に近いものとなってきており、今回もこういった質問をしてしまっているわけですね。

私も開発途中で時々リファクタリングしてます。
途中でリファクタリングするのは経験不足だからだ、設計が行き届いてない・・・と考えていたのですが、柔軟な対応と置き換えたり、途中でリファクタリングするものだと想定して開発するなら、それはそれで正しいのかなと思いました。

Answer 3

（１）：◯◯Managerや◯◯Controllerなど
この２つは、どちらか片方だけにするべきなのでしょうか？

両者は全く同じ意味というわけではないので、意味に応じて使い分ければ良いと思います。

オブジェクト指向的に分割しすぎるのは可読性の低下を招くので良くないというのは間違った考えでしょうか？

オブジェクト指向的な分割が可読性の低下を招くのではありません。不適切な分割が可読性の低下を招くのです。オブジェクト指向的に分析し、適切に分割（役割分担）すれば可読性が上がるはずです。

オブジェクト指向に適した設計をしていけば、ManagerクラスやControllerクラスは良くないという話は聞いた事があります。

それは誤解です。オブジェクト指向かどうかは関係ありません。ManagerやControllerのような名前だと仕事を押しつけやすいのでクラスが肥大化しがちになる、ということに対する問題提起だと思います。名前がどうであれ、適切に役割分担すれば良いのです。そして、役割にふさわしい名前を付けることで可読性が上がります。

人間の認知に近い・人間にとってイメージしやすいクラス分割をする方が、可読性が良くなるのではないでしょうか？

その通りです。そのために、「設計」に時間をかけてしっかり分析して適切な役割分担を決めるのです。それはオブジェクト指向から外れることではありません。

（２）：上記（１）の◯◯の部分や関数名

私は英語力がないので辞書を引きながら名前を付けます。経験というか、各種SDKやOSSを使ううちに、それに影響を受けた部分はあるかと思います。基本的には何をするクラス（メソッド）なのかが判れば良いと思っていますが、業務では命名規則でルールを定めている場合もあります。

Comments

[Boemusan]

ご回答いただき、ありがとうございます。

オブジェクト指向はあくまで可読性向上につながるということですね。

正直なところ、人間にわかりやすい分割とオブジェクト指向というのは、相反するとは言いませんが、少し違ってくるのではないかと感じています。
逆に言えば、人間にとってイメージしにくいものはオブジェクト指向ではない（または単にふさわしい名前ではない）ということでしょうか？

[catsforepaw]

オブジェクト指向というのは、事象をどう捉えるかという考え方のことなので、的確に捉えて設計すれば判りやすくなり、不的確・不正確に捉えて無理矢理設計すれば判りにくくなります。
イメージしにくいと思うなら、それは設計がいまいちということであって、オブジェクト指向だから判りにくいということではありません。

Answer 4

Controllerという名前は画面の実装をするときに使うことが多いかと思います。
例えばPHPです。
http://www.objective-php.net/mvc/controller
ですので、独自で作るクラスにControllerという名前は使わないようにしています。

個人的にStaticなメソッドを実装しているものにはHogeUtil、インスタンス化するものはHogeComponentとしています。※これはどこかの案件でこういう規約だったので、分かりやすいなぁと思ってそのまま使っています。

関数名はメソッドについては基本的に英語ですが、余りに難解な単語を使うと逆に分かり難くなってしまいます。
例えば、Enumのメンバ名を付けるときに全部英語にするという規約のプロジェクトに参加したときに
あまりにも難しい単語で書く方が居て、他の誰も分からなかった経験があります。
そのため、他のプロジェクトでは全部ヘボン式の日本語にするとしたところ、CancelをKyanseruと書かれてしまい、これも逆に分かり難くなりました。

このあたりのさじ加減は非常に難しいところです。

Comments

[Boemusan]

ご回答いただきありがとうございます。

Staticなメソッドを持つクラスはUtilというのは賛成です。わかりやすいですね。
個人的には、今使っているゲームエンジン内スクリプトでは、既にエンジンにコンポーネントという概念・クラスがあるので、こちらは使えそうにありませんね。

全部ヘボン式日本語というのは、極端ですが、面白いですね
正直、無理に初めて聞くような単語を使うくらいなら、自分にわかりやすい日本語も混ぜていいのかなと考えてます。
特にローカル変数だと、妙に長い英語になったり、逆に単語を短くしてしまうと(PositionをPos、DistanceをDis等)、後でわかりにくかったりむず痒かったりします。

Answer 5

プログラミング言語は英語を元にした、(最終的に)マシン語にコンパイルされる中間言語です。

要するに文章なのです。
郷に入っては郷に従え、英語が元なら英語として読みやすい文章がゴールとなります。

リーダブルコードという書籍は既に目を通していますか？
もしまだなら読んでみてください。
命名はこの書籍の2〜3章に書いてあります。

◯◯Managerや◯◯Controllerなど

その場その場で適していると思う方を使ってください。
どのみちマネージャーもコントローラーも作業を指示するだけのスイッチ郡であるはずです。

座標移動をする場合

それはプレイヤーがコントローラーを操って、
ゲーム内のキャラクターを特定の座標まで移動させる行為
全てをコントローラーの1メソッド中にねじ込んでいるように思えます。

コントローラーは所詮コントローラーです。
ボタンと矢印キーしかないあれです。

オブジェクト指向に適した設計をしていけば、ManagerクラスやControllerクラスは良くないという話は聞いた事があります。

上記参照、Webサイトを構築するためのCakePHP等のフレームワークでは、
MVC（モデル・ビュー・コントローラー）という役割分担を行ってますが、
往々にしてコントローラーがモデルを取り込んでデブデブになってしまうケースがあります。

その辺と混同してるかもしれません。
適切な責務によって抽象化されたクラスの使い方が出来れば、そのような情報に惑わされる事はありません。

みなさんはこの辺どうしているのでしょうか。積み重ねた経験でしょうか？

○○は良いことなのだろうか？悪いことなのだろうか？
…と考える事はとても大事な事だと思います。

しかし、考える事は時間とパワーを使うので、私もついつい慣習で作業をすることがあります。
これは本来でいうと良くない事で、後で見るとリファクタリングしたくなります。

人間の認知に近い・人間にとってイメージしやすい

素晴らしい考えだと思います。
私としては、これはクラスだけに限った話ではなく、プログラミング全体に言えるのかなと考えています。

個人的に面白いと思っているのがプロビジョニングツールのChefですね。
パソコンのマシンの初期設定を行ってくれるこのシェフ、お前料理人じゃん！
そのシェフにクックブックという名のファイルを手渡してやると、それに従って初期設定前のマシンをセットアップしてくれます。
コマンドがレシピ、作業を行うマシンはナイフ・・・うまく比喩を使いながら表現しています。

sailsというWebフレームワークがありますが、
それの起動用コマンドはなんとlift！
海に浮かぶヨットが帆をかけているAA付きでWebサーバーが立ち上がります。

実際にはここまでフリーダムにやれとは思いませんが、
わかりやすく可愛い名前を付けたいですね。

Comments

[Boemusan]

ご回答いただきありがとうございます。

それらは既に比喩というレベルを超えているように思いますが、
カプセル化の考え方や、プログラマやユーザもまた適切な責務を持つべきだという考え方を踏まえると
大きいメソッド（多数のメソッドを実行するメソッド）やクラス、パッケージ名に関しては、そのくらいのユーモアがあるのが一番良いような気がします。
それにIT技術の歴史にはそのような例え・比喩がわりと多いと感じます。

業務では特に、そういう命名や例えは難しいと思いますが、積極的に取り入れてみたいと思います。
リーダブルコード読んでみます！

Answer 6

昔はハンガリー記法というので命名していましたね。
最近はこの記法はあまり使わないですが。

Comments

[Boemusan]

ご回答ありがとうございます。
学生時代に歴史的な知識として学びはしましたが、世代的に触れる機会は今まで一切ありませんでした。
自分ルールになる恐れもありますが、ユニークなパッケージ・クラスを作るときには、識別子も選択肢に入ると思います。特徴的なデバイスのAPIで、ハンガリー記法とまでいきませんが、スコープがわかるようにしているものを見たことがあります。

Answer 7

私は基本的な命名規則として、
インターフェースは振る舞いや概念を表す名前、
クラスは具体的な実装を表す名前を意識しています。
その名前を日本語で考えて、それを和英辞典に入れてるだけです。

例えば、キャラクターなら
ICharactorという概念を示すインターフェースがあり、
それを実装する形で、MovableCharactorやStrategiedCharactorなどとします。
MovableCharactorは単純に動かす機能を要求する実装で、
StrategiedCharactorは状況判断をしながら自動で動くための戦略を要求する実装、
という具合です。
（実際では、Charactorという概念が広すぎる印象があるので、もう少し具体的な概念に絞ります）

特に、座標移動をする場合はマネージメントというよりコントロールだと思うからです。

私は、平面上の移動という意味でPlanarMovementにするかもしれません。
そして、これは振る舞いなのでインターフェースにします。
さらに、クラスに実装する時に、例えば座標移動が自動か手動かで命名を決め、
AutomationやGamePadとします。

オブジェクト指向的に分割しすぎるのは可読性の低下を招くので良くないというのは間違った考えでしょうか？

個人的には、可読性よりも前に、変化の境界で区切るべきと考えています。
結果として分割されすぎてしまったとしても、
変化する領域から、変化しない領域を保護出来るのであれば、それで良しと考えています。

Comments

[Boemusan]

継承ではなくインターフェイスでキャラクターの概念を実装するのですか？
私ならCharacterという親クラスを作ってしまいますね・・・

「変化の境界」「変化の領域」とはどういった意味でしょうか？

[i50]

命名規則のお話から逸れてしまいすみません。

＞私ならCharacterという親クラスを作ってしまいますね・・・
単一の親クラスで、
発生しうるキャラクターの実装をカバーできるのであれば、
大丈夫かと思います。

インターフェースにしているのは、
あらゆる実装の可能性を完全にカバーできるからです。
テスト用のモックもカバーできます。

＞「変化の境界」「変化の領域」とはどういった意味でしょうか？
すみません。文章を短くしようと、ややこしい言い方になっていました…。

例えば、キャラクターを動かすことを考えた時、
自動的に動かす場合と、手動で動かす場合があるとします。

その時、キャラクターを動かす機能と、動かし方の間に「変化の境界」を設け分割します。
動かし方に自動や手動があり、それを「変化の領域」と表現していました。

変化するしないという観点で分ける事で、プログラムは拡張や変化に強くなると考えています。
理解しやすくても、実際に拡張や変化に強くなくては意味が薄いと考えています、
ということでした。

Answer 8

好みの問題だと思いますが私なら下記のようにすると思います。

・キャラクタークラス
→特定のキャラクターの振る舞いを表すクラス

・複数のキャラクターインスタンスやその他ゲームに関連するインスタンスを管理するクラス
→○○Controller

・通信やファイルなどのフレームワークの機能を使いやすくラッピングしたもの
→○○Manager

しっかりと分割すれば神クラスはなかなか発生しないと思います。たぶん

Comments

[Boemusan]

ゲーム以外のプログラミングをしている時は、原則、特定のAの振る舞いを表すクラスはAという風にそのまま名前を使っていたのですが
ノードやゲームオブジェクトの概念のあるゲームエンジンを使うと、特定のキャラクターの振る舞いを表すクラスの名前にそのままキャラクター名を使うというのが若干わかりにくい時があり、最近ではControllerに変えました。
というより、そもそもゲームエンジンを使う以上、キャラクターの振る舞いというより、実際にはキャラクターのオブジェクト・ノードを操作しているだけなので、そのまま名前だけというのは不適切になってしまう仕様なのかもしれません。

ゲームエンジン等ではなく、一般的な開発環境やネイティブアプリ開発環境(AndroidStudio, Xcode)であれば、私もyonaさんのような分割の仕方に近いと思います。

[yona]

ゲームだとまた違うんですね。
勉強になりました。

Answer 9

理想論を挙げても空論になるので、
まずは、出来る事から、
例えば、
数カ月～数年前の自作コードを見てみる、
⇒理解出来ない。追えない。なら、改善すべき点があるのでは？

代理検索

コード規約 初心者
https://www.google.co.jp/search?hl=ja&q=%E3%82%B3%E3%83%BC%E3%83%89%E8%A6%8F%E7%B4%84%E3%80%80%E5%88%9D%E5%BF%83%E8%80%85&lr=lang_ja&gws_rd=ssl

コード規約 MVC
https://www.google.co.jp/search?hl=ja&q=%E3%82%B3%E3%83%BC%E3%83%89%E8%A6%8F%E7%B4%84%E3%80%80%E5%88%9D%E5%BF%83%E8%80%85&lr=lang_ja&gws_rd=ssl#lr=lang_ja&hl=ja&tbs=lr:lang_1ja&q=%E3%82%B3%E3%83%BC%E3%83%89%E8%A6%8F%E7%B4%84%E3%80%80MVC

Comments

[Boemusan]

ご回答いただき、ありがとうございます。

こうして理想論的な質問をしておきながら、私はやはりまだまだ未熟です。
数ヶ月経つと、同じような内容のメソッドでも、明らかにコードの読みやすさ・記述方法（コメントの仕方）・アルゴリズムが変わっています。
私の場合、２年も経てば、開発環境や使用言語自体が変わってしまいます。
過去の自作コードは、１週間前のものでも、改善すべき点だらけです。

コード規約やMVCという単語は数年前に聞いたことはありましたが、勉強もせずに今に至っています。
この機会に、勉強してみようと思います。