あなたのC言語コーディング規約

みなさんの回答を読み、「なるほど」と唸りました。

いろいろなのがあるんですね。

わたしが気をつけている事を挙げます。

・システムコールの戻り値は、falseと比較する。
　　→falseは０、trueは非０と教わりました。
　　　ir( true == XXX ) ってやらないようにしています。

・コーディング規約、と言えるかは微妙ですけど、
　手書きでフローチャートを書く。
　　→紙にフローを書ける位なら、後で何とか読めるかな。
　　　ネストが深すぎる関数は、後付けの設計書を書けず、
　　　納品時に困った事があるので。

・どこ行っても「やるな」といわれるので当たり前かも
　しれませんけど、goto は使わない。
　　→goto使うくらいなら、do{ }while(0); でbreakして、
　　　と言われた事があったけど、どっちも微妙。。。

そんな所でしょうか。

そういえば以前、STLを使うなと言われて閉口した事があります。

既約が特にあるわけでないけど自分で特に意識していることで他の方が

あまりあげてないことだけ書きます.
1.変数宣言は値が初めて発生したときに書く.
(忘れやすいので)
2.変数名,メソッド名等なるべく英語のフルスペルで書き省略しない.
英単語は複数を表していても単数形.
(正確に省略するのが難しいので統一が難しい.
人によりぶれがあるのでローマ字なども使用しない)
3.できるだけ小文字を使用し大文字はテンプレート引数やマクロに限定する.
(これは単なる好み.なんとなく見やすい.)
4.private,protectedメンバには前にアンダースコアを付ける.
(publicとの間での変更はあまり無いと思うので)
5.計算途中の値はなるべく変数にする.
int x = 0;
int y = 1;
int z = x + y;
int w = x - y;
int s = z * w;
のように書き一本の式になるべくしない
6.論理的な切れ目に空行・コメントをいれリストを短くするより見やすくなるよう心がける.

■ if文の判定には定数値を右辺に持ってくる

理由：可読性を考慮して。定数値を左辺だと読みにくい

■ なるべくwhile(1)は使用しない
理由：脱出条件が分かりにくく、無限ループに陥る可能性もあるから

■ 変数名は分かる範囲でなるべく短いものにする
理由：好み。コーディングのしやすさから。あと、英単語そのままだと長すぎだから

■ #defineの定数はなるべく使用しない
理由：手軽だから沢山作って分岐とかに色々使う人がいる。その人のコードが非常に分かりにくかったから。あと、安全性の問題で。

■ 関数名は大文字から始める。
理由：可読性考慮。

■ インデントは2。
理由：好み。4だと空き過ぎで読みにくいと感じる。特にif文がいくつか重なると。

まぁ色々ありますが、結構でてるのでこれくらいで

SE の傍ら PG っぽいこともやっている者です。

# 人手不足なもので。。。

私のいるプロジェクトの場合、コーディング規約は必要最低限のことしか決められていないですね。

で、私の場合ですが、こんな感じかなぁ。

●変数名は名詞、関数名は動詞、ブール変数 (TRUE/FALSE) は疑問形にする。
こうすると全体が読みやすくなる(気がする)。

●変数名の先頭に型名をつけない。
型と変数には関連がないことが多く、また全体として読みにくくなることが多い (気がする)。

●整数との比較には switch-case を使用する。
if ( hoge == 1 )
{
…
}
else if ( hoge == 2 )
{
…
}
…

なんてことを書くくらいなら

switch ( hoge )
{
case 1:
…
break;

case 2:
…
break;

…
}

を使用する。

●ブール変数 (TRUE/FALSE) には == TURE や == FALSE をつけない。
なんとなくその方が読みやすい気がする。

if ( enabled )
{
…
}

とか

if ( !enabled )
{
…
}

とかを使う。

●関数の戻り値は極力いったん変数に代入する。
そのほうが読みやすいことが多い。

hoge = do_something();
if ( hoge != -1 )
{
…
}

など。
ただし、こんな場合は仕方ないとあきらめる。

while ( ( hoge = do_something() ) != -1 )
{
…
}


他にもあると思いますが、パッと思いついたのはこんな感じかな。

回答ではないのですが、No.7の方が書かれている奴は結構良いと思います。

そもそもそんな書き方したらまともに動かんだろうってのが多いので、コーディング規約と言えるかは微妙な所ですが。。。

お暇な方は一読を！
https://sec.ipa.go.jp/download/200504eb.php

演算子と変数やリテラル文字列などの間には必ずスペースを入れる

→その値の構成要素を明確に分離する為

関数名と引数との間には必ずスペースを入れる
→処理(関数名)と値を明確に分離する為

Breakは使用しない
→長いループ等で脱出条件が分かりにくくなる為

returnは関数の終わりに1回のみ
→関数の脱出する場所が分かりにくくなる為

インクリメント,デクリメントは使用しない
→2以上の加減算や加減乗除等との記法統一を行い読みやすくする為

省略はしない
→そんな事をしたとするならば私の場合直ぐに間違いを見つけられなくなります

グローバル変数は使わない
→ネーミング衝突を回避する為

staticは必須で無い限り使わない
→過去の値に挙動を左右されるリスクを負わない為

変数は必須の事情が無い限り初期化する
→初期化されていない値に挙動を左右されるリスクを負わない為

他にも沢山の制限を設けているのだとは思うのですが直ぐに思い出せるのはこれ位ですね。

たびたびすみません。

#8では理由を書かなかったので、補足することにします。

1. 可能な限り規格厳密合致プログラムにする。
2. 規格厳密合致が無理な場合、処理系に対する仮定を明確にする。
3. 処理系に依存する部分を分離する。

1.～3.の理由は二つあります。一つは移植性を向上させること。もう一つは、規格厳密合致プログラムを書いたり、厳密合致にできないと判断して別の方法を採用するには、コードの各部の振る舞いが正確に把握できている必要があります。つまり、この規約を守ることで、少なくともコーディングを行った本人の静的検証が同時に行われることになります。

4. 例外安全にする。

これは当たり前のことなので、特に理由を挙げるまでもありませんが、例外安全でなければ信頼性のあるプログラムにはなりません。

5. 可能な限り静的にエラー検出を行う。

動かしてみてからバグを見つけるのではなく、問題のあるコードはコンパイルまたはリンクができないようにすることで、ビルドが通れば大多数のバグを潰せます。C++だけでなく、本来はCでもこのようにすべきなのですが、言語仕様上大したことは期待できません。

全体にいえることとして、言語の仕様や特性を十分に理解していないと守れない規約を設定することで、初級者の参入を拒む目的もあります。初級者が参入すると、どんなに厳格な規約を作ってもまともなプログラムはできませんし、平均以下のスキルではメンテナンスできないようにしておくのも（業者変更されたり、買い叩かれるリスクを軽減する意味で）ビジネス的には重要だったりします。

高度に整った環境で働いている人もいれば、足りないメモリをやりくり

するために言語機能削って苦戦する人もいます。
書いてあることをみれば、どういう環境なのかはわかりますし、環境的
に無理な話もあるでしょうから、お互い「へぇー」くらいの気分でいい
んですよね。

中間データにメモリ変数名を付けてやらないとデバッガで見にくいって
話は私も経験あります。
レジスタに割り当てられちゃうとアセンブラモードにしないと見えない
ので難儀しました。
組み込み系ならよくある話ですよね。

ちなみに私は組み込みでたまにＰＣで、主に６８０００，Ｍ１６Ｃ，
ＳＨ２，Ｈ８，６８０１のマイコン用Ｃソースをいじってます。

○ループはfor()に統一すること
○ループ処理内の最初の行に必ず終了条件を書くこと
私はこれでやってます。

○外部参照する関数、変数のプロトタイプ宣言は必ずexternをつける。
○外部参照しない関数、変数は必ずstaticをつける。
検索時に同じ名前でヒットするとどれが本物かわかりにくいので。

○変数は全て#defineやtypedefで置換したユーザ定義型を使用する。
ＣＰＵが変わるとint=shortだったりchar=unsigned charだったり
して置換作業に困ったので。

○標準ライブラリの関数を各ソースから直接呼ばず置換関数を作る。
上記と同じ問題で、引数の型が変わってしまうために移植すると
型違いのワーニングの嵐になったので、呼び処理を１つのファイル
内に集めてキャストなど対策して、影響を受けるソースを減らして
います。
sprintf()とかはＲＯＭの容量不足でライブラリを実装できないこと
が多いので、%d,%xあたりだけ自作して使うことも多いです。

要点という意味ではNo.8のjactaさんの回答でかなりカバーされてるかと思います。

(書かれていることは私も意識して守ってますし)

質問者さんの意識はもっと細かい個々のコーディングに焦点があるようなので、
もしかすると直接の役には立たないと思われたりするのかもしれませんが、
実際にはそういう細かい書き方とかは些事なので、
あまりこだわると木を見て森が見えないことになりかねません。
程々がよいかと思います。

> そこで、質問です。
> 「あなたの中で決めているコーディング規約は何ですか？」
> 「また、その理由は何ですか？」

正解も無いので、質問というよりはアンケートが妥当かと。

他の方々と同様に、質問者さんが提示されているコーディング規約に対しても少しコメントしておきます。

> □変数名の前には必ず型を現す文字を書く
> 理由：観ただけで型が分かるから。

変数が存在する有効範囲が十分に狭ければ、このような配慮は不要です。
変数名に型情報をつけて便利なのは、関数がやたら長いとか、大域変数を多用した場合であり、それ自体が問題です。
なお、ハンガリアン記法そのものは悪くありません。ただし、某社が流行させた間違った用法ではなく、本来のハンガリアン記法を使うことが重要です。
http://www.radiumsoftware.com/hungarian_notation …

> □関数の復帰値は、一旦必ず変数に代入する。
> 理由：代入しないとデバックがしにくい。

必要に応じて変数に格納する方がよいと思います。
C++なら、無意味な変数を介すことで、コピーコンストラクタや代入演算子が呼ばれることになります。結果として、（例外が送出されるかもしれないので）実行パスを複雑にし、例外安全にするのが難しくなります。

> □if文には、極力「！」(NOT)は使用しない。
> 理由：複数の論理和・積などが入った場合ややこしいので
> 　　　elseで代用する。(真の時の処理はわざと書かない)

真の処理を書かないと、実装漏れとの区別が付きにくいので、個人的には好きではありませんが、そういう書き方もあっていいと思います。ただ、強制すべきものではないように思います。

> □if文の判定には必ず定数値を左辺に持ってくる。
> 理由：if(iData=0)とかの"=="を"="にしてしまうミスを防ぐため。

そういう書き方をしてもよいとは思いますが、直感的ではありませんし、やはり強制すべきではないと思います。
また、==ならまだよいのですが、不等号にまで拡大すると、0 ≦ x ＜ 10を表すには if (0 <= x && x < 10)、その否定には if (x < 0 || 10 <= x) と書いた方が直感的であるにも関わらず、こうした書き方ができなくなります。

> □while(1)は、基本的に使用しない。
> 理由：無限ループに陥らないようにするため。

意図からすると for (;;) も禁止のような気がします。「基本的に」というのがよくわかりませんが、全面禁止であれば、無限ループを作るには goto を使わざるを得ず、組み込みシステムなどでは非常に不便です。