可読性可読性可読性のはなし
アドカレ予定ではなんらかのUnityコーディング(UniRx,UniTask本の履修結果とかかきたかった)を書くといいましたがそれは嘘だ。
二回生のTZです。実はRiGのアドカレは分身(複数投稿)が流行っていまして、二度目なので自己紹介は省きます。
今回は可読性の話です。爆速で終わります。(なんか他のサークルのアドカレでも可読性って書いた記憶あるな……流用では……？)
可読性とは
可読性とはソースコードの読みやすさのことです。
ソースコード、動けばいいと思っていませんか？
私は短期間制作の際つい動けばいいや！をします。そして可読性がおざなりになり、制作速度も落ちることになるのです……。
可読性は大事です。数日後の自分や、共同作業をするまったくの他人にコードを読んでもらい、理解してもらわねばならないのです。
私は数か月前の自分のコードがわからず、フルでゲームを作り直すという無駄作業に一年費やしました。
可読性をあげたい
- 命名をちゃんとやる
- コメントをつける
- ドキュメンテーションコメントをつける
順番に説明します。
命名ちゃんとやる
変数名、関数名、クラス名など命名する機会は多いです。
そのときにint a;とか int GetProcess A(){}をやめて
int playerAttack;とか、int GetPlayerAttack(){}
にしようぜというお話です。
つまり、機械的な名前をやめて、意味のある名前をつけようという話です。これがレベル1。
レベル2,無意味な略称はやめましょう。略称って正直やばいんやなって大学の実習サンプルコードをみて理解しました。
元の単語が類推できなかった場合、その略称はただの暗号と化します。
プレイヤー操作クラス、PlayerCtrl。わからんくもないですが、現在はIDEの優秀な入力補完があるので素直にPlayerControllerと書きましょう。
変数名が数バイト長くなったり、文字がちょっと長くなったりしただけではメモリも時間も大して浪費しません。
レベル3,なんでも屋な名前はやめよう。
これは関数の切り分けにもつながる話です。みなさんは神クラスという名前を聞いたことがあるでしょうか？
神クラス。数百行から数千行ものコード量を誇るなんでもやれちゃうごっちゃごちゃクラスを指しますが、彼らはたいてい似たような名前をしていたそうです。
その名もなんとかManager。
やめて！ Managerに全部押し付けないで！！
例えばプレイヤーについてですが、プレイヤーのステータスなどのデータ、プレイヤーに入力を受け付けて移動を行う処理、移動や攻撃、被攻撃を受けてアニメーションをする処理、攻撃を受ける処理、選択肢のフラグ……。などなど。プレイヤーにまつわるというだけでPlayerManagerに処理を押し付けるとえらいことになります。
選択肢のフラグなんかシナリオ関係のスクリプトでよくない？？ってなりますし、プレイヤーに関してだって、PlayerStatus(データ専門),PlayerMove(移動入力受けつけ、位置移動),PlayerAnimation(アニメーション管理)とかってわけたらいいんですよ。
どうせPlayerオブジェクトにManager1つ貼り付けようが分けたスクリプト5つくらい貼り付けようがそんなに変わらんと思います。
曖昧な名前にして、とりあえずここだろって適当に処理を放り込む曖昧ネーミング。やめよう、絶対。(ブーメラン)
コメントつけよう
みなさんコメントつけてますか？
//からはじまる一行コメント
/*で囲まれる数行コメント*/
基本は名前だけで説明することが一番らしいですが、コメントも大事です。
処理が複雑になってしまったとき、こうこうこういう理由です、ごめんね！とか書いてる気がする(いいのかわるいのかわからん)
一年にわたる長期プロジェクトと化しているとある先輩の某プロジェクトでは、前半期に書かれたコードを数名で読み、ときおり手を加えているらしいですが、
その際、やったこと、考えたことなどを手を加えた本人の名前と一緒に書き残しているそうです。はえーすごい。
ソースコード解読の手がかりになる情報がコメントとして残っているだけでMPの回復量はえぐいです。ぜひコメントを書きましょう。
ドキュメンテーションコメントをつけよう
ドキュメンテーションコメントってなんぞやって人もいるかもしれません。
クラスや関数の最初の行の上で、///とバックスラッシュを三回打つと、IDE補完でこんなものがでてきます。
///<summary>
///ここに概要を書く。なんとかするクラスです。これこれこうする関数です。
///</summary>
時と場合によっては、この下に
<return>返り値設定してたらでる。なにが返ってくるか書く。</return>
<param name = “仮引数名”>引数設定してたらその数だけでる。何がいるか書く</param>
みたいなのが出るかもしれません。
これは、書いておけばC#のコードをコンパイルする際に自動でXML形式のドキュメントを生成してくれるよってやつらしいです。
これのなにがいいかですが、まず概要を書いているのでたいていの場合その関数をすべて読む必要がなくなります。
アセットのコード呼び出してるときとかもそうですが、使い方さえわかれば中身は知らなくていい、をすることができるようになるっていう。よくない？？
(内部全部知らないとダメなんだ！って場合はそもそも設計がダメな説ある)
で、さらにこれらの概要説明は関数やクラスを呼び出している、参照しているところをマウスホバーすることで表示されます。
他人のコードおよび昔の自分のコードを読んでいて、呼び出し/呼び出され関係が現れると、呼び出してるもの、呼び出してきてるものまで辿って見ないといけません。今はなんかVisualStudio2019だっけ？のおかげで参照してきてるとこがいくつかとかそこがどこかとか一目瞭然で神なのですがそれでもめんどい。
しかし、ドキュメンテーションコメントがある。見る。ほうほうこんな関数を呼び出してるのかー。終わり！！！！！<-これができる。
ということでドキュメンテーションコメントは書きましょう。
おわり
爆速とか言ったけど以外に長くなったのでコメントとか名前とかすぐできそうなやつだけ書きました。
if文のネスト爆散とか関数の切り分けについては、リーダブルコードとかゲームプログラマのためのコーディング技術とかそーいう本を読んでください。
いうて名前付けに気を使っていれば自然と関数、クラスは切り分けられるはずだと思います。i
f文ネストに関しては条件を少なくできないか？とか考えて、無理なら条件に合わないやつをさっさとreturnする早期returnを使ってください。
以上！！！私もフリゲ語りしたい。
