仕様変更に強い命名は大事だ。ボタンを「OKボタン」や「Noボタン」と名付けていたらヤバいかも。ゲーム開発に仕様変更はつきもの。開発中盤「OKボタンの色を使ってキャンセルボタンを作りたい」というケースもある。結論、用途ではなく機械的な名前をオススメ。後の参画メンバーの混乱は避けるべき。
業界違いだからなのかな、興味深い。名前は意味ベースが理想で、Button_Red, Button_X, Button_0的な色や物理配置や番号に依存しないほうがよいと思ってた。用途がコロコロ変わる場合も、Button_Primary, _Secondaryぐらいが限界で、それ以上は素直にボタン名か位置をリファクタするほうが良い気も
私は「楽しく動けばいいんじゃない教」筆頭だから、まぁまぁ命名は軽視してる。これは実務では非常に危険な思想だが、私が作るのが多くの場合モックアップまでという都合、プロジェクトにテロ行為をせずに済んでいる。役割分担というのは大事である
もちろんソースを引き渡す場合は整えて渡しますけど
命名規則はほぼ宗教なので、私は争うつもりはない。プロジェクトの主義に従う
傭兵だから「当プロジェクトではボタンに必ず動物の名前を入れ、UTF8の2バイト日本語で命名します。例えばこのOKボタンのオブジェクト名は"いぬボタン"です。動物図鑑がありますので使ってください」って言われても金もらった以上従う。金のうちだから。
ただ、長居はしないと思う。
命名規則やインデントで多くの血が流れた。これからもそうだろう。寛容だだけが平和をもたらす
UIの命名をマジックナンバーで管理されると、それはそれで困る。「あの番号は何のボタン?」みたいな情報共有が必要になって対応表がいるし、作る当人・・・つまり私がしんどい。
無個性で命名するメリットも確かに理解できる。ただ、自分はしない。
マジックナンバーというのは、プログラムにおいて作った当人しか意味のわからない数字のこと。
プログラムではマジックナンバーは入れないことが望ましく、変数やクラス名も誰が見ても役割が想像できるように具体的につけるのが良いとされてる。
なぜかというと、だいたいのプロジェクトは多人数でやるものであり、当人以外の誰が見てもわかりやすく、一見で意味や役割が理解できるコードが望ましいからです。
あと、数ヶ月前の自分も他人みたいなものなので、わかりやすくしとくと自分が助かる。
今日自分が爆発したとして、明日シーンとコードを引き継いだ人の理解を助けるような名前が一番だとは思ってる。これが私の宗教観です。
一人で作ってるときは「a」みたいな「今が楽なら良い」名前をつけます。神よ、我が怠惰をお許しください
「役割の変わるボタン、もくしは役割が検討中のボタンに命名する場合」とシチュエーションを狭めていれば、みんなそうだねで終わってたと思う。
例えがあんまり良くなかった。