モデル設計時の規約を決めた
これまで一緒に仕事をした経験の無い新しいメンバーと一緒に仕事する事になったので、
規約を決定してみた。
とりあえずモデル設計からみんなで取り掛かったので、その時に決めた。
- 名前は :name, :tel 等、単純にする。モデル名と重複させない。
- Railsの規約に従って、モデルは単数系/テーブルは複数形
- set_field_namesで、カラムに対応した日本語名をつける。
- t.timestampsで、created_at,updated_atは必ずつける。
- テストファイルも必ずコミットする。
- migrationファイルは、downも書く事
- 名称は省略しない。
それぞれの規約の目的
名前は :name, :tel 等、単純にする。モデル名と重複させない。
例えばSystemモデルの内部にシステム名を持とうとしてSystem.system_nameのように
重複してアクセスさせたくない。冗長な記述になっちゃうというのが一番。
後、メタプログラム的に、Model.nameでアクセスできると後々全体への変更がしやすいという事も。
set_field_namesで、カラムに対応した日本語名をつける。
ActiveHeartは使わないで下さいってあるけど、今回はモデル図を常にシステムから作りたいなーと思ってるので、
set_field_namesをrailroadで読み込む様に、railroadちょっと改造しようかなと。
t.timestampsで、created_at,updated_atは必ずつける。
多少遅くなるかも知れないので、要らないテーブルは要らないってちゃんとするべきなんだけど、
大体の場合、必要なテーブルから抜けてる事が多いので……。
テストファイルも必ずコミットする。
svn addからテストファイル抜けてて後から用意するのめんどくさいので、
ちゃんと意識してねーと。
migrationファイルは、downも書く事
「downいらねーじゃん」って言ってる人も居たので明文化、全員用意するって言う前提が無いと意味ないですしね。
名称は省略しない。
カナ名をkn_nmとかkana_nmとかじゃなくてkana_nameにしましょうという話。
わけわかんなくなっちゃいますからね。
とりあえず、まだまだ明文化していくべきルールはあると思うけど、一応こんな感じでまとめて行ってる。
というか、コーディング規約というより「作業時の注意事項｣になってる様な気配もｗ
