catsforepaw score 5796
2015/11/13 07:49 投稿
| > ①if の条件式で定数は右辺？左辺？ |
| 右辺派です。 |
| 今時のコンパイラなら警告レベルを適切に設定すれば、if文の条件式が代入文になっていると警告を発してくれます。その他見落としがちなミスを指摘してくれたりするので、プロジェクト開始時には必ずコンパイルオプションを確認しましょう。VC++なら警告レベル4に上げましょう。 |
| また、==ならまだしも、不等号でも定数を左辺にするという記述をたまに見かけますが、非常に読みづらいのでコードレビューなどでそのような記述をしているのを見かけたら、私なら訂正させます。 |
| > ②if, for, switch, whileの中括弧はifと同じ行？次の行？？ |
| 自分でコードを書く場合は改行してブロックの開始と終了のインデント位置をそろえますね。左側だけ見ていればプログラムの構造が把握できますから。それと、{を行末にすると、特にfor文でそうなりがちですが、条件式が長くなって改行したときに、条件式なのかブロック内の処理なのか見分けがつきにくくなります。 |
| あとは、行単位にすると編集がしやすいということもありますね。ブロックを丸ごとカット＆ペーストするというときなど。 |
| ただし、他人のコードを修正するようなときはそっちに合わせます。 |
| > ③インデントはタブ派？スペース派？ |
| 基本4文字のハードタブです。これは重要なのでプロジェクト開始時には規約に入れてメンバーに周知させ、エディターの設定などを確認します。 |
| コーディング「スタイル」に関しては、あまり細かく規定して「規約」に盛り込むと、それこそ宗教戦争的な流れになってしまうので、そうしなければ困るということ以外は個人の裁量に任せた方がいいような気がします。有名なところが出しているコーディング規約は、参考にすることはありますが従う気にはなれません。 |
| T.Kannoさんのご指摘のように命名規則やコメントの充実などを決めた方が良いでしょう。あるいはエラーの伝達方法とか。 |
| --- |
| 追記です。 |
| 以下自分で実践している主な規約(?)です。 |
| - 外部公開のクラス・メソッド等にはDokygen形式でコメントを書く |
| - 外部公開のクラス・メソッド等にはDoxygen形式でコメントを書く |
| - それ以外も処理内容が判るように適度にコメントを書く（数か月後に見直したときに思い出せるように） |
| - シンボル名をあまり省略しすぎない |
| - 命名規則でいくつかのプリフィックスを決めている（m:メンバ変数、g:グローバル変数、i:入力引数、o:出力引数、等） |
| - #defineでなければ実現できない場合を除いて定数定義は列挙子かconst値を使う |
| - 1行はだいたい130桁程度まで（昔プリンターに出していたときの名残。今ではこれがエディターでもちょうど良い長さ） |
| - 1行が長すぎて途中で改行する場合は行頭が演算子で始まるようにする（前の行の続きだと即座に判るように） |
| - 1行に複数の文を記述しない（デバッガーのステップ実行が行単位なので） |
| - 一項演算子はくっつけて二項演算子は前後に空白を入れる（ただし読みやすさを考えてくっつけることもある） |
| - 演算子の優先順位が誤解を招きそうな場合は括弧で明確にする（*(p++), x = (a << 1) + 1等） |
| - ifやforなどと括弧の間に空白は挟まない |
| - do～whileのwhileはブロック閉じ括弧と同じ行に書く |
| - switch文のcaseはswitchと同じインデント位置 |
| - ブール値の条件判定では等号・不等号を使わない（if(flag == false)ではなくif(!flag)とする） |
| - gotoを使う前に本当に必要なのかをよく考える（少なくとも21世紀に入ってから使った記憶はない） |
| - 同じような記述（関数呼び出しとか変数設定とか）が何行も続くときはなんとなく桁位置をそろえる |
| - ファイル終端は改行で終わらせる |
| - フレームワークなどを使わない場合はエラー処理やデバッグの仕組みを先に決める（業務でも重要ですね） |
| 結構ありますね。ガチガチですね。 |
catsforepaw score 5796
2015/11/13 07:48 投稿
| > ①if の条件式で定数は右辺？左辺？ |
| 右辺派です。 |
| 今時のコンパイラなら警告レベルを適切に設定すれば、if文の条件式が代入文になっていると警告を発してくれます。その他見落としがちなミスを指摘してくれたりするので、プロジェクト開始時には必ずコンパイルオプションを確認しましょう。VC++なら警告レベル4に上げましょう。 |
| また、==ならまだしも、不等号でも定数を左辺にするという記述をたまに見かけますが、非常に読みづらいのでコードレビューなどでそのような記述をしているのを見かけたら、私なら訂正させます。 |
| > ②if, for, switch, whileの中括弧はifと同じ行？次の行？？ |
| 自分でコードを書く場合は改行してブロックの開始と終了のインデント位置をそろえますね。左側だけ見ていればプログラムの構造が把握できますから。それと、{を行末にすると、特にfor文でそうなりがちですが、条件式が長くなって改行したときに、条件式なのかブロック内の処理なのか見分けがつきにくくなります。 |
| あとは、行単位にすると編集がしやすいということもありますね。ブロックを丸ごとカット＆ペーストするというときなど。 |
| ただし、他人のコードを修正するようなときはそっちに合わせます。 |
| > ③インデントはタブ派？スペース派？ |
| 基本4文字のハードタブです。これは重要なのでプロジェクト開始時には規約に入れてメンバーに周知させ、エディターの設定などを確認します。 |
| コーディング「スタイル」に関しては、あまり細かく規定して「規約」に盛り込むと、それこそ宗教戦争的な流れになってしまうので、そうしなければ困るということ以外は個人の裁量に任せた方がいいような気がします。有名なところが出しているコーディング規約は、参考にすることはありますが従う気にはなれません。 |
| T.Kannoさんのご指摘のように命名規則やコメントの充実などを決めた方が良いでしょう。あるいはエラーの伝達方法とか。 |
| T.Kannoさんのご指摘のように命名規則やコメントの充実などを決めた方が良いでしょう。あるいはエラーの伝達方法とか。 |
| --- |
| 追記です。 |
| 以下自分で実践している主な規約(?)です。 |
| - 外部公開のクラス・メソッド等にはDokygen形式でコメントを書く |
| - それ以外も処理内容が判るように適度にコメントを書く（数か月後に見直したときに思い出せるように） |
| - シンボル名をあまり省略しすぎない |
| - 命名規則でいくつかのプリフィックスを決めている（m:メンバ変数、g:グローバル変数、i:入力引数、o:出力引数、等） |
| - #defineでなければ実現できない場合を除いて定数定義は列挙子かconst値を使う |
| - 1行はだいたい130桁程度まで（昔プリンターに出していたときの名残。今ではこれがエディターでもちょうど良い長さ） |
| - 1行が長すぎて途中で改行する場合は行頭が演算子で始まるようにする（前の行の続きだと即座に判るように） |
| - 1行に複数の文を記述しない（デバッガーのステップ実行が行単位なので） |
| - 一項演算子はくっつけて二項演算子は前後に空白を入れる（ただし読みやすさを考えてくっつけることもある） |
| - 演算子の優先順位が誤解を招きそうな場合は括弧で明確にする（*(p++), x = (a << 1) + 1等） |
| - ifやforなどと括弧の間に空白は挟まない |
| - do～whileのwhileはブロック閉じ括弧と同じ行に書く |
| - switch文のcaseはswitchと同じインデント位置 |
| - ブール値の条件判定では等号・不等号を使わない（if(flag == false)ではなくif(!flag)とする） |
| - gotoを使う前に本当に必要なのかをよく考える（少なくとも21世紀に入ってから使った記憶はない） |
| - 同じような記述（関数呼び出しとか変数設定とか）が何行も続くときはなんとなく桁位置をそろえる |
| - ファイル終端は改行で終わらせる |
| - フレームワークなどを使わない場合はエラー処理やデバッグの仕組みを先に決める（業務でも重要ですね） |
| 結構ありますね。ガチガチですね。 |
