回答編集履歴
2
スペルミス修正
answer
CHANGED
|
@@ -17,7 +17,7 @@
|
|
|
17
17
|
追記です。
|
|
18
18
|
|
|
19
19
|
以下自分で実践している主な規約(?)です。
|
|
20
|
-
- 外部公開のクラス・メソッド等には
|
|
20
|
+
- 外部公開のクラス・メソッド等にはDoxygen形式でコメントを書く
|
|
21
21
|
- それ以外も処理内容が判るように適度にコメントを書く（数か月後に見直したときに思い出せるように）
|
|
22
22
|
- シンボル名をあまり省略しすぎない
|
|
23
23
|
- 命名規則でいくつかのプリフィックスを決めている（m:メンバ変数、g:グローバル変数、i:入力引数、o:出力引数、等）
|
1
規約\(\?\)追記
answer
CHANGED
|
@@ -12,4 +12,28 @@
|
|
|
12
12
|
基本4文字のハードタブです。これは重要なのでプロジェクト開始時には規約に入れてメンバーに周知させ、エディターの設定などを確認します。
|
|
13
13
|
|
|
14
14
|
コーディング「スタイル」に関しては、あまり細かく規定して「規約」に盛り込むと、それこそ宗教戦争的な流れになってしまうので、そうしなければ困るということ以外は個人の裁量に任せた方がいいような気がします。有名なところが出しているコーディング規約は、参考にすることはありますが従う気にはなれません。
|
|
15
|
-
T.Kannoさんのご指摘のように命名規則やコメントの充実などを決めた方が良いでしょう。あるいはエラーの伝達方法とか。
|
|
15
|
+
T.Kannoさんのご指摘のように命名規則やコメントの充実などを決めた方が良いでしょう。あるいはエラーの伝達方法とか。
|
|
16
|
+
---
|
|
17
|
+
追記です。
|
|
18
|
+
|
|
19
|
+
以下自分で実践している主な規約(?)です。
|
|
20
|
+
- 外部公開のクラス・メソッド等にはDokygen形式でコメントを書く
|
|
21
|
+
- それ以外も処理内容が判るように適度にコメントを書く（数か月後に見直したときに思い出せるように）
|
|
22
|
+
- シンボル名をあまり省略しすぎない
|
|
23
|
+
- 命名規則でいくつかのプリフィックスを決めている（m:メンバ変数、g:グローバル変数、i:入力引数、o:出力引数、等）
|
|
24
|
+
- #defineでなければ実現できない場合を除いて定数定義は列挙子かconst値を使う
|
|
25
|
+
- 1行はだいたい130桁程度まで（昔プリンターに出していたときの名残。今ではこれがエディターでもちょうど良い長さ）
|
|
26
|
+
- 1行が長すぎて途中で改行する場合は行頭が演算子で始まるようにする（前の行の続きだと即座に判るように）
|
|
27
|
+
- 1行に複数の文を記述しない（デバッガーのステップ実行が行単位なので）
|
|
28
|
+
- 一項演算子はくっつけて二項演算子は前後に空白を入れる（ただし読みやすさを考えてくっつけることもある）
|
|
29
|
+
- 演算子の優先順位が誤解を招きそうな場合は括弧で明確にする（*(p++), x = (a << 1) + 1等）
|
|
30
|
+
- ifやforなどと括弧の間に空白は挟まない
|
|
31
|
+
- do～whileのwhileはブロック閉じ括弧と同じ行に書く
|
|
32
|
+
- switch文のcaseはswitchと同じインデント位置
|
|
33
|
+
- ブール値の条件判定では等号・不等号を使わない（if(flag == false)ではなくif(!flag)とする）
|
|
34
|
+
- gotoを使う前に本当に必要なのかをよく考える（少なくとも21世紀に入ってから使った記憶はない）
|
|
35
|
+
- 同じような記述（関数呼び出しとか変数設定とか）が何行も続くときはなんとなく桁位置をそろえる
|
|
36
|
+
- ファイル終端は改行で終わらせる
|
|
37
|
+
- フレームワークなどを使わない場合はエラー処理やデバッグの仕組みを先に決める（業務でも重要ですね）
|
|
38
|
+
|
|
39
|
+
結構ありますね。ガチガチですね。
|