>> ・比較演算子の「>」は使うな
> たとえば
> x > 0 && x < 10 より
> 0 < x && x < 10 のほうがやらせたいことがわかりやすいとかかな
こういう例があれば、どういう事を意図して決めたのかが
わかるので、それが納得できる内容ならそれはそれかなと思います。
結局、私も
「基本的にコーディング規約というのは、「みんなで同じにすると他人のコードが読み
やすいですよ」というものなので、決めごとでしかないなら、上司の言うとおりにす
るというのが私の姿勢です。」
に賛成です。
一人でコードを書く場合と違って、会社ではチームとしてのメンテナンス性を
要求されます。なので、やはりチームのルールとして定められているなら
従うしかないかなと思います。
まあ、皆が納得できるだけの理由を挙げれば一部変更することは可能かもしれませんけど。
> #define DATAMAX (256)
> と、自分は括弧を意図的につける様にしています。
御意。
これってC言語では特に利いてきますよね。
これをやっていなかったばかりに意味不明なバグに悩まされたりする事もありえるので。
C++だとconstで定数化する事が多いので#defineは条件コンパイルの時くらいしか
使いませんけれど。
私個人の考えです。
・if文には必ず｛｝をつけろ
賛成
・マルチステートメントにするな
賛成。
・goto文、continue文は使うな
反対
・比較演算子の「>」は使うな
反対 (というか意味不明)
・ソースコードの右側にコメントを記述するな
基本的に賛成だけど場合によりけり
規則は暗黙的に守ることより、なぜその規則があるかを理解して守る必要があるでしょう。
当然、規則の目的がおかしなものであれば改善すべきだし、必要なら遵守しなければならない
でしょう。
ただ単に規則だからといって強制されていると、その真の目的を忘れておかしなコードを書い
てしまうこともあり得ます。そのためには規則を逸脱する手段が必要でしょう。例えばコード
レビューで承認を得る、等の。こういう逸脱手順なしで規則を運用されると私としてはかなり
息苦しいことになります。
提示されている規則そのものに関しては、
> ・if文には必ず｛｝をつけろ
賛成
> ・マルチステートメントにするな
賛成
> ・goto文、continue文は使うな
基本的には賛成。ただし逸脱してもよい（逸脱手順が必要）
> ・比較演算子の「>」は使うな
どちらでも良い。
# 最初は意味が分からなかった。
> ・ソースコードの右側にコメントを記述するな
反対。（意図が分かれば賛成するかも。）
コメントに関しては余計なコメントは邪魔になるだけなので、なるべくコメントなしで読める
ソースにしろ、と指導しています。（ファイルヘッダ、関数ヘッダは付けます。）
コメントは結果的に嘘になってしまうことがあり（コードを修正してコメントは修正を忘れる）
、人のソースを読む場合、あまりコメントは信用していません。
>それが自分にとっても万人にとっても見やすいと思っています。
そう思っているのはあなただけ。
どんなベテランが書こうが「万人にとっても見やすい」
なんてありえません。
んで私の意見
> ・if文には必ず｛｝をつけろ
賛成。
> ・マルチステートメントにするな
賛成。
> ・goto文、continue文は使うな
gotoは賛成（場合によりけり）
continueは反対
> ・比較演算子の「>」は使うな
反対（というか普通に使う）
> ・ソースコードの右側にコメントを記述するな
どっちでもいいけど私的には賛成
>此処には触れて無さそうだけど…
>>003|#define DATASIZE 8
>>004|#define DATAMAX 256
良く見たら他にも問題のあるマクロもありますね。
>05|#define FileClose(a) if (a!=NULL) { fclose(a);a=NULL; }
>06|#define MemFree(a) if (a!=NULL) { free(a);a=NULL; }
社内で協力しあってソフトを作る以上、規制は必要です。
やはり、Aのほうが見やすいですね。
>・if文には必ず｛｝をつけろ
>・マルチステートメントにするな
>・goto文、continue文は使うな
>・比較演算子の「>」は使うな
>・ソースコードの右側にコメントを記述するな
すみません、
途中で切れたので最初から書きました。
-------------------------------------------------------------
社内で協力しあってソフトを作る以上、規制は必要です。
やはり、Aのほうが見やすいですね。
Ｂだとすぐ分からないですよね。
>・if文には必ず｛｝をつけろ
賛成
if文が幾つも重なった時、分かりにくい。
>・マルチステートメントにするな
賛成
これも、多くなった時分かりにくい。
>・goto文、continue文は使うな
ontinue文は必要だと思う。
goto文は、こうかな。
「goto文は原則的に使ってはいけない。
ただし、必要の場合で開発チームのリーダの了解が
取れた時のみ使用を許可する。」
goto文を使うと意図しない動作になってしまうことが多い。
本人が気づいてなくて問題になることもあると思う。
なれないうちはいやでも周囲の了解を得たほうがいいと思う。
>・比較演算子の「>」は使うな
反対、
ただ一言いうなら、「=」、「==」、「<」と判別で生きるように書く。
かな
>・ソースコードの右側にコメントを記述するな
１行何文字で（印刷、表示か）だと思う。
紙の端までコメントが続いたら見づらいよね。
以上です。
> 私には、自分なりのプログラミングスタイルというものがあり、
> それが自分にとっても万人にとっても見やすいと思っています。
> しかし、会社では私のスタイルは受け入れてもらえず、
ここが既に矛盾してますよね。
あなたのスタイルが万人にとっても見やすいならば、
会社の人たちにとっても見やすいはずでしょ。
会社の人たちも見やすいと感じているのに受け入れられない事情があるなら、
こんなところで意見を聞いても意味が無いし。
他の多くの意見と同様、私もソースコードAの方が読みやすく感じます。
以下はあなたのルールについての私の意見ね。
> ・if文の｛｝は、前後とのバランスなどに応じて、つけたりつけなかったり。
私は、1行だけの場合は{}でくくりませんが、{}を付けるスタイルを
否定するものではない。
> ・似た処理が続く場合は、マルチステートメントにする（特にswitch文のcase処理）。
私も処理eのようなswitchを書くこともあるけど、
処理dや処理gはやりすぎだと思う。
> ・不必要にネストが深くなるのを避けるために、continue文を使う。
これには賛成。でもソースコードAが不必要にネストが深くなっているとは思わない。
これはcontinueの必要性を訴えるほどの例ではないですね。
> ・例外処理を簡潔化するため、場合によってはgoto文も使用。
これもルールとしては賛成だけど、ソースコードAもそれなりに簡潔と思う。
gotoでまとめるにしても、FileClose(a)とMemFree(a)のマクロは無い方がいいと思う。
> ・変数と数値を比較するときは、変数を必ず左側に書く。
反対。『比較演算子の「>」は使うな』と同じくらいナンセンス。
> ・ソースを左側、コメントを右側と分けることで、印刷時の可読性を向上。
これは消極的に反対。印刷時のことはそれこそ環境依存。
どんなプリンタを使っていて、どんな用紙にどんなフォントで何の目的で
印刷するのか分からないので、ここでの議論は無意味だと思うな。
『皆さんはどういうときにどのように印刷してますか？』っていう質問なら別だけど。
コーディングスタイルとしては、一行の文字数が長くなりすぎになるかも、
ということで、消極的に反対。
最後に、戻り値の型がboolなのに、TRUEやFALSEを返しているのはどうかと。
（良く知らんけどC99に準拠？）
皆さん、ご意見ありがとうございました。
まとめると、
「ソースコードAの方が見やすい。ただし、会社規則にも疑問な部分がある」
といったご意見が、多数派のようですね。
でも、ソースコードB、そんなに見ずらいかなぁ…。
「縦に長く書くか、横に詰めて書くか」が大きく違うだけで、
全体的なコード量はほぼ同じなんですけどね…。
スクロールしないと全体を見渡せないよりも、
パッと見はゴチャゴチャ感があっても全体を一望できる方が、
解析する分には好きなんだけどなぁ…。
でもそれが「万人に共通」と思っていたのは、
どうやら自分の思い込みだったみたいで…。
> ・if文には必ず｛｝をつけろ
自分の場合、
「一連のif ～ else if ～ elseの中で、
一つでも｛｝が必要なら、すべて付ける。
そうでなければつけない」
というスタイルを取っています。
基本的にはつけない方がスッキリするので。
でも、「必ず付ける」と徹底した方が、間違いないですね。
> ・マルチステートメントにするな
デバッガで追う時は自分も不便さを感じることがあります。
しかし、処理gのように、引数の違いが目に飛び込んでくるので、
マルチステートメントも捨てがたいんですよね…。
> ・goto文、continue文は使うな
「continue文やgoto文を使うと分かりづらくなる」
という話をよく耳にしますが、それは使い方次第だと思うんですよね。
ソースコードBでは、異常時の処理を「goto ErrEnd」で統一化することで、
「free,fcloseを気にする必要がない」という利点があります。
なのに、会社では「gotoは論外！」と怒られたことがあります。
> ・比較演算子の「>」は使うな
おそらくrinさんのおっしゃる理由で定められたルールだと思います。
でも自分は、変数が左側の方が直観的なんです。
「3 < a」とかを言葉にすると、「3がaより小さかったら」なんてなっちゃうので。
> ・ソースコードの右側にコメントを記述するな
複数人数でプログラミングしてますから、「コメントの書き方も統一しましょう」ってこ
とだと思います。
コメントの文面までルール化されていて、「句読点を使うな」と言われたこともありま
す。
ルールにも、理由があるならいいけど、
理由がない（もしくは理由が間違ってる）ルールは、ほんと、やめてほしいです。
そういえば、別の会社ですが、次のようなルールを定めてる会社もありました。
・数値の値によって分岐する場合は、分岐が4つ以上ならswitch文、4つ未満ならif文を使
え。
・関数の引数は、4つ以内にしろ。それを超える場合は、構造体にして渡せ。
このルールの必要性も、未だ不明です。
あと、defineのカッコについてですが、自分は、
「#define DATA1 8」の場合はカッコを付けませんが、
「#define DATA2 DATA1 - 1」の場合はカッコを付けます。
であれば、問題ないですよね…？
「#define FileClose(a) if (a!=NULL) { fclose(a);a=NULL; }」は、
「#define FileClose(a) do { if (a!=NULL) { fclose(a);a=NULL; } } while
(0)」と
書くべきってことか…。
とりあえず、「会社では会社規則に従う。趣味では自分流」という、
今まで通りのスタンスで行こうと思います。
でも「自分流のスタイルが他の人には見ずらい」ということが分かって、良かったです。
趣味でも、あまり自分流に突っ走りすぎないよう、気を付けます。
皆さん、どうもありがとうございました。
> ・関数の引数は、4つ以内にしろ。それを超える場合は、構造体にして渡せ。
> このルールの必要性も、未だ不明です。
環境が違うとは思いますが、
Windowsパソコンではない別のハードでやってた頃は言われてました。
そのハードの機能上の制限によるものでしたが。
> あと、defineのカッコについてですが、自分は、
> 「#define DATA1 8」の場合はカッコを付けませんが、
> 「#define DATA2 DATA1 - 1」の場合はカッコを付けます。
> であれば、問題ないですよね…？
はい、それならば全く問題はありません。
もう解決しているけど。
僕の意見も。
>でも、ソースコードB、そんなに見ずらいかなぁ…。
これ僕にとってはやり過ぎの部分が多く感じます。(処理a,d,g)
今回の例えではソースコードA(会社の規則スタイル)が見やすいな。
>「縦に長く書くか、横に詰めて書くか」が大きく違うだけで、
>全体的なコード量はほぼ同じなんですけどね…。
上から順に処理を戻らず読めるなら縦長でも良い。
この方が処理を追いやすいから。
ルールについて
>・if文には必ず｛｝をつけろ
賛成(でも if (条件) break(continue); の場合は付けないね)
>・マルチステートメントにするな
賛成(特に宣言時、一括代入など)
>・goto文、continue文は使うな
反対(goto,continue文を使いこなせない人の考えかもね)
>・比較演算子の「>」は使うな
反対(見やすくなるように使い分けが重要)
>・ソースコードの右側にコメントを記述するな
印刷を考慮するなら賛成(桁数の制限のため)
ソースコードなら反対(上手に使えば良いだけ)
こんな感じです。
まにさん、金魚さんの書き込みをみて思ったのですが
>という話をよく耳にしますが、それは使い方次第だと思うんですよね。
>反対(goto,continue文を使いこなせない人の考えかもね)
>反対(見やすくなるように使い分けが重要)
>ソースコードなら反対(上手に使えば良いだけ)
「使い方次第」「使いこなす」「使い分ける」「上手に使う」
これが、ルールの理由なんじゃないかな。
「見やすいソースコード」のためのルールの一部として
「プログラマーの個々の能力やセンスに寄らない、
誰が書いても同じになるように」
ってことが考慮されてるのではないかと
マルチステートメントや、コードの右側コメントなんかも
どのくらいの長さが・・・って
書き手のセンスに頼ってしまう面があると思います
>でも、ソースコードB、そんなに見ずらいかなぁ…。
ソースコードAのほうは、
似たような書き方をネット上やら仕事で見かけるせいもあって
無骨でセンスないけど、見慣れている感があります
ああ、またこの書き方かぁ・・って感じ
返信する
最新の投稿: お久しぶりです、いかがお過ごしでしょうか。 最新のメンバー: gantez 最近の投稿 未読の投稿
