Coding Guide

コーディング作法ガイド 0.8 ドラフト版

組込みソフトウェア用Ｃ言語

コーディング作法ガイド
(0.8 ドラフト版)

2005 年 3 月

経済産業省組込みソフトウェア開発力強化推進委員会
独立行政法人情報処理推進機構ソフトウェア・エンジニアリングセンター

1


コーディング作法ガイド発行にあたって

近年，組込みソフトウェアの規模は拡大の一途を辿り，多人数による開発形態に移行しています。小規模であった頃は
ハードウェア・ソフトウェアを共に熟知した少人数の開発者により開発が進められ，スキルレベルの統一は容易でした。しかし，
開発者数の増大と共に様々なスキルレベルの開発者が参画するようになり，スキルレベルの統一のための施策が今まで以
上に必要となっています。特に，安全性，保守性及び移植性を考慮した高品質なＣ言語のコーディングは，組込みソフ
トウェア開発の中で基礎体力と位置付けられるものと考えます。

高品質なＣ言語コーディングのためには，開発者の暗黙の了解でコードを記述するのではなく，コーディング規約を形式
知として定め，規約に基づいてコードを記述することが有効と考えます。しかし，コーディング規約を制定するためには，Ｃ言
語の文法に精通している必要があることなど，高いスキルと多大な労力が必要です。また，開発者への理解を深め，普及・
徹底を図ることに大きな障壁があることも事実です。

このような背景から経済産業省組込みソフトウェア開発力強化推進委員会では，産官学連携の取組みの一環として，
Ｃ言語のコーディング規約を策定している方を対象にした「コーディング作法ガイド」を編纂することにしました。編纂に当って
は，プログラミング技法に精通した有識者から構成されるコーディング作法ワーキンググループを発足し，原案を定め，品質
向上技術部会で詳細を審議する方法で策定しました。本書は，品質特性に対応して分類した作法と，それに対応するル
ール群から構成されています。コーディング規約を策定する方は，ルール群の中から必要部分を取捨選択することにより，目
的に見合ったコーディング規約を策定することが出来ると考えます。

本書は，コーディング規約策定者はもとより，開発のベテランの方には，Ｃ言語の持つ特性を俯瞰し，新たな気づきのきっ
かけとなり，初心者の方には，過去の先人が築いたノウハウを体得できる実践的な教科書として，利用していただくことがで
きると確信しています。是非とも，本書を有効に活用いただくことにより，組込みソフトウェアの生産性の向上及び高品質
なソフトウェア開発を実現していただくことを願ってやみません。

2005 年 3 月
組込みソフトウェア開発力強化推進委員会
品質向上技術部会

2


目次
1. はじめに.............................................................................................................................. 4
1.1 背景 ....................................................................................................................................................4
1.2 本ガイドの対象者..................................................................................................................................4
1.3 本ガイドの特徴 .....................................................................................................................................4
1.4 ルールの対象範囲..................................................................................................................................5
1.5 用語，略語 ..........................................................................................................................................5
2. 品質特性と作法 ................................................................................................................. 6
2.1 品質特性.............................................................................................................................................6
2.2 品質特性と作法，ルール.........................................................................................................................8
3. 本ガイドの利用方法............................................................................................................. 9
3.1 新規コーディング規約の作成 ...................................................................................................................9
3.2 既存コーディング規約の充実 .................................................................................................................10
3.3 プログラマの研修，独習のための学習教材 ...............................................................................................10
4. 作法とルールリファレンス....................................................................................................... 11
4.1 表の見方と用語 ................................................................................................................................... 11
4.1.1 表の見方......................................................................................................................................... 11
4.1.2 表中の用語 .....................................................................................................................................12
4.2 作法とルールリファレンス.........................................................................................................................13
4.3 ルール定義への指針.............................................................................................................................48
付録A 作法・ルール一覧 ........................................................................................................ 56

付録B ルールクロスリファレンス.................................................................................................. 64

付録C 処理系定義文書化テンプレート .................................................................................... 65

引用・参考文献

3


1. はじめに
本書は，企業やプロジェクトでコーディング規約を作成・運用する人に対して，コーディング規約作成の支援を目的とした
コーディング作法ガイドです。本ガイドの特徴は，コーディング規約を『品質を保つために守るべきコードの書き方』と考え，ル
ールの基本概念を作法としてまとめたことです。作法は『JIS X 0129-1 ソフトウェア製品の品質第１部：品質モデル』に
準拠した品質概念を基に，作法概要，作法詳細に分類・階層化しています。さらに，それぞれの作法にＣ言語に対応した
ルールをその必要性とともに提示しています。この作法とルールにより，意義・必要性を理解できる，実用的な「コーディング
規約」が容易に作成できることを目標としています。

1.1 背景
コーディング規約は，コードの品質を向上させるために重要なツールです。しかしながら，経済産業省の 2004 年版『組込
みソフトウェア産業実態調査』及び組み込みソフト開発力強化委員会品質向上技術部会の『メンバ企業ヒアリング』
では，次のような課題が浮かび上がっています。

1. コーディング規約が存在しない。
※ 『組込みソフトウェア産業実態調査』によれば，約半数がコーディング規約が存在しないと回答しています。
2. ルールの必要性が理解されない。または，ルール違反に対する正しい対処方法が理解されていない。
3. ルールが多すぎると覚えきれないが，少ないとカバー範囲が不足する。
4. 精度よく検証できるツールがなく，検証をレビューに頼っているので負担が大きい。
5. コーディング規約が形骸化している。

本ガイドでは，これらの問題の中で，1 と 2 に対して一つの解を提供しています。

1.2 本ガイドの対象者
本ガイドが想定している対象者と利用方法および期待効果を示します。

1. コーディング規約を作成する人
本ガイドにより，容易に新規のコーディング規約が作成できます。または既にあるコーディング規約の確認，整理がで
きます。
2. プログラマやプログラムレビューをする人
本ガイドの作法・ルールを理解・修得することによって，信頼性の高い，保守しやすいコードの作成が無理なくできるよ
うになります。

1.3 本ガイドの特徴
(1) 体系化された作法・ルール
本ガイドでは，ソフトウェアの品質同様，コードの品質も，「信頼性」，「保守性」，「移植性」などの品質特性で分類でき
ると考え，ルールの基本概念を示す作法を『JIS X 0129-1』を基に体系化しています。ルールについては，世の中に存在す
る多くのコーディング規約を十分に吟味し，作法と対応させる形でコードの品質という観点から体系化し，現在の状況（言
語仕様や処理系の実情）にあわせて取捨選択しました。個々の作法・ルールを品質特性で分類することで，どの品質を保
つことを主たる目的としているのか理解できるようしています。
なお，本ガイドが参照したコーディング規約として，WG メンバ会社のコーディング規約， "MISRA-C"， "Indian Hill C
Style and Coding Standards"，"GNU coding standards" 等があります。詳細は巻末「引用・参考文献」をご参照くださ
い。

4


(2) すぐに使えるルールリファレンス
本ガイドで示すルールは，そのまま規約に利用できるよう作成されています。３章「本ガイドの利用方法」を参考に，規約
を作る人が必要と考えるルールを取捨選択し，その上で足りないルールを追加することで，C 言語のコーディング規約を容易
に作成することが可能です。

(3) ルールの必要性を提示
本ガイドでは，ルールの必要性を作法の表現，ルール自体の中，及び C 言語における注意事項で提示しています。プロ
グラマは，この作法と注意事項を参考に，ルールの必要性を自ら理解し身に付けることができます。ルールの多くは，熟練し
たプログラマであればすでに知識として獲得しているコーディング時の注意事項に対応します。

(4) 他のコーディング規約との対応関係を明示
本ガイドでは，各ルールについて，世の中で使われているコーディング規約との対応関係を示しています。それによって，包
含関係などを確認しやすくしています。対応を示しているコーディング規約としては， "MISRA-C"， "Indian Hill C Style
and Coding Standards"があります。

1.4 ルールの対象範囲

本ガイドでは，次に関するルールは，C 言語のリファレンスルールの対象外としています。
・ライブラリ関数
・メトリクス（関数の行数・複雑度など）

1.5 用語，略語
本ガイドでは，以下の用語と略語を使用しています。
・作法ソースコードの品質を保つための慣習，実装の考え方であり，個々のルールの基本概念を示す。
・ルール守らなければならない，具体的な一つ一つの決め事。本ガイドでは複数のルールもルールと呼ぶことが
ある。
・規約ある目的を持って集められた，ルールの集合。
・引用このガイド中で，原文献の中の表現をそのまま(意訳を含む)使用すること。
・参考文献このガイドを作成する上で，参考にした文献。
・ C90 「JIS X 3010:1996 プログラム言語 C」で規定される C 言語規格のこと。「JIS X 3010:1993 プログラ
ム言語 C」が 1996 年に追補・訂正されたものである。翻訳元の ISO/IEC 9899:1990 が 1990 年に
発行されたため，「C90」と呼ぶことが多い。なお，C 言語規格はすでに改正され C99 となっており，C90
は旧規格である。しかしながら，現状世の中に普及している規格がまだ C90 であること，また，改版に
よる機能追加は多くはないことなどから，本ガイドでは，対象とする言語規格とし C90 を採用している。
・ C99 「JIS X 3010:2003 プログラム言語 C」で規定される C 言語規格のこと。C 言語の現在の規格である。
翻訳元の ISO/IEC 9899:1999 が 1999 年に発行されたため，「C99」と呼ぶことが多い。
・ C++ 「JIS X 3014:2003 プログラム言語 C++」で規定される C++言語規格のこと。
・ MISRA-C MISRA-C:1998 及び MISRA-C:2004 のこと
・ MISRA-C:1998 英国 The Motor Industry Software Reliability Association(MISRA)によって定められた，引
用・参考文献[5]の規約のこと。
・ MISRA-C:2004 英国 MISRA によって定められた，引用・参考文献[6]の規約のこと。MISRA-C:1998 の改訂版で
ある。

5


2. 品質特性と作法
2.1 品質特性
本ガイドでは，品質を保つコードを書くために守るべき作法・ルールの着眼点として JIS X 0129-1 の「主品質特性」を
参考にしています。JIS X 0129-1 の「主品質特性」は，次の６つの特性で構成されています。
1.信頼性 2.保守性 3.移植性 4.効率性 5.機能性 6.使用性
このうち，「機能性」，「使用性」の２特性については，より上流の設計段階以前に作りこむべき特性と考え，「信頼性」，
「保守性」，｢移植性｣及び「効率性」の４特性を作法の大分類として採用しています。表１に，JIS X 0129-1 の「主品質
特性」と本ガイドが考える「コードの品質」の関係を，「品質副特性」と共に示します。

表 1 ソフトウェアの品質特性とコードの品質

品質特性（JIS X0129-1）品質副特性（JIS X0129-1）コードの品質

成熟性ソフトウェアに潜在する障害の結果として生じ使い込んだときのバグの少なさ。
る故障を回避するソフトウェア製品の能力。
指定された条件下で利用障害許容性ソフトウェアの障害部分を実行した場合，またバグやインターフェース違反などに対
信は仕様化されたインタフェース条件に違反がする許容性。
するとき，指定された達成
頼発生した場合に，指定された達成水準を維
水準を維持するソフトウェ
性持するソフトウェア製品の能力。
ア製品の能力。
回復性故障時に指定された達成水準を再確立し，
直接に影響を受けたデータを回復するソフト
ウェアの能力。
信頼性標準信頼性に関連する規格または規約を遵守す
適合性るソフトウェア製品の能力。
解析性ソフトウェアにある欠陥の診断または故障の原コードの理解しやすさ。
因の追求，及びソフトウェアの修正箇所の識
別を行うためのソフトウェア製品の能力。
変更性指定された修正を行うことができるソフトウェアコードの修正しやすさ。
製品の能力。
保
修正のしやすさに関するソ安定性ソフトウェアの修正による，予期せぬ影響を避修正による影響の少なさ。
守
フトウェア製品の能力。けるソフトウェア製品の能力。
性
試験性修正したソフトウェアの妥当性確認ができるソ修正したコードのテスト，デバッグのし
フトウェア製品の能力。やすさ。
保守性標準保守性に関連する規格または規約を遵守す
環境適応性ソフトウェアにあらかじめ用意された以外の付異なる環境への適応のしやすさ。
加的な作法または手段なしに，指定された ※ 標準規格への適合性も含む。
異なる環境にソフトウェアを適応させるための
ソフトウェア製品の能力。
設置性指定された環境に設置するためのソフトウェア
の能力。
移ある環境から他の環境に
共存性共通の資源を共有する共通の環境の中で，
植移すためのソフトウェア製品
他の独立したソフトウェアと共存するためのソフ
性の能力。
トウェア製品の能力。
置換性同じ環境で，同じ目的のために，他の指定さ
れたソフトウェア製品から置き換えて使用する
ことができるソフトウェア製品の能力。
移植性標準移植性に関連する規格または規約を遵守す

6


品質特性（JIS X0129-1）品質副特性（JIS X0129-1）コードの品質

時間効率性明示的な条件の下で，ソフトウェアの機能を処理時間に関する効率性。
実行する際の，適切な応答時間，処理時
間及び処理能力を提供するソフトウェア製
明示的な条件の下で，使品の能力。
効
用する資源の量に対比し資源効率性明示的な条件の下で，ソフトウェア機能を実資源に関する効率性。
率
て適切な性能を提供する行する際の，資源の量及び資源の種類を
性
ソフトウェア製品の能力。適切に使用するソフトウェア製品の能力。
効率性標準効率性に関連する規格または規約を遵守す
合目的性指定された作業及び利用者の具体目標に
対して適切な機能の集合を提供するソフトウ
ェア製品の能力。
正確性必要とされる精度で，正しい結果若しくは正
しい効果，又は同意できる結果若しくは同意
できる効果をもたらすソフトウェア製品の能
力。
ソフトウェアが，指定された
相互運用性一つ以上の指定されたシステムと相互作用す
条件の下で利用されるとき
機るソフトウェア製品の能力。
に，明示的及び暗示的
能
必要性に合致する機能をセキュリティ許可されていない人又はシステムが情報又は
性
提供するソフトウェア製品データを読んだり，修正したりすることができな
の能力。いように，及び許可された人又はシステムが
情報又はデータへのアクセスを拒否されないよ
うに，情報又はデータを保護するソフトウェア
製品の能力（JIS X 0160:1996）。
機能性標準機能性に関連する規格，規約又は法律上
適合性及び類似の法規上の規則を遵守するソフト
ウェア製品の能力。
理解性ソフトウェアが特定の作業に特定の利用条件
で適用できるかどうか，及びどのように利用で
きるかを利用者が理解できるソフトウェア製品
の能力。
習得性ソフトウェアの適用を利用者が習得できるソフ
指定された条件の下で利
使トウェア製品の能力。
用用するとき，理解，習得，
性利用でき，利用者にとって運用性利用者がソフトウェアの運用及び運用管理
魅力的であるソフトウェアを行うことができるソフトウェア製品の能力。
製品の能力。魅力性利用者にとって魅力的であるためのソフトウェ
ア製品の能力。
使用性標準使用性に関連する規格，規約，スタイルガイ
適合性ド又は規則を遵守するソフトウェア製品の能
力。

7


2.2 品質特性と作法，ルール
本ガイドでは，作法，ルールを 2.1 に示した４つの品質特性に関連づけて分類・整理しています。本ガイドにおける作法，
ルールの意味は次のとおりです（図 1 参照）。
・作法ソースコードの品質を保つための慣習，実装の考え方であり，個々のルールの基本概念を示す。作法概要，
作法詳細に階層化して示している。
・ルール守らなければならない，具体的な一つ一つの決め事であり，コーディング規約を構成する。本ガイドではリファレ
ンスとして示している。なお，ルールの集まりもルールと呼ぶことがある。
作法，ルールの多くは，複数の品質特性と関連しますが，最も関連の強い特性に分類しています。品質特性と関連づける
ことにより，各作法がどのような品質に強く影響するかを理解できるようにしています。

品コード品質向
質上の着眼点信頼性保守性移植性効率性
概 (JIS X0129-1)
念
品質向上のたプログラムは明示的
作めに守るべきに記述する
法具体的な実装言語独立
動作が保証された意味的がわかりやすい移植を意識した
の考え方記述を行う記述をする記述をする
（一部依存）
リファレンスとして提供
浮動小数点変数は厳密な等式、式の値は、規格が認めるどのような順序で
言語依存性を非等式のテストをしてはならない評価されようとも同じでなければならない言語依存
ル考慮した具体
ー的なコーディ単項演算子‘-’ は符号なしの隠蔽されている浮動小数点のビット表現は、
式に適用してはならないプログラマは、いかなる方法でも使用してはならない
ルングルールの
リファレンスより大きなデータ型の一部分にアクセスする
ために共用体を使用してはならない

作法ガイドを
各ＰＪのコーディング規約参考にして作成
浮動小数点変数は厳密な等式、式の値は、規格が認めるどのような順序で
非等式のテストをしてはならない評価されようとも同じでなければならない
単項演算子‘-’ は符号なしの隠蔽されている浮動小数点のビット表現は、
式に適用してはならないプログラマは、いかなる方法でも使用してはならない
より大きなデータ型の一部分にアクセスする
ために共用体を使用してはならない

図 1 品質概念，作法，ルールの関係

8


3. 本ガイドの利用方法
本ガイドは，コーディング規約作成支援を目的とし，次の３通りの利用方法を想定しています。
1. 新規コーディング規約の作成
2. 既存コーディング規約の充実
3. プログラマの研修，独習のための学習教材
以下，それぞれの利用方法を説明します。

3.1 新規コーディング規約の作成
コーディング規約の存在しないプロジェクトが，本書を用いて新規にコーディング規約を作成する場合の手順を示します。

(1) 作成時期
コーディング規約は，プログラム設計に入る前までに作成します。コーディング規約は，コーディング時に参照するルールの
集まりですが，関数名の命名規約などプログラム設計に関わるルールもあります。そのため，プログラム設計以前に作成する
必要があります。

(2) 作成方法
次の順序で作成します。
1. コーディング規約の作成方針を決定
2. 決定した作成方針に沿ってルールを選択
3. ルールのプロジェクト依存部分を定義
このあと，必要に応じて，ルールを追加して下さい

1. 作成方針の決定
コーディング規約作成にあたっては，まず，コーディング規約の作成方針を決定します。コーディング規約の作成方針と
は，プロジェクトが作成するソフトウェアやプロジェクトを構成する人の特性などから，そのプロジェクトで作成されるコードが
どのようなコードの書き方となっているべきかを示す方針のことです。例えば，安全性を重視し，便利であっても危険な機
能は使用しないという書き方にするのか，危険な機能であっても注意して使用する程度の書き方にするかなどが，この方
針にあたります。なお，方針の決定にあたっては，プロジェクトで重視したい品質特性及び次に示す視点を考慮して下
さい。
・フェールセーフを考慮したコーディング
・プログラムを見やすくするコーディング
・デバッグを考慮したコーディング
など

2. ルールの選択
ルールは，1.で決定した規約作成の方針に従い，選択します。例えば，移植性を重視する方針とした場合，移植性
に該当するルールを多く選ぶなどの工夫をして下さい。
本ガイドの４．に示すルールリファレンスでは，規約として採用しないとそのルールが属する品質特性を著しく損なうと考
えられるルールについて「選択指針」欄の○で示しています。一方，言語仕様を熟知している人にはあえて規約にする必
要がないと思われるルールについて△で示しています。これを参考にルールを選択して下さい。ルール選択の最も簡便な
方法は，○がついているルールのみを選択することです。それにより，ごく一般的なルールが選択できます。

9


3. プロジェクト依存部分の定義
本ガイドのルールには，次の３種類のルールがあります。
A．規約としてそのまま使えるルール
B．文書化により，規定する必要のあるルール(「文」印のルール)
C．プロジェクトの特性にあわせて，どのルールとするか選択する必要のあるルール（「特」印ルール）
B, C のルールは，そのままではルールとして利用できません。B のルールを採用した場合，「4.3 ルール定義の指針」と付
録「文書化テンプレート」を参考に，ルールを規定して文書化して下さい。C のルールを採用した場合，提示されている複数
のルールから，いずれかのルールを選択して下さい。

3.2 既存コーディング規約の充実
本ガイドは，コーディング規約が既に存在するプロジェクトに対しては，既存のコーディング規約をさらに充実したものとする
ための参考書として利用できます。

(1) 抜け・漏れの防止
本ガイドの作法概念を用いて，既存のコーディング規約をカテゴライズすることにより，抜けている観点を充実させたり，自
プロジェクトが何に重点を置いて作業していたか再認識することができます。

(2) ルールの必要性の明確化
本ガイドの作法とルールの適合例，Ｃ言語での注意事項を利用することで，理由もわからず強制されていた規則の必要
性を認識するためのツールとして利用できます。

3.3 プログラマの研修，独習のための学習教材
本ガイドは，Ｃ言語は一応勉強したが，実際のコーディングには不慣れ，経験が浅いなどのプログラマにとって格好の学習
教材となります。

・対象者
・Ｃ言語を一通り学習したプログラマ
・他言語でのプログラミング経験はあるが，Ｃ言語を使うのは初めてというプログラマ

・学習できること
信頼性・保守性・移植性などの観点から分類された本ガイドを読むことにより，次のようなことを学習できます。
・信頼性を高くするコーディング方法
・バグを作り込まないようにするコーディング方法
・デバッグ・テストがし易いようにするコーディング方法
・他人が見て，見やすいようにするコーディング方法とその必要性
など

10


4. 作法とルールリファレンス
本章では，コーディング時にプログラマが守るべき作法と，その作法に対応する具体的なルールをリファレンスとして示しま
す。4.1 節で，「4.2 作法とルールリファレンス」の表の見方と表中で使用している用語を説明します。4.2 節に「作法とルール
リファレンス」を示し，4.3 節で，ルールを補足説明します。

4.1 表の見方と用語
本節では，「4.2 作法とルールリファレンス」の見方と，表中で利用している用語を説明します。
4.1.1 表の見方
「4.2 作法とルールリファレンス」の表の各々の欄とその意味は次の通りです。
(1) (2) (3) (4) (5) (6) (7) (8)
品作法選規関連
質ルール
ルール C 言語での注意事項択約ﾙｰﾙ
概 No. 指化
念概要詳細針
No.

(1) 品質概念「JIS X 0129-1」の主品質特性に関連付けた品質概念。
本書では以下の４つの品質概念を使用。
― 信頼性 ― 保守性 ― 移植性 ― 効率性
(2) 作法コーディング時にプログラマが守るべき作法。
― 概要作法の広い括りを概念的に定義。言語に非依存。
― 詳細概念的な作法を詳細化。より具体的に気を付けるべき作法。概要同様，基
本的には言語非依存であるが，一部「C 言語」の特性により作法化されてい
るものある。
(3) ルール No. ルールの番号。
(4) ルール作法に対応する具体的に守らなければいけない C 言語用のルール。リファレンスとして示してい
る。なお，この欄のルールが文献の引用である場合，次の形式で示している。
【＜引用文献を示す略語＞＜番号＞】
＜引用文献を示す略語＞
- MISRA : MISRA-C:2004 のこと
- その他は検討中
例：【MISRA 1.3】
(5) C 言語での注意事項 C 言語仕様上の注意事項など，ルールの必要性，ルール違反時に生ずる問題などを説明
している。
(6) 選定指針本ガイドを用いてコーディング規約を作成する際のルールの選定指針。
マーク無しプロジェクトの特性に合わせて選択すればよいと思われるルール。
△ 言語仕様を熟知している人にはあえて規約にする必要がないと思われる
ルール (経験のあるプログラマには当たり前なこと)。
○ 守らないと著しく品質特性を損なうと考えられるルール。
(7) 規約化対象ルールが，プロジェクトごとの指針によって詳細を定める必要があるか無いかを示す。
マーク無し詳細を定める必要なし。そのまま規約として利用できる。
文文書化。プロジェクトごとにルールを規定し，文書化する必要がある。規定するべ
き部分は＜＜＞＞で囲み明示している。
特選択。複数のルールが提示されており，その中から選択する必要がある。
選択肢は，括弧付き数字((1),(2),...という形式)で示している。
(8) 関連ルールＮｏ．当該ルールに関連するルール No。

11


4.1.2 表中の用語
本節では，「4.3 作法とルールリファレンス」で使用する用語を説明します。

用語説明

アクセス変数の参照及び更新を含む参照のこと。

データの型を指定するもの。char，int，float などの基本的な型を指定するものと，プログ
型指定子
ラマが独自に typedef で定義した型を指定するもの。
型に特定の性質を付け加えるもの。次の 2 つがある。
型修飾子
const，volatile
データが記憶される場所を指定するもの。次の 4 つがある。
記憶クラス指定子
auto，register，static，extern
コンパイラがデータをメモリに配置するときの方法を示す。
境界調整例えば，int 型が 2 バイトの場合，必ずメモリの偶数アドレスから配置するようにし，奇数ア
ドレスから配置しないようにすること。
‘??=’，’??/’，’??(‘ のように決められた３文字をコンパイラが特定の 1 文字に解釈する
3 文字表記文字表記のこと。
‘??=’，’??/’，’??(‘ はそれぞれ，’#’，’’，’[‘ に変換される。

生存期間変数が生成されてから，プログラムからの参照が保証されている期間をいう。

2 バイト以上のデータで表現される文字。漢字，ひらがななどの全角文字や，Unicode で
多バイト文字
表現される文字などがある。

ナルポインタいかなるデータ，関数へのポインタと比較しても等しくないポインタ。

ナル文字文字列の最後を表現する文字。’0’で表現される。

ファイルスコープ有効範囲が，ファイルの終わりまでであること。

実行環境の状態に変化を起こす処理。次の処理が該当する。
副作用 volatile データへのアクセス，データの変更，ファイルの変更，及びこれらの操作を行う
関数呼出し。

ブロックデータ宣言，プログラムなどで波括弧’{‘，’}’で囲んだ範囲をいう。

有効範囲変数などを使用できる範囲のこと。スコープともいう。

列挙型 enum 型。いくつかの列挙されたメンバで構成される。

列挙子列挙型（enum 型）のメンバのこと。

12


4.2 作法とルールリファレンス

選規関連
品質作法ﾙｰﾙ択約ﾙｰﾙ
概念 No.
ルール C言語での注意事項指
概要詳細針化 No.
1. 領域は領域は，初期化し 1.1 自動変数は宣言時に初期化する。または自動変数を初期化しないと，その値は不定
信初期化し，てから使用する。使用する直前に初期値を代入する。となり，動作や環境によって演算結果が異な
大きさ，生＜適合例＞る現象が発生する。初期化のタイミングは宣
頼存期間に気 void func() { 言時，または使用する直前とする。（使用す
int var1 = 0; /* 宣言時に初期化する
をつけて使る直前の初期化は正確には代入であり，
*/
性用する。 int i; C++では初期化と代入は意味が異なるので
var1++; 注意が必要）。
/* 使用する直前に初期値を代入 */
for (i=0; i < 10; i++) △
{ /* … */ }
}
＜不適合例＞
void func() {
int var1;
var1++;
/* … */
}
1.2 const 型変数は，宣言時に初期化する。 const 型変数は後から代入ができないので，
＜適合例＞宣言時に初期化すべきである。初期化しな
const int N = 10; いと外部変数の場合は 0，自動変数の場合
＜不適合例＞はが不定となるので，意図しない動作となる
const int N; 可能性がある。宣言時に未初期化でもコン △
パイルエラーにならないため，注意が必要で
ある(C++では const の未初期化はエラーとな
る)。
初期化は過不足 1.3 要素数を指定した配列の初期化では，初配列を文字列で初期化する際に，配列の
無いことがわかるよ期値の数は，指定した要素数と一致させ大きさとしてナル文字分を確保せずとも宣言
うに記述する。る。時にはエラーにならない。意図した記述であ
＜適合例＞れば問題ないが，文字列操作関数等の引
char var[] = "abc"; 数として使用すると文字列の最後を示すナ △
またはル文字がないため，意図しない動作となる可
char var[4] = "abc"; 能性が高い。文字列の初期化の際には，
＜不適合例＞最後のナル文字分まで確保する必要があ
char var[3] = "abc"; る。
1.4 列挙型(enum 型)のメンバの初期化は，定列挙型のメンバに初期値を指定しない場
数を全く指定しない，全て指定する，又は合，直前のメンバの値に 1 を加えた値になる
最初のメンバだけを指定する，のいずれかと (最初のメンバの値は 0)。初期値を指定した
する。り，指定しなかったりすると，不用意に同じ値
【MISRA 9.3】を割り当ててしまい，意図しない動作となる
＜適合例＞可能性がある。使い方にも依存するが，メン
/* E1 から E4 には異なる値が割り付けられバの初期化は，最初 1 つだけに行うか，全く
る */ 行わないかのどちらかにし，同じ値が割り振ら
enum etag { E1=9, E2, E3, E4 };
れるのを防止した方がよい。
enum etag var1;
var1 = E3;
/* var1 に入れた E3 と E4 が等しくなること
はない */
if (var1 == E4 )
＜不適合例＞
enum etag { E1, E2=10, E3, E4=11 };

enum etag var1;
var1 = E3;
/* var1 には E3 が入るが E4 とも等しく真と
なるので，分かり難い */
if (var1 == E4 )

13


選規関連
概念 No.
ポインタの演算を 1.5 (1) ポインタへの整数の加減算(++,--も含ポインタに対する演算を行うとポインタの指し
行う場合には，ポむ）は使用せず，確保した領域への参照・ている先がどこなのかが分かり難くする原因と
インタの指す範囲代入は[ ]を用いる配列形式で行う。なる。すなわち，確保していない領域を参照
に気を付ける。 (2) ポインタへの整数の加減算(++,--も含したり，領域に書き込んだりするバグを埋め
む）は，ポインタが配列を指している場合だ込む可能性が高くなる。領域の先頭を指し
けとし，結果は，配列の範囲内を指していている配列名を使った配列の添え字により，
なければならない。配列要素をアクセスする方が，安全なプログ
ラムとなる。
＜適合例＞なお，(2)のルールにおいて，ポインタは，その
#define N 10 ポインタを用いて配列要素にアクセスしない
int data[N]; 限り，配列の最後の要素を一つ越えたところ
int i; を指してもよい。すなわち，int arr[MAX]，特
i = 1; p=arr として，p+MAX は適合しており，
data[i] = 10; /* OK */ *(p+MAX)は不適合である。
data[i+3] = 20; /* OK */
＜不適合例＞
#define N 10
int data[N];
int *p;
p = data;
*(p + 1) = 10; /* NG */
p += 2; /* NG */
*p = 20;
1.6 ポインタ同士の減算は，同じ配列の要素を C 言語では，ポインタ同士の減算を行った場
指すポインタにのみ使用する。合，各ポインタが指している要素の間に幾つ
【MISRA 17.2】要素が有るかが求まる。この時，各ポインタ
＜適合例＞が別配列を指していると，その間にどのような
int off, var1[10]; 変数がレイアウトされるかは，コンパイラ依存
int *p1, *p2; であり，実行結果は保証されない。このよう
p1 = &var1[5]; にポインタ同士の減算は，同じ配列内の要
p2 = &var1[2]; 素を指している場合のみ意味がある。従っ △
off = p1 - p2; /* OK */ て，ポインタ減算を行う場合には，同じ配列
＜不適合例＞を指しているポインタ同士であることをプログラ
int var1[10], var2[10], off; マが確認して行う必要がある。
int *p1, *p2;
p1 = &var1[5];
p2 = &var2[2];
off = p1 - p2; /* NG */
1.7 ポインタ同士の比較は，同じ配列の要素，異なる変数のアドレス比較をしてもコンパイル
または同じ構造体のメンバを指すポインタにエラーにならないが，変数の配置はコンパイラ
だけ使用する。依存なので意味の無い比較となる。また，こ
【MISRA 17.3】のような比較の動作は，定義されていない
＜適合例＞（未定義の動作）。
#define N 10
char var1[N];
void func(int i, int j) {
if (&var1[i] < &var2[j]) { △
/* ... */
＜不適合例＞
#define N 10
char var1[N];
char var2[N];
void func(int i, int j) {
if (&var1[i] < &var2[j]) {
/* ... */

14


選規関連
概念 No.
解放した領域をア 1.8 自動変数領域は関数終了後は使用しな自動変数領域を関数終了後に使用した場
クセスしない。い。合，その領域は他の用途に使用される可能
＜適合例＞性があるため，他の領域を破壊することがあ
extern int data1;
extern int data2; る。
int *func(tag *p) {
p->mem = &data1; /* 静的な領
域のアドレスなら OK */
return &data2; /* 静的な領域
のアドレスなら OK */
}
...
tag y;
int *p;
p = func(&y);
*p = 10; /* OK */
*y.mem = 20; /* OK */
＜不適合例＞ △
int *func(tag *p) {
int x;
p->mem = &x; /* 関数復帰後に
自動変数領域が参照されてしまう(危険)
*/
return &x; /* 関数復帰後に自動
変数領域が参照されてしまう(危険) */
}
...
tag y;
int *p;
p = func(&y);
*p = 10; /* 不当な領域を
破壊 */
*y.mem = 20; /* 不当な領域を破壊
*/
1.9 解放した領域にアクセスしない動的に獲得した領域を解放後に使用した
＜適合例＞場合，その領域は他の用途に使用される可
struct stag { /* リスト構造の構造体能性があるため，他の領域を破壊することが
*/
struct stag *st_next; ある。
...
}
struct stag *st1; /* リスト構造のポイン
タ */
struct stag *top; /* リスト構造の先頭
ポインタ */
struct stag *next; /* 次のリスト構造の
ポインタ */
...
for (st1 = top ;st1 != NULL; st1 = next) {
next = st1->st_next;
free(st1);
}
＜不適合例＞ △
struct stag { /* リスト構造の構造体 */
struct stag *st_next;
...
}
struct stag *st1; /* リスト構造のポインタ
*/
struct stag *top; /* リスト構造の先頭ポ
インタ */
...
/* リスト構造の構造体を順次解放する処
理 */
/* 解放後，for 文の 3 つ目の制御式で解
放したポインタにアクセスしているので，NG
*/
for (st1 = top; st1 != NULL; st1 =
st1->st_next) {
free(st1);
}

15


選規関連
概念 No.
2. データは内部表現に依存 2.1 浮動小数点型変数は厳密な等式，非等浮動小数点型は，見た目の値と実装された
範囲，大きしない比較を行式の比較はしない。値は完全に一致していないので，比較は許
さ，内部表う。【MISRA 13.3】容誤差を考慮して判定する必要がある。
現に気を付＜適合例＞
けて使用す #define LIMIT 1.0e-4
る。 void func(double d1, double d2) {
double diff = d1-d2; △
if (-LIMIT <= diff && diff <= LIMIT) {
/* … */
＜不適合例＞
void func(double d1, double d2) {
if (d1 == d2) {
/* … */
2.2 浮動小数点型変数はループカウンタとして浮動小数点型は，ループカウンタとして演算
使用しない。が繰り返されると，誤差が累積し，意図した
【MISRA 13.4】結果が得られないことがある。このため，ルー
＜適合例＞プカウンタには整数型を使用すべきである。
void func() {
int i;
for (i=0; i < 10; i++) { △
/* … */
＜不適合例＞
void func() {
double d;
for (d=0.0; d < 1.0;d += 0.1) {
/* … */
2.3 構造体や共用体の比較に memcmp を使構造体や共用体のメモリには，未使用の領
用しない。域が含まれる可能性があり，その領域に何
＜適合例＞が入っているか分からないので，memcmp は
struct { 使用すべきでない。比較をするなら，メンバ
char c; 同士で行う必要がある。また，構造体のメン
long l; バの詰め物，境界調整は処理系定義であ
} var1, var2; る。
void func() {
if (s1.a == s2.a && s1.b == s2.b) {
/* …*/ △
＜不適合例＞
struct {
char c;
long l;
} var1, var2;
void func() {
if (memcmp(var1, var2, sizeof(var1))
== 0) {
/* … */

16


選規関連
概念 No.
真の値と等しいか 2.4 真偽の結果を真として定義した値と等しい真は 0 でないという意味であり，1 とは限らな
どうかを調べてはなかどうかを調べてはいけない。判定する場合い。
らない。は，偽(0)と等しくないかどうかを調べる。
＜適合例＞
typedef int bool;
#define FALSE 0
bool func1(void);
void func2() {
if (func1() != FALSE) {
＜不適合例＞
typedef int bool;
#define TRUE 1
bool func1(void);
void func2() {
if (func1() == TRUE) {
データ型を揃えた 2.5 符号無し整数定数式は，結果の型で表現 int のビット数が異なると，同じ定数式でも，
演算や比較を行できる範囲内で記述する。演算結果がその型で表現できる範囲を超え
う。【MISRA 12.11】た場合と超えない場合で動作が異なる状況
＜適合例＞が発生する。
#define M 0xffffUL
if ((M+1) > M)
/* long が 32bit であれば，int の bit 数が違
っても問題ない */
＜不適合例＞
#define M 0xffffU
if ((M+1) > M)
/* int が 16bit の場合と 32bit の場合で動
作が違う */
2.6 条件演算子(?:演算子)では，論理式は括型が異なる記述を行った場合は，結果はど
弧で囲み，返り値は 2 つとも同じ型にする。ちらの型を期待しているかを明示するために
＜適合例＞キャストを行う。
void func(int i1, int i2, long l1) {
i1 = (i1 > 10) ? i2 : (int)l1;
＜不適合例＞
void func(int i1, int i2, long l1) {
i1 = (i1 > 10) ? i2 : l1;
2.7 ループカウンタとループ継続条件の比較に使値の表現できる範囲が違う変数の比較をル
用する変数は，同じ型にする。ープの継続条件に使用すると，意図した結
＜適合例＞果にならず，無限ループになる場合がある。
void func(int arg) {
int i;
for (i = 0; i < arg; i++) { △
＜不適合例＞
void func(int arg) {
short i;
for (i = 0; i < arg; i++) {

17


選規関連
概念 No.
型が異なる変数 2.8 演算の型と演算結果の代入先の型が異な演算の型は演算に使用する式の型によって
同士で演算するる場合は，期待する演算精度の型へキャス決まり，代入先の型は考慮されない。演算
場合は，演算精トしてから演算する。の型と代入先の型が異なる場合，多くは，
度を考慮した記述＜適合例＞代入先の型の精度の演算を期待している。
にする。 int i1, i2; このため，期待する型にキャストしてから演算
long l; する必要がある。
double d;
void func() {
d = (double)i1 / (double)i2; /* 浮動小
数点型での除算 */ △
l = ((long)i1) << i2; /* long でのシフト
*/
＜不適合例＞
int i1, i2;
long l;
double d;
void func() {
d = i1 / i2; /* 整数型での除算 */
l = i1 << i2; /* int でのシフト */
2.9 符号付きの式と符号無しの式の混在した大小比較，乗除算など，演算を符号付きで
算術演算，比較を行う場合は，期待する行うか，符号無しで行うかによって結果が異
型に明示的にキャストする。なる演算もある。符号付き，符号無しを混
＜適合例＞在して記述した場合，どちらで行われるか
long l; は，それぞれのデータのサイズも考慮して決
unsigned int ui; 定されるため，常に符号無しで行われるとは
void func() { 限らない。このため，混在した算術演算を行
l = l / (long)ui;
う場合は，期待する演算が符号付きか符
または
l = (unsigned int)l / ui; 号無しかを確認し，期待した演算になるよう
に，明示的にキャストする必要がある。また，
if (l < (long)ui) { キャストするのでなく，使用するデータ型を変
または更した方がよい場合もある。
if ((unsigned int)l < ui) {
＜不適合例＞
long l;
unsigned int ui;
void func() {
l = l / ui;
if(l < ui) {
/* … */
関数の，宣言と使 2.10 関数呼出しと関数定義の前で関数のプロプロトタイプ宣言が存在すると，コンパイラで
用の整合性がとらトタイプ宣言をする。整合性のチェックが行われる。(C++では必須
れていることを，コ＜適合例＞である)
ンパイラがチェックで /* stdio.h の中に関数 puts のプロトタイプ
きる書き方にする。宣言がある */
#include <stdio.h>
void main() { ○
puts(" hello");
}
＜不適合例＞
void main() {
puts(" hello");
}
2.11 引数を持たない関数は，引数型を void とす int func(); は，引数がない関数の宣言では
る。なく，旧式の宣言で引数の数と型が不明と
【MISRA 16.5】いう意味である。引数がない関数を宣言す
＜適合例＞る場合は void を明記する。 ○
int func(void);
＜不適合例＞
int func();

18


選規関連
概念 No.
情報損失の危険 2.12 情報損失を起こす可能性のあるデータ型へ値をその型と異なる型の変数に代入すると，
のある演算は使用の代入(＝演算，関数呼び出しの実引数値が変わる（情報損失する）可能性がある。
しない。使用する渡し，関数復帰)を行う場合は，問題がな可能であれば代入先は同じ型とするのがよ
場合は問題のないいことを確認し，問題がないことを明示するい。情報損失の恐れはない，又は損失して
ことを明示する。ためにキャストを記述する。もよいなど，意図的に異なる型へ代入する
＜適合例＞場合は，その意図を明示するためにキャスト
short s; を記述する。
long l; 但し，キャストを記述するより，代入先のデー
void func() { タ型を見直す方がよい場合が多いことに注 ○
s = (short)l; 意する。
s = (short)(s+1);
＜不適合例＞
short s;
long l;
void func() {
s = l;
s = s+1;
2.13 単項演算子'-' は符号無しの式に使用し符号無しの式に単項'-'を使用することで，
ない。演算結果が元の符号無しの型で表現でき
【MISRA 12.9】る範囲外になった場合，予期しない動作と
＜適合例＞なる可能性がある。
int i;
void func() { △
i = -ｉ;
＜不適合例＞
unsigned int ui;
void func() {
ui = -ui;
2.14 unsigned char 型又は unsigned short unsigned char 又は unsigned short の演算
型のデータをビット反転(~)したり，左シフト結果は signed int となる。演算によって，
(<<)する場合，結果の型に明示的にキャス符号ビットがオンになると，期待した演算結
トする。果にならない場合がある。このため，期待す
【MISRA 10.5】る演算の型へのキャストを明示する。
＜適合例＞
unsigned char uc; ○
void func() {
u = (unsigned char)(~uc) >> 1;
＜不適合例＞
unsigned char uc;
void func() {
u = (~uc) >> 1;
2.15 ビット列として使用するデータは，符号付き符号付き型のビット単位の演算（ ~, <<, >>,
型ではなく，符号無し型で定義する。 &, ^, | ）を行った結果は処理系定義であ
る。
＜適合例＞
unsigned int flags;
void set_x_on() {
flags |= 0x01;
＜不適合例＞
signed int flags;
void set_x_on() {
flags |= 1;

19


選規関連
概念 No.
対象データが表現 2.16 ビットフィールドに使用する型は signed int 符号指定のない int をビットフィールドに使用
可能な型を使用と unsinged int だけとし，1 ビット幅のビットフした場合，符号付き，符号無しのどちらで使
する。ィールドが必要な場合は singed int 型でな用されるかは処理系定義である。そのため，
く，unsigned int 型を使用する。符号指定のない int 型はビットフィールドには
【MISRA 6.4, 6.5】
＜適合例＞使用しない。また，コンパイラがサポートしてい
struct S { ても，char,short,long の型をビットフィールド
signed int m1:2; に使用することは C90 の仕様外であるの
またはで，移植性を考慮する場合は使用ししな ○
unsigned int m1:1; い。また，1 ビットの signed int のビットフィール
};
＜不適合例＞ドが表現できる値は-1 と 0 のみとなるので，1
struct S { ビットのビットフィールドには unsigned int を使
signed int m1:1; 用する。
int m2:1;
char m3:1;
};

ポインタの型に気を 2.17 (1) ポインタ型は，他のポインタ型や整数型ポインタ型の変数を他のポインタ型にキャスト
付ける。に変換してはならない。また，逆も行ってはや代入すると，ポインタの指す先の領域が，
ならない。データへのポインタ型については，どのようなデータなのかが分かり難くなる。
void*型との変換は可とする。 CPU によっては，ワード境界を指さないポイン
(2) ポインタ型は，他のポインタ型に変換しタを使ってポインタの指す先を int 型でアクセ
てはならない。ポインタ型のデータ幅以上のスしてしまうと，実行時エラーが発生するもの
整数型との変換は可とする。また，データへもあり，ポインタの指す先を，プログラマが勝
のポインタ型については，void*型との変換手に変更してしまうと，思わぬバグになる危
は可とする。険がある。ポインタ型の変数は，他のポインタ
(3) ポインタ型は，ポインタ型のデータ幅以型にキャストや代入しない方が安全である。
上の整数型との変換は可とする。関数へのポインタ型を整数型に変換することも，前述
ポインタ型は，整数型以外の型との変換はの問題と同じ危険性があり，必要な場合
不可とする。データへのポインタ型は，他のは，経験者を交えたレビューが必要である。
データへのポインタ型との変換を可とする。さらに，int 型の扱う値の範囲とポインタ型の
＜適合例＞扱う値の範囲に対する注意も必要である。
int *ip; int 型サイズが 32 ビットにも関わらず，ポインタ
void *vp; 型サイズが 64 ビットということもあるので，事
int n; 前に，コンパイラの仕様を確認しておく。 ○ 特
n = (int)ip; /* 2 と 3 のルールに
OK */
ip = (int*)vp; /* OK */
vp = (void*)ip; /* OK */

＜不適合例＞
int *ip;
int (*fp)(void);
float f;
char data[10];
fp = ip; /* NG */
f = ip; /* NG */
ip = (int*)&data[1]; /* 1 と 2 のルールに
NG */
*ip = 0; /* CPU によっては実行エラーが
発生 */

20


選規関連
概念 No.
2.18 const や volatile 修飾された領域を指すポ const や volatile 修飾された領域は，参照し
インタに対し，const や volatile 修飾を取りかされない領域であったり，最適化をしては
除くキャストはしてはならない。ならない領域ということで，その領域に対する
【MISRA 11.5】アクセスに注意しなければならない。これらの
＜適合例＞領域を指すポインタに対し，const や volatile
void func(const char *); を取り除くキャストを行ってしまうと，前述の注
const char *str; 意項目が見えなくなり，コンパイラは，プログラ
void x() { ムの誤った記述に対し，何もチェックできなく
func(str);
なる。 ○
/* … */
}
＜不適合例＞
void func(char *);
const char *str;
void x() {
func((char*)str);
/* … */
}
3 .異常値を領域の大きさを意 3.1 配列を順次にアクセスするループの継続条 C 言語の問題ではなく，領域外をアクセスし
考慮した書識した書き方にす件には，配列の範囲内であるかの判定を入ないようにするためのルールである。
き方にする。る。れる。
＜適合例＞
char var1[MAX];
for (i = 0; i < MAX && var[i] != 0; i++)
{ /* var1 配列に 0 が未設定の場合でも，
配列の範囲外アクセスの危険無 */
/* … */
＜不適合例＞
char var1[MAX];
for (i = 0; var[i] != 0; i++) { /* var1 配列
に 0 が未設定の場合，配列の範囲外アク
セスの危険有 */
/* … */
3.2 (1) 配列の extern 宣言の要素数は必ず指配列の大きさを省略して extern 宣言した場
定する。合，エラーにはならない。しかし，配列の範囲
(2) 要素数が省略された初期化付き配列外のチェックするときに大きさが省略されてい
定義に対応した配列の extern 宣言を除きると，チェックに支障が発生する場合がある。
配列の extern 宣言の要素数は必ず指定このため，配列の大きさは明示して宣言した
する。方がよい。ただし，初期値の個数で配列の
＜適合例＞大きさを決定し，一意に大きさが決まらない
extern int var1[MAX]; 場合などは，宣言時の配列の大きさを省略
... した方がよい場合もある。
for ( i = 0; i < MAX; i++ ) { /* 配列の
○ 特
範囲を超えていないことが明確 */
var1[i] = i ;
}
＜不適合例＞
extern int var1[];
...
for ( i = 0; i < MAX; i++ ) { /* 配列の
範囲を超えているか不明確 */
var1[i] = i ;
}

21


選規関連
概念 No.
3.3 メモリ操作を行う関数を使用する場合，配領域外をアクセスすると，意図しない結果を
列の範囲を超えてアクセスしない値を渡す。引き起こす場合がある。異なるサイズの領域
＜適合例＞を引数に指定する場合は，データ型を見直
#define N 20 して同じサイズに揃えるか，小さな方のサイズ
char var1[N]; を指定する必要がある。また，サイズが不特
char var2[N]; 定の領域を操作する可能性がある関数に
void func2(char*, char *,int n); は，引数にサイズを指定するようにする。
void func() {
memcpy(var1, var2, sizeof(var2));
func2(var1,var2,sizeof(var2)); △
＜不適合例＞
#define A 10
#define B 20
char var1[A];
char var2[B];
void func2(char*, char*);
void func1() {
memcpy(var1, var2, sizeof(var2));
func2(var1, var2);
実行時エラーにな 3.4 除算や剰余算の右辺式は，0 でないのを確明らかに 0 でない場合を除き，除算や剰余
る可能性のある演認してから演算を行う。算の右辺が 0 でないことを確認してから演算
算に対しては，エラ＜適合例＞する。そうしない場合，実行時に 0 除算のエ
ーケースを迂回さ if (y != 0) ラーが発生する可能性がある。 ○
せるようにチェックす ans = x/y;
る。＜不適合例＞
ans = x/y;
3.5 ポインタは，ナルポインタでないことを確認し
てからポインタの指す先を参照する。
＜適合例＞
if (p != NULL)
*p = 1;
＜不適合例＞
*p = 1;
関数が異常を返 3.6 関数がエラー情報を返す場合，関数の復
す可能性がある場帰値を確認し，異常時の処理を行う。
合は，異常値をチ【MISRA 16.10】
ェックする。＜適合例＞
p = malloc(BUFFERSIZE);
if (p == NULL)
/* 異常処理 */ ○
else
*p = ¥0;
＜不適合例＞
p = malloc(BUFFERSIZE);
*p = ¥0;
関数のパラメタとし 3.7 関数に渡す引数に制限がある場合，関数
て渡してはならない呼び出しする前に，制限値でないことを確
制限値がある場認してから関数呼び出しする。
合は，制限値を渡＜適合例＞
さないように，チェッ if ((MIN <= para) && (para <= MAX))
クする。 ret = func(para);
＜不適合例＞
ret = func(para);

22


選規関連
概念 No.
多岐分岐処理に 3.8 if-else if 文は，最後に必ず else 節を置く。 else 節がないと，else 節を書き忘れているの
おいて，所定の条通常，Else 条件が発生しないことがわかっか，else 節が発生しない if-else if 文なのか
件以外が発生している場合は，次のいずれかの記述とする。がわからなくなる。
た場合の処理を (i) else 節には，例外発生時の処理を記述通常，else 条件が発生しないことがわかって
記述しておく。する。いる場合でも次のように else 節を書くことによ
(ii) else 節には，/* DO NOTHING */といって想定外の条件が発生した場合のプログ
うコメントを入れる。ラムの動作を予測することができる。
・else 条件に想定外の条件に対する動作
＜適合例＞を記述する。(万が一，else 条件が発生した
/* else 条件が通常発生しない場合の場合のログラムの動作を決めておく)
if-else if 文の else 節 */ また，else 条件が発生しないコメントを記述
if (var1 == 0) { するだけでも，プログラムがわかりやすくなる。
… ・/* DO NOTHING */のように，else 条件
} else if (0 < var1) { が発生しないことを明示するコメントを記述
… し，else 節の書きもれではないことを表現す
} else { る。
/* 例外処理を記述する */
… ○
}
…
if (var1 == 0) {
…
} else if (0 < var1) {
…
} else {
/* DO NOTHING */
}
＜不適合例＞
/* else 節のない if-else if 文 */
if (var1 == 0) {
...
} else if (0 < var1) {
…
}

23


選規関連
概念 No.
3.9 switch 文は，必ず default 節を置く。 default 節がないと，default 節を書き忘れて
通常，default 条件が発生しないことがわかいるのか，default 節が発生しない switch 文
っている場合は，次のいずれかの記述とすなのかがわからなくなる。
る。通常，default 条件が発生しないことがわか
(i) default 節には，例外発生時の処理をっている場合でも次のように default 節を書く
記述する。ことによって想定外の条件が発生した場合の
(ii) default 節には，/* DO NOTHING */ プログラムの動作を予測することができる。
というコメントを入れる。・default 条件に想定外の条件に対する動
＜適合例＞作を記述する。(万が一，default 条件が発
/* default 条件が通常発生しない switch 生した場合のログラムの動作を決めておく)
文の default 節 */ また，default 条件が発生しないコメントを記
switch(var1) { 述するだけでも，プログラムがわかりやすくな
case 0: る。
… ・/* DO NOTHING */のように，default 条
break; 件が発生しないことを明示するコメントを記
case 1: 述し，default 節の書きもれではないことを表
… 現する。
break;
default:
/* 例外処理を記述する */
…
break;
} ○
…
switch(var1) {
case 0:
…
break;
case 1:
…
break;
default:
/* DO NOTHING */
break;
}
＜不適合例＞
/* default 節のない switch 文 */
switch(var1) {
case 0:
…
break;
case 1:
…
break;
}
再帰呼び出しにな 3.10 実行時の利用スタックサイズが予測できな
るような関数呼びいため再帰呼び出し関数は使用しない。
出しを行わない。【MISRA 16.2】

24

Coding Guide

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (8)

Similaire à Coding Guide

Similaire à Coding Guide (20)

Coding Guide