C言語のコーディングチェックリスト

質問

社内教育の一環でC言語の講習を行ないます。

その中でC言語のコーディングを行なう際の
注意点ややるべきでないコーディングスタイルなど
コーダーが自己チェックできるチェックシートを
作成して事前に配布しようと思っています。

特にC言語固有のルールなどがあれば
事前に共有しておきたいのですが、
どういったことを盛り込んだらよいでしょうか。

回答No.3

Interest · ベストアンサー

C言語固有ではないのですが、社内の勉強会向けに作った資料から引っ張り出してきました。参考までにどうぞ。

<< 機能 >>
- 仕様書で規定された機能を満足に実行できるか？
- 未実装の機能はないか？
- 仕様書に無い機能を実装していないか？

<< コメント文 >>
- 自明なコメントが書かれていないか？
- ファイルや関数のヘッダに記入漏れがないか？
- 関数や処理の仕様変更によるコメントの修正漏れがないか？
- 機能追加によるコメントの修正漏れがないか？
- 無責任なコメントが入っていないか？

<< データ宣言 >>
- 全ての変数が宣言されているか？
- デフォルトの属性を知っているか？
- 配列と文字列に適切な初期値をセットしているか？
- 長さ、型、記憶域の種類が正しく与えられているか？
- よく似た同じような名前の変数がないか？

<< データ参照 >>
- 値がセットされていない変数を使っていないか？
- 添え字の値が限界値内にあるか？
- 整数でない添え字を使っていないか？
- ポインタを使った参照で、参照された記憶領域は現在割り当てられているか？
- 別名を使うときに正しい属性を持つか？
- 文字列の限界を超えていないか？
- 索引つきまたは添え字操作で１つずれのエラーがないか？

<< 計算 >>
- 数字でない変数の計算は適切か？
- 混じったモードの計算は？
- 長さの違う変数の計算は？
- 代入された値より少ない長さをもつターゲットでは？
- 中間結果がオーバーフローまたはアンダーフローしていないか？
- ０で割り算していないか？
- 意味を成す範囲を超えた変数値は？
- 演算子の優先度は明確になっているか？
- 整数の割り算の結果は正確か？

<< 比較演算 >>
- 異なるデータ形式（例えば文字列と番地）の比較などしていないか？
- 比較演算子を正しく使っているか？
- 演算子の優先順位を理解しているか？ブール代数式は意図したとおりに- 表現されているか？
- 比較とブール代数表現が混じっていないか？
- コンパイラによるブール代数式の解釈方法を理解しているか？

<< 制御フロー >>
- 反復ループは停止するか？
- ループでの可能な中断が正しく行われるか？
- １つずれの反復回数エラーは？
- 選択肢は全ての場合を考慮できているか？

<< インターフェース >>
- パラメータと引数の属性が一致しているか？
- パラメータと引数の単位系が一致しているか？
- 組み込み関数への引数の数、属性、順序は正しいか？
- 参照しないパラメータを引き渡したりしていないか？
- 入力だけの引数が変更されていないか？
- 大域変数の定義がモジュール間で一致しているか？

<< エラー処理 >>
- 入力の正当性がチェックされているか？
- 入力パラメータ（データ）の取り扱い範囲はすべて考慮されているか？
- エラー時の復旧処理は考慮されれているか？

<< その他 >>
- 他人に上手く説明できない「おまじない処理」が含まれていないか？

【 参考文献 】
Glenford J. Myers著、ソフトウェア・テストの技法、近代科学社、１９８０.

会社にあるソフトウェア開発マニュアルのチェックリストを見たら、ああ、この元ネタは「ソフトウェア・テストの技法」だったのか、と気が付きました。

お礼

まさに私が求めていたものの形です。
> Glenford J. Myers著、ソフトウェア・テストの技法、近代科学社、１９８０
こちらも読ませてもらいます。

どうもありがとうございました。

回答No.2

u-bot

「C言語固有のルール」はあるようでいてかなりいい加減と感じています。
色々な本を読みましたが、独自のルールで書いているものが少ないないです。
少しぐらい邪道な書き方をしてもコンパイラが許してくれるため非常に危ないプログラムを書く人をよく見かけます。
（自分もその一人ですが・・・）

とりあえずC言語の古典と呼ばれる本を参考にしてみてはどうでしょうか？
http://itpro.nikkeibp.co.jp/members/NSW/ITBASIC/20030324/2/?ST=books

お礼

> 非常に危ないプログラムを書く人をよく見かけます。
そうなんですよね、ほんとその通りだと思います。
個人の趣味で作るならそれでもいいんですが、
やはり共同作業で作る場合、方針は決めたいなと
思って悩んでいます。

ご紹介してもらった本は参考にしてみます。

回答No.1

jacta

C言語は、プログラマが間違いをおかさないことが前提となっている言語ですので、「言語仕様を理解しないままコーディングしない」のひとことに尽きます。
あとは現場の都合ですね。

お礼

> 「言語仕様を理解しないままコーディングしない」のひとことに尽きます。

そう、それをセルフチェックできるようにしたいんですよね。
人は無意識に間違いをおかすはずなので。