-PR-
締切済み

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

  • 暇なときにでも
  • 質問No.2271876
  • 閲覧数1605
  • ありがとう数16
  • 気になる数0
  • 回答数19
  • コメント数0

お礼率 0% (0/19)

勤務先・学校・趣味でC言語を使用してプログラムをしている方の多くは組織内で決めているコーディング規約に沿ってプログラムをしていると思います。
しかし、全てに関して規約化されていることは少なく、ある程度プログラマの裁量に任せていることがあると思います。

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

私が決めているコーディング規約を一例挙げると以下の通りです。
(基本は他人が見ても直ぐに理解できるように心がけてます。)
------
□変数名の前には必ず型を現す文字を書く
理由:観ただけで型が分かるから。
例 :int型は、iData
   char配列は、stData
   ポインタは、pData

□関数の復帰値は、一旦必ず変数に代入する。
理由:代入しないとデバックがしにくい。
例 :iRetCode=func();
   switch(iRetCode){
     case文
   }
   の、ように色んな値を試すときに不便。

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

□if文の判定には必ず定数値を左辺に持ってくる。
理由:if(iData=0)とかの"=="を"="にしてしまうミスを防ぐため。
   (コンパイラによっては、警告が出るものもありますが…)
例 :if(0=iData)など

□while(1)は、基本的に使用しない。
理由:無限ループに陥らないようにするため。
------
通報する
  • 回答数19
  • 気になる
    質問をブックマークします。
    マイページでまとめて確認できます。

回答 (全19件)

  • 回答No.8
レベル14

ベストアンサー率 26% (845/3158)

要点だけを挙げると...

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

これに加えて、C++では、

4. 例外安全にする。
5. 可能な限り静的にエラー検出を行う。

といった感じです。
細かな部分はいろいろありますが、それほど本質的ではありません。


  • 回答No.11
レベル12

ベストアンサー率 53% (331/615)

要点という意味ではNo.8のjactaさんの回答でかなりカバーされてるかと思います。
(書かれていることは私も意識して守ってますし)

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

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

正解も無いので、質問というよりはアンケートが妥当かと。
  • 回答No.7
レベル9

ベストアンサー率 41% (27/65)

最近は コーディング作法ガイド というキーワードで
ググって最初に見つかるやつを使ってます。
  • 回答No.3
レベル5

ベストアンサー率 100% (2/2)

はじめまして。

C++にて開発を行っているものです。
自分の勤めている組織内ではやはり規約化はされていません。
各、PGが独自の規約(?)を作ってやっていますね。

自分は、大体下記のような感じでコーディングをしています。

■変数名
 頭に変数の型をつける。
 int  iData;
char szBuff[16];
char *pIn;
struct stuData strDataRec;
などなど。

■関数名
 fnSubMain()
頭にfnをつけ、関数である事を明示しています。
 また、クラスの使用時は、Onxxxxという形で
 宣言しています。

■ループ
 ループに関しては、時と場合によりです。
 配列の添え字として使用する場合は、forループ
 主体、テーブル内のデータ検索などは、while(1)
 で無限ループを使用し、データ終端でループエンド
 という形です。

■if文の判定には必ず定数値を左辺に持ってくる
 同じく、=防止の為、極力同じようにコーディング
 しています。

■その他
 #defineの羅列がきらいなので、enumをよく
 使用しています。

以上、ご参考になりましたでしょうか。
  • 回答No.1
レベル11

ベストアンサー率 20% (72/359)

組織を移動したとき、方言を矯正させられますが、
その対処方法はお考えですか?
補足コメント
sky9999

お礼率 0% (0/19)

移動の意味を教えてください。
人の異動のことですか?
投稿日時 - 2006-07-12 19:51:41
  • 回答No.2
レベル13

ベストアンサー率 46% (545/1182)

□変数名の前には型を現す文字を書かない
ユーザ定義型は無限であり、対処できない。

□関数の復帰値は、一旦必ず変数に代入しない。
必要に応じて決めることであり、規約にするのはナンセンス。

□if文には、極力「!」(NOT)を使用する。
真のとき空の{}が現れるよりずっとマシ。

□if文の判定には必ず定数値を右辺に持ってくる。
人間の思考順序に合わせないと混乱する。

□while(1)は、積極的に利用する。
無限ループを作りたいならこれが最も楽。

といった意見もあります。
補足コメント
sky9999

お礼率 0% (0/19)

意見は分かりました。
で、あなた自身の規約は無いのですか?
その日の気分で次第でデタラメに書いているのですか?
投稿日時 - 2006-07-12 19:52:20
  • 回答No.12
レベル11

ベストアンサー率 47% (101/213)

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

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

ちなみに私は組み込みでたまにPCで、主に68000,M16C,
SH2,H8,6801のマイコン用Cソースをいじってます。

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

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

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

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

ベストアンサー率 26% (845/3158)

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

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

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

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

必要に応じて変数に格納する方がよいと思います。
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 を使わざるを得ず、組み込みシステムなどでは非常に不便です。
  • 回答No.13
レベル14

ベストアンサー率 26% (845/3158)

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

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

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

4. 例外安全にする。

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

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

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

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

ベストアンサー率 46% (12/26)

回答ではないのですが、No.7の方が書かれている奴は結構良いと思います。
そもそもそんな書き方したらまともに動かんだろうってのが多いので、コーディング規約と言えるかは微妙な所ですが。。。

お暇な方は一読を!
https://sec.ipa.go.jp/download/200504eb.php
19件中 1~10件目を表示
このQ&Aで解決しましたか?
AIエージェント「あい」

こんにちは。AIエージェントの「あい」です。
あなたの悩みに、OKWAVE 3,500万件のQ&Aを分析して最適な回答をご提案します。

関連するQ&A
こんな書き方もあるよ!この情報は知ってる?あなたの知識を教えて!
このQ&Aにはまだコメントがありません。
あなたの思ったこと、知っていることをここにコメントしてみましょう。

その他の関連するQ&A、テーマをキーワードで探す

キーワードでQ&A、テーマを検索する
-PR-

特集


抽選で合計100名様にプレゼント!

ピックアップ

ページ先頭へ