モデル設計時の規約を決めた

これまで一緒に仕事をした経験の無い新しいメンバーと一緒に仕事する事になったので、
規約を決定してみた。
とりあえずモデル設計からみんなで取り掛かったので、その時に決めた。

1. 名前は　:name, :tel 等、単純にする。モデル名と重複させない。
2. Railsの規約に従って、モデルは単数系/テーブルは複数形
3. set_field_namesで、カラムに対応した日本語名をつける。
4. t.timestampsで、created_at,updated_atは必ずつける。
5. テストファイルも必ずコミットする。
6. migrationファイルは、downも書く事
7. 名称は省略しない。

それぞれの規約の目的

名前は　:name, :tel 等、単純にする。モデル名と重複させない。

例えばSystemモデルの内部にシステム名を持とうとしてSystem.system_nameのように
重複してアクセスさせたくない。冗長な記述になっちゃうというのが一番。
後、メタプログラム的に、Model.nameでアクセスできると後々全体への変更がしやすいという事も。

Railsの規約に従って、モデルは単数系/テーブルは複数形

railsで作ってるんだからrailsの規約は守ろうね！という話。当たり前だよね。

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にしましょうという話。
わけわかんなくなっちゃいますからね。

とりあえず、まだまだ明文化していくべきルールはあると思うけど、一応こんな感じでまとめて行ってる。
というか、コーディング規約というより「作業時の注意事項｣になってる様な気配もｗ