はるっちー的コーディングルール

はるっちー @hal_chi

私的作業中のソースコード掃除だん。

はるっちー @hal_chi

リファクタリングとか呼べる高尚な作業ではないけれど。

はるっちー @hal_chi

個人的なところで、コーディングルールはある程度決めて書くようにしてるので、それに準拠してないものを手直しした。

はるっちー @hal_chi

一応、俺ルールで採用している記述ルールはこんな感じ: クラスはHogeClassのように大文字開始ルール。CとかSとかのプレフィックスは特にいらない。メソッドはhogeMethodのように小文字開始ルール。いずれもアンダースコアを使用しない。

はるっちー @hal_chi

メンバ変数は小文字開始ルール。システムハンガリアンとかマジ勘弁。アプリケーションハンガリアンは同種の変数が多いときに見分けのために適宜使用する。

はるっちー @hal_chi

グローバル変数は処理系にもよるけど、だいたい使わない。必要ならグローバルに参照可能なシングルトンにパッケージングする感じで定義する。グローバルなconstも同様。

はるっちー @hal_chi

ポインタ変数は頭にpを付ける。*は変数側に寄せる派→Type *p;

はるっちー @hal_chi

コメントは処理フローの要点くらいのレベルで簡単でもいいので極力記述しておく。あとで追いかけやすいので。

はるっちー @hal_chi

ある機能を追加するときに、特定の編集箇所が定型的に発生する場合は、コメントで場所を検索可能にしておく。 // <EDIT_HERE> のようにタグを貼る感じでコメントを残す。

はるっちー @hal_chi

先にハコを作って中身の設計や実装を後回しにするときはコメントとして<TBD>か<TODO>を残しておく。デバッグ/単体テスト用のスタブやドライバをコード中に埋め込むときは<DEBUG>のタグを仕込んでおく。

はるっちー @hal_chi

・・・とかそんな感じかなぁ。そんな厳格でもないし、要するにあとでメンテしやすければなんでもいいんだよね。可読性がある程度保たれてれてて、いじり易けりゃどんな方法でも。

はるっちー @hal_chi

あ、お仕事のほうでコーディング規約があったら、当然だけどそれ優先ですよ。当たり前だけど。

はるっちー @hal_chi

ルールではない次元だと、メンバ変数の宣言とか綺麗に並べたくなる。

はるっちー @hal_chi

このあたりの俺ルールは、まず最初にいた会社で厳格なコーディングルールを使う文化があったという環境、ウォーターフローで文書(仕様書)重視主義で開発してたこと、その次の会社で仕様書書かない高速なサイクルでネイティブアプリ開発してたこと、の双方の癖に適応した結果だと思う。

はるっちー @hal_chi

といっても、全然若輩だからなぁ。うわーすげぇとか思うコードはいっぱいあるから、今でもそういうのを見る度に少しずつ手法も変化してるな。

はるっちー @hal_chi

引数チェックして結果がアウトだったらassertで強制終了するように仕込んだ自前のライブラリで自ら引っ掛かったときのやっちまった感はやるせねぇな。

はるっちー @hal_chi

でも、厳密に動くように書くときは、引数チェックに掛かったら落とすようにしないとマズイので挙動としては思惑は正しい。くそう。