プログラムのコーディングをする作業って、楽しいですか？辛いですか？
そもそもプログラムができないという人は、想像もできない苦痛でしかないかもしれませんが、プログラマーとして仕事をしている人はおそらく、
「仕事のプログラミングは苦痛だけど、プライベートでのプログラミングは楽しい」
と答える事でしょう。
そしてここでは、プログラミングは、やればやるほど上達するし、今までできなかった事を実現できるような難しい課題にトライする事で、よりハイレベルなプログラミングが構築できるようになり、いわゆる自分がやりたいことができる状態になります。
しかし、僕がプログラミングを趣味でやっていた時代から、会社で行うようになって、会社が上場した事から、大規模開発になる過程で感じたのは、コーディング規約って大事だけど、宗教みたいな思想だと感じてきました。
プログラミングが宗教？？？
これは二人以上で開発（プログラミング）作業を行う時に、必ず何かしらの約束事を作って作業を進めると思いますが、ちゃんとした会社だと、「コーディング規約」として、誰が書いてもわかるようなコードにする事を目的にします。
この時のコーディング規約って、最初に決めた人の好き嫌いで決めることが多いため、後からそのコーディング規約では問題が発生するというような事も起き得るからです。
もちろん、コード規約を作ったエンジニアが会社を退社したとしたらどうでしょう？
残されたエンジニアがその思想を持ったエンジニアがいない中で「何で理不尽な規約を守らなければいけないのか？？？」という不穏な感じになってしまいがちです。
プログラマーとしての上下関係が明確な場合は、上司が決めた規約に準拠すればいいのですが、これってやっぱり規約というなの書き方のお手本なだけであって、「別の書き方の方がいいのに・・・」と感じた瞬間に破綻しがちなんですね。
でも、そんな規約って実はすごく重要で、決め事は決め事、日本国憲法も、何十年経っても国民は守らなければいけないのと同じで、重要なルールという事なんです。
リーダブルコード読んでないエンジニアはまず読んでからこの記事を見よ
コード規約やプログラムコードの書き方を、単なるプログラムとして捉えているプログラマーは、まだまだ未熟で、僕も会社を上場させた経験があるのに、いまだに自分で最適なコーディング規約を見つけきれていません。
でも、最近、会社としてちゃんとプログラムの仕事を受ける事もあり、一人で作業を進めている中で、ある程度のルールが作られてきたので、公開型規約を作っておこうと考えました。
今回のブログ記事から、何回かに分けて、自分流（オレ流）のプログラム規約を掲載してみたいと思います。
手始めに今回はjavascriptの決め事をリストアップしておきます。
オレ流Javascriptコード規約
1. 基本的に全てのコードを無名関数記述で行い、クロージャー構成にする。
;$$func = (function(){
var $$ = function(data){
this.init(data);
};
$$.prototype.init = function(data){
console.log(data);
};
return $$;
})();
jsファイルは、上記の構成でクロージャーでアクセスできるようにして、new宣言で利用するようにする。
1つのファイルで"$$"関数１つにまとめて処理をする。
2. 変数の命名
基本的には英文で説明できる変数名にする。
"data"や"list"などの汎用名称ではなく、"data_accountInfo"や"list_tableTr"などのように、どの部分の情報かを見た目で判別できるようにする。
この際に、"_"アンダースコアとキャメルケース（つなぎ部分を大文字英字）にする区分けは、1つの単語として表す場合は、キャメルケースで、カテゴリや、ベンダープレフィックスなどのような識別子を表す場合は、"_"アンダースコアで繋いでいく。
3. 関数名
変数名と似ているが、コメントを書かなくてもわかりやすい英文で記述するが、ヘッド部分に、return属性を以下のように整える。
set_*** : グローバル変数の変更など、returnがない場合。
get_*** : 任意の値を受け取る場合。
bool_*** : true,falseのどちらかの判定を受け取る場合。
event_*** : イベント処理で受け取り用の関数。
click_*** : クリックイベントでの実行関数。
mouseover_*** : マウスオーバー時のイベント実行関数
mouseout_*** : マウスアウト時のイベント実行関数
mousemove_*** : マウス移動時のイベント実行関数
mousedown_*** : マウスダウン（押下）時のイベント実行関数
resize_*** : windowなどのサイズ変更時のイベント実行関数
※イベント系は、event_をプレフィックスとして、継承してもいい。
ajax_*** : ajax受信時の受け取り用関数。
cb_*** : setTimeoutや、任意関数処理のcallbackの時に受け取る専用。
4. 起動処理
var $$ = function(){
if(document.readyState === "complete"){
this.start();
}
else if(document.readyState === "interactive"){
$$event(window , "DOMContentLoaded" , $$.prototype.start);
}
else{
$$event(window , "load" , $$.prototype.start);
}
}
jsファイルの初回起動時は、上記の記述にして、ページ読み込み完了を判定して処理を実行開始にする処理を行う。
この処理を入れる事で、色々な読み込み処理待ちを確実にwaitすることができる。
ただし、ajaxなどでのloadが発生する場合は、この範囲ではない。
この後の起動は"$$.prototype.start"に統一する事でjs実行開始を統一化させる。
5. コメント記述
関数コメントは、その関数の概要（必要があれば詳細）、returnと受け渡し値のそれぞれの"type","コメント",必要があれば、サンプルを記述する。
6. エレメント選択
getElementByIdとquerySelector,querySelectorAllの３種類を使用して、それ以外の取得プロパティは利用しない。
全てselector系で統一する方が良し。
この際、めちゃ古ブラウザは対象外とする。
7. callback系の受け渡し関数は、クロージャー継承できるようにする。
下記の記述で統一する。
setTimeout((function(e){hoge(e)}).bind(this) , 1000);
(function(){}).bind(this)を記述徹底することで、クロージャーから外れないようにする。
8. 関数の深度
$$.prototype.***というクロージャー関数を多階層にすると、クロージャー継承しづらくなるので、全て1階層での関数で徹底する。
どうしてもグループ化したい場合は、プレフィックス命名して行う。
9. 三項演算子の利用について
基本的に、多重三項演算は禁止。
１行でのtrue、false判定や、単純な値取得振り分けの場合のみ利用することが可能。
10. if文とswitch文の使い分け
単純な文字列値判定での振り分けはswitchとして、それ以外の複雑になる場合はif文で行う。
switchで複雑な分岐判定処理を行うことは禁止。
11. for文とwhile文の使い分け
基本的に
for(var i=0; i<hoge .length; i++){...}
の記述で行うが、内部判定でどうしてもwhileが効率いい場合は使用しても良い。
ただし、無限ループが起こり得るリスクがあるので、内部変数は徹底管理すること。
また、foreachは、IE8以前が利用できないので、ほぼ考えなくてもいいが、なるべくなら使わない方がトラブル回避になる。
12. cssとの区分け
アニメーションはできる限りCSSで行う。
JSでは、処理を判定して、属性値の切り替えを行う。
style.setPropertyを使わずにできる限り属性値での処理にする。
querySelectorの記述はcss設計ルールと連動すること。
13. HTML読み込み仕様を考える。
HTMLに貼り付けるjavascriptタグは、基本的にヘッダ部分記述とする。
onloadイベントで全ての動作が起動するようにすることでエラーが起きない仕組みを徹底する。
順位が入れ替わっても起動できるように仕様検討をする。
14. returnルール
基本的に関数には全てreturnを設置する。
関数処理の成功、失敗を明確にする。
15. consoleルール
デバッグコンソールへの記述は、error,message関数を作って、対象のプログラムのプレフィックスを統一して明示する。
16. 旧ブラウザ対応について
クライアント意向も発生する案件もあるが、基本的にはできる限りのブラウザで動作する事を意識してコーディングする事。
わざわざ新しい記述をしなければ、どんなに古いブラウザ、ゲーム端末などのPC以外でのブラウザなどで動作することも可能になる。
17. ヘッダコメント
コードファイル毎に、下記内容を記述する。
- Summary
- Author
- Write(date)
- Use-sample
あくまで自分の為（自社）の規約なので、他の人は何も気にせずプログラミングしてください。
この資料は、うちの会社でプログラマーを採用した時に読んでいただく記事になります。
0 件のコメント:
コメントを投稿