実際のコーディングに近い部分のルールをまとめます コーディングの心得 五ヶ条株式会社電通国際情報サービスによるJavaコーディング規約より: 一、見やすさを重視せよ タスク・タグソース内に以下のルールでタスク・タグをうつことが可能です。 Eclipseを利用している人は 設定 -> Java -> コンパイラー -> タスク・タグ で設定を変えられるので統一してください。 またこれ以外のオレオレタスク・タグはtrunkには適用しないようにしましょう。(各個人のブランチは自由にやって問題なし) BUGもしバグを発見し影響範囲が広いために即時修正をできない場合は必ずチケットを発行し、チケット番号を書いてください。 また必ず具体的な発生条件と詳細を記載してください。長くなる場合はチケットに書いた上で「詳細はチケットxxxxで」といった形にしてください。 例) BUG: ○○の際に文字化けする。詳細は #999 だめな例 BUG: なんかうまく動かないときがある FIXME重要度は低くバグではないが、修正が必要な箇所につける。 その際、必ず具体的な問題点を明示すること。 粒度的にはチケットが必要か微妙な場合があるが、もしチケットを必要とするほど大きなリファクタリングの場合は必ずチケット番号を記述する 例) FIXME: レコード数が増加した際に対応できないため、別のアルゴリズムに変更した方がいい だめな例 FIXME: あとで直す MEETING以下のような次回ミーティングで話し合うべき箇所につける。
命名規則
クラス/モジュール名
正しい例: module ExampleModule 誤った例: module Example_Module 例外クラス名
メソッド名
正しい例: def add_something 誤った例: def addsSomething 定数名
正しい例: EXAMPLE_CONSTANT = "foo" 変数名
正しい例: local_variable ファイル名
正しい例: # Fooクラスを定義 ソースコード全般インデント半角スペース2個 コメント
クラス/モジュールの定義クラス/モジュールの定義が3段以上ネストする場合は、ネストが深くなるのを防止するために、ネストの定義と実装を分離する。 module Foo メソッドの定義メソッド定義の仮引数リストには括弧を付ける。ただし、引数がない場合は、括弧を省略する。 正しい例: def foo(x, y) 誤った例: def foo x, y クラスメソッドの定義
正しい例: class Foo 誤った例: class Foo メソッド呼び出しメソッド呼び出しの引数リストには括弧を付ける。ただし、引数がない場合は、括弧を省略する。 ただし、加算などの記号を用いたメソッド、後述する例外的なメソッドは括弧を省略しても良い。 正しい例: foo(1, "abc") 誤った例: foo 1, "abc" 例外的なメソッドは以下
例外定義メソッド全体にかかるような例外の場合、beginは省略する 正しい例: def hoge 誤った例: def hoge グローバル変数グローバル変数を利用していると一つの変更の影響反意の想定がつかなくなるため、原則利用しない。 条件分岐if/unless文のthenは省略する正しい例: if x > 0 誤った例: if x > 0 then unless の else はしないunless ↑のようなものは↓のように書いたほうがわかりやすいです。 if よくあるのが当初は unless だけだったのに後で問題があってelseを付け足してしまいこの形になることです。その場合はきちんと ソースを読み、リファクタリングしてください。 .zero?, .nil? 等を利用するRailsのActiveSupport?の機能を活用してください。 正しい例: if x.zero? # x が 0 なら 誤った例: if x == 0 繰り返し
正しい例: while cond 誤った例: while cond do 無限ループ
正しい例: loop {
誤った例: while true 文字列リテラル
do 〜 end と { } の使い分け複数行に処理がまたがる場合は do 〜 end hoge.each do 1行でかけるものは { } を使うようにしましょう。 hoge.each { hoge = 1 }
modelrailsに乗る
→作成時、更新時に自動的に値が更新される acts_as_paranoid は必ず定義するアプリケーション全体として論理削除を基本としているので SQLインジェクションを注意する具体的には以下のように変数を展開する方式は利用しない。 Hoge.find(:all, :conditions => [" id = #{hogehoge} " ])
以下のように必ずパラメータを使うようにする。 Hoge.find(:all, :conditions => [" id = ? ", hogehoge]) hoge.find(:all, :conditions => [" id = params[:hogehoge]", :hogehoge => '1'] また複雑なSQLを手動で組み立てる場合等で上記の方法を使えない場合は必ず個別にサニタイジングをすること。 レコード制約は必ずvalidate定義をするテーブルのNull制約、文字列長制約を適切に設定することは必須だが、値のチェックはvalidate定義で行いテーブル制約任せにせず必ず定義 すること。またvalidate定義を書いていても、アプリケーション以外で値の更新が行われる(コンソール、もしくは他システム)場合に仕様外の値がま ぎれこむことを防ぐため各レコードの制約も適切に行う。 カラム名ルールを統一するカラム名は用途、データ型別の以下のルールに従って付けること
find結果が単数か複数かを考慮してメソッド名をつける単数なら find_hoogehoge_base_user 複数なら find_hogehoge_base_users トランザクション以下の場合は必ずトランザクションを利用し、データベースの整合をとること。
filter利用用途
こんなのには使わないよ!
命名規則
ある権限などが必要なとき xxxx_required 例) #オーナー権限が必要なとき よくない例 access_filter deletable_filter only, except
viewW3C の XHTML 1.0に準拠した正しいHTMLを意識する。具体的には幅をとるためだけに<br/>タグを使う、リスト表示するべきところを<ul>タグを利用しない で<p>タグや<br>タグでそろえるなどは仕様上正しくありません。特にPCで閲覧する画面に関してはSEOの視点、保守性か らも準拠していることは重要です。なお携帯viewの場合利用できるタグに制限があるため、必ずしも準拠することはできませんが、HTMLタグの最適化は やはりSEOに関わるので意識する必要があります。 インデントや見やすさを考慮するcontrollerやmodelでインデントしない人は滅多にいませんが、rhtmlになった途端、意外とおろそかにしがちです。 ロジックをかかなくてもrailsのテンプレートエンジンの構造上 if 文や繰り返しなどはつかわれるため、 きちんとインデントされているかされていないかでも相当、コードを読んだり機能を追加するときに差があります。 viewもコードとみなして最低限の見やすさを考慮してください。 リスト表示をする場合
正しい例: <% if @hoge.size.zero? %> 誤った例: <% if @hoge.size > 0 %> JavaScript?可能な限りjQuery記法を利用する特別の理由がない限り生のJavaScript?のコードを書くことは禁止です。 正しい例: $('#abcd')
誤った例: document.getElementById("abcd");
jsdoc-toolkit形式にそってドキュメントを書く特にutil的な使われ方をするものには必ず記述してください。書式、使い方はjsdoc-toolkitを参照のこと。 参考 |