UnityとVisual Studioの開発における相違点

Unityを勉強していて、色々と疑問が出て来た。Visual Studioで普通のアプリをC#で開発してきた人にとっては、戸惑う部分がてんこ盛り。ものすごいプログラマなら大丈夫なのかも知れないが、僕程度のプログラマでは迷った挙げ句に一端妥協してしまう事が多い。うーん。 サンプルコードとか、開発中に気付いた事を書いてみる。

何故かvarが全然使われていない

いや、本当に理由がわからない。初心者にいきなりvar使わせるのはどうかと思うので、そういった入門とかならまあいいんだろうけれど。色々と文章や情報を調べてみても、varが本当に滅多に使われていない。理由が不明。

LINQが使われていない

これはまあ、わかりにくいからだと思われる。というか、色々な所でそんな感じの事が書いてある。良くも悪くも、UnityでC#を扱っている人は生粋のC#使いではないケースが多い様だ。あと、LINQのサポート自体もなんかバグだらけな様だし。一応、サポートするライブラリは出てはいるけれど……。

やたらとメンバ変数を活用する

プロパティにしといた方が良かったんじゃあ……。プロパティじゃあ自由度高すぎてアレだったんだろうか？　しかし、publicなメンバ変数が大量に並んですごく不安な気持ちにさせられる。というか、WindowsアプリをC#で作る時にpublicなメンバ変数なんぞ、そもそもあり得ない。何か特殊な理由がない限り、普通は全部プロパティにする。

そして、使用頻度が高くなるので命名規則が変わる。C#ではprivateなメンバ変数は「_hogehoge」みたいな最初にアンダーバーを付けるネーミングが多かった様に思う(僕だけじゃないよね？)が、そうする意味が薄れる。

名前空間をあまり使わない

使うケースももちろんあるのだろうけれど、サンプルコードとか見ると名前空間を全然使ってない。Windowsでは名前空間を使わない事の方が珍しいぐらいだが……。 しかし、Unityも開発を進めていくと、やはり名前空間による整理整頓は必須だった。なんでサンプルでこれに触れないのか、デフォルトで無しになってるのか、そこら辺の理由はわからない。

スクリプトがシーンに従属していない

UnityのシーンをVisual Studioで対応づけるのであれば、フォームになると思う。 Visual StudioではフォームはそれそのものがC#によるクラスであって、デザイナはあくまでコードの出力装置に過ぎなかった。 しかし、Unityでのシーンは完全に在り方が違う。 シーン=クラスではないし、シーンファイルはコードですらなく、バイナリだ。いじれない。 そもそも、シーンそれ自体に従属するスクリプトがないのだ。 そして、シーンがクラスでは無いという事はどういう事かというと、シーンの中に散りばめたコンポーネントがそれぞれ独立している感じなのだ。

こんな感じ。 シーンはコンポーネントを束ねる場でしかなく、コンポーネントを内包している感じではない。いや、実際は内包しているのだけども。Windows Forms程強固な関係に思えないのだ。 シーン内の何かを探したければ、一々「Find("コンポーネント名")」しなければいけない。 コンポーネントと実際のコードの紐付けを、一々手動でしなきゃいけない。 ややこしい。 下手をしたら、素人の人よりもVisual Studio経験者の方が慣れるのに時間かかるんじゃなかろうか。

うーん、なんかこう、上手く言葉に表せない。まあ、また思いついたら書こう。

……ふと書いてる途中でコンポーネントじゃなくてオブジェクトだな、と思ったけど面倒だから書き直さない。