[セットトップ]C++Coding Standard
9053 ワード
1汎用
Rule 1コンパイルのWarningsは無視できません
Rule 2既存のCodeまたは三者のcodeに基づく修正は、元のcoding standardの使用を許可する
Rule 3 CとC++が同じCのヘッダファイルにアクセスできるようにする場合、extern Cはヘッダファイルに
2命名規則
Rule 4のすべての名前の定義は16バイト以内で、最大31バイトを超えないでください.
Rule 5名の定義は英数字と下線のみです
Rule 6保留名は使用しない
Rule 7コードファイルは.h, .c末尾
Rule 8コードのファイルフォーマットはUNIX file formatのままでなければなりません
Rule 9ファイル名小文字、単語の記述が1つを超える場合は下線で区切る
Rule 10 Typedefs,and enumerated types,structure types and union types小文字を下線で区切って複数の単語の説明をし、最後はtypeで終わる
Rule 11マクロ定義、Enumの値は、複数の単語を大文字で下線で区切る必要があります
Rule 12関数名は動詞で、複数の単語を小文字と下線で区切る必要があります.
Rule 13グローバル変数は、gの先頭と次の線で単語を区切る必要があります.
g_default_interface
Rule 14関数のパラメータ小文字
Rule 15 structureのメンバー変数には、次のルールがあります.
名前
マーク
例
static
s_
static UINT8 s_some_number
static
s_
static UINT8 s_some_number
constant
c_
const UINT8 c_some_number
cp_
const user_data_type* cp_user_data
3 Files
Rule 16各includeの多重包含を防止するメカニズムが必要
Rule 17相対パスのlinuxファイルは#includeに表示できません
Rule 18ヘッダファイルでは実装コードは許可されていません
Rule 19各ヘッダファイルは、関連定義されたヘッダファイルを含む他の依存するヘッダファイルのみをincludeグローバルヘッダファイルを含まない
Rule 20コードファイル(.c)にはincludeグローバルヘッダファイルおよび関連ヘッダファイルが必要です
4コードスタイルと間隔
Rule 21は、変更されたファイルに会社confidentialのIDを付ける必要があります.
Rule 22は、変更または新規作成されたファイルに会社confidentialのIDを付ける必要があります.
Rule 23 Revision HistoryはFeature開発完了またはBug解決完了後に更新する必要があります
Rule 24のすべてのCommentsは英語で記入する必要があり、埋め込むことはできません.
Rule 25コードをインデントするときはTabではなく4つのスペースで代用します
Rule 26 Switchにはdefaultが必要です
Rule 27はいないまたは->前後にスペースがある
Rule 28変数の宣言はできるだけ小さな範囲に抑える
Rule 29ポインタ*はタイプの後に続くべきで、アドレス&は変数名の前にあるべきです
Rule 30変数定数定義は必ず意味があり、magic numberを使用しないでください.
x = 100*10+1;//NOT ALLOWEDnumber = 100*10+1;
Rule 31は変数定義ごとに行書きし、初期値を必ず与える
Rule 31のすべての状態変数またはenumの変数は、その値を明示的に与える
Rule 32すべてのglobalの宣言は1つのヘッダファイルにあります
Rule 33定数宣言には明確な意味が必要です
Rule 34 1つのconstantは別のconstantに支払うことができません
Rule 35 NULLはポインタの初期化と比較にのみ使用されます
Rule 36定数はコンパイルスイッチに使用する場合、必ずコンパイル制御の領域内
Rule 37#ifdef#endifコンパイルには十分なコメントが必要であり、#endifには//コメント対応の#ifdefが必要である
Rule 38は、#defineではなくtypedefでタイプを定義する
Rule39 The following types shall be defined in a global header file and shall be used in place of the C language int types:
Rule 31関数は1つのreturn出口しかないはずです
Rule 32明確に定義されていないパラメータは使用しないでください
Rule 33関数returnポインタfailureの場合はreturn NULLが必要です
Rule 34関数パラメータは単列配列で明確なサイズは必要ありません
Rule 35マクロ定義の拡張にはカッコを付けて定義する必要があります
Flow control, expressions
Rule 36 Switch caseはbreakで終わる必要があります
Rule 37 Switch defaultは制御以外の状況が必要です
Rule 38 Gotoは使用しない
Rule 39は比較時に左に定数を入れます
Rule 40 else ifを使用する場合、elseの部分に
Rule 41 if/else/while/for/doのブロックは1行でも複数行でも必ず{
Memory
Rule 42は、必ず呼び出し関数から割り当てられたメモリが使用済みになった後にメモリを解放することを保証し、必ずここで関数コメントを呼び出して注意する.
Rule 43は、deferenceがポインタを参照する前に、ポインタがNULLであるか否かを必ず判定する
UINT32* p_number = NULL;if (NULL == p_number){}
その他
Rule 44コンパイラ関連の拡張は必要に応じて使用
Rule 45コンパイラ関連の拡張は必要に応じて使用
Rule 46すべての失われたタイプの変換を明確にするにはcast
Rule 47配列のアクセスは角カッコでのみアクセスできます.deference*ではアクセスしないでください.
Rule 48はcondition判定の場合はなるべく肯定論理を用いる
Rule 1コンパイルのWarningsは無視できません
Rule 2既存のCodeまたは三者のcodeに基づく修正は、元のcoding standardの使用を許可する
Rule 3 CとC++が同じCのヘッダファイルにアクセスできるようにする場合、extern Cはヘッダファイルに
#ifdef __cplusplus
extern "C" {
#endif
/* body of header */
#ifdef __cplusplus
}
#endif
2命名規則
Rule 4のすべての名前の定義は16バイト以内で、最大31バイトを超えないでください.
Rule 5名の定義は英数字と下線のみです
Rule 6保留名は使用しない
Rule 7コードファイルは.h, .c末尾
Rule 8コードのファイルフォーマットはUNIX file formatのままでなければなりません
Rule 9ファイル名小文字、単語の記述が1つを超える場合は下線で区切る
structured_data_display.h
structured_data_display.c
Rule 10 Typedefs,and enumerated types,structure types and union types小文字を下線で区切って複数の単語の説明をし、最後はtypeで終わる
typedef UINT8 user_data_struct_type
Rule 11マクロ定義、Enumの値は、複数の単語を大文字で下線で区切る必要があります
#define USER_DATA_MAX_ERROR_CODES 15
enum user_data_struct_type
{
USER_DATA_ERROR_INVALID_DATA,
USER_DATA_ERROR_FAILURE
};
Rule 12関数名は動詞で、複数の単語を小文字と下線で区切る必要があります.
handle_error
check_for_error /* NOT errorCheck */
Rule 13グローバル変数は、gの先頭と次の線で単語を区切る必要があります.
g_default_interface
Rule 14関数のパラメータ小文字
void start_engine(engine_type* myengine,
UINT8 engine_id,
const UINT32* protected_data);
Rule 15 structureのメンバー変数には、次のルールがあります.
名前
マーク
例
static
s_
static UINT8 s_some_number
static
s_
static UINT8 s_some_number
constant
c_
const UINT8 c_some_number
cp_
const user_data_type* cp_user_data
3 Files
Rule 16各includeの多重包含を防止するメカニズムが必要
#ifndef FOO_H
#define FOO_H
/* The rest of the file*/
#endif
Rule 17相対パスのlinuxファイルは#includeに表示できません
// NOT ALLOWED
#include <../foo/include/foo.h>
Rule 18ヘッダファイルでは実装コードは許可されていません
Rule 19各ヘッダファイルは、関連定義されたヘッダファイルを含む他の依存するヘッダファイルのみをincludeグローバルヘッダファイルを含まない
Rule 20コードファイル(.c)にはincludeグローバルヘッダファイルおよび関連ヘッダファイルが必要です
4コードスタイルと間隔
Rule 21は、変更されたファイルに会社confidentialのIDを付ける必要があります.
/* -------------------------------------------------------------------------------
Copyright (C) 2011, Nollec Wireless CO. LTD. All Rights Reserved
Revision History:
Bug/Feature ID Author Modification Date Description
------------------ ------------------- ------------------ ---------------------
BugID/FeatureID developer name YYYY/MM/DD brief discription
----------------------------------------------------------------------------------*/
Rule 22は、変更または新規作成されたファイルに会社confidentialのIDを付ける必要があります.
Rule 23 Revision HistoryはFeature開発完了またはBug解決完了後に更新する必要があります
Rule 24のすべてのCommentsは英語で記入する必要があり、埋め込むことはできません.
Rule 25コードをインデントするときはTabではなく4つのスペースで代用します
（ , ）
void func()
｛
if (something bad)
{
...
if (another thing bad)
{
}
}
Rule 26 Switchにはdefaultが必要です
switch (testValue)
{
case VALUE_1:
/* Body for case 1. */
break;
case VALUE_2:
/* Body for case 2. */
break;
default:
/* Body for default. */
break;
}
Rule 27はいないまたは->前後にスペースがある
Rule 28変数の宣言はできるだけ小さな範囲に抑える
Rule 29ポインタ*はタイプの後に続くべきで、アドレス&は変数名の前にあるべきです
Rule 30変数定数定義は必ず意味があり、magic numberを使用しないでください.
x = 100*10+1;//NOT ALLOWEDnumber = 100*10+1;
Rule 31は変数定義ごとに行書きし、初期値を必ず与える
UINT8 i, j; /* NOT RECOMMENDED */
UINT8 i = INIT_VALUE; /* GOOD */
UINT8 j = INIT_VALUE; /* GOOD */
Rule 31のすべての状態変数またはenumの変数は、その値を明示的に与える
/* INCORRECT*/
if (cpCurrentState == CP_L3_STATE_TYPE_D1)
{
cpCurrentState++;
}
/*CORRECT*/
if (cp_currentState == CP_L3_STATE_TYPE_D1)
{
cp_currentState = CP_L3_STATE_TYPE_D2;
}
Rule 32すべてのglobalの宣言は1つのヘッダファイルにあります
Rule 33定数宣言には明確な意味が必要です
(Does not meet requirements)
#define ONE 1
#define TWO 2
(Meets requirements)
#define NUM_LOOPS_FOR_AD_READ 4
#define NUM_SAMPLES_TAKEN 8
Rule 34 1つのconstantは別のconstantに支払うことができません
Rule 35 NULLはポインタの初期化と比較にのみ使用されます
Rule 36定数はコンパイルスイッチに使用する場合、必ずコンパイル制御の領域内
#define DEBUG 4
/* if undefined, disables debugging */
/* set to 1 - 4 for desired debugging level */
/* This usage of DEBUG in the for loop control statement is
* allowed since the statement is fully enclosed within the
* conditionally compiled section of code.
*/
#ifdef DEBUG
for (i = 0; i < DEBUG; i++)
{
printf("i = %d
", i);
}
#endif
Example 31 - Example (Incorrect Usage)
#define DEBUG 4
#ifdef DEBUG /* usage here is fine */
/* do something special */
#endif
/* the code statement below is outside the segment controlled by
* the #ifdef and therefore should NOT use DEBUG.
*/
for (i = 0; ((i < 5) && DEBUG); i++)
{
printf("i = %d
", i);
}
Rule 37#ifdef#endifコンパイルには十分なコメントが必要であり、#endifには//コメント対応の#ifdefが必要である
Rule 38は、#defineではなくtypedefでタイプを定義する
Rule39 The following types shall be defined in a global header file and shall be used in place of the C language int types:
• INT8: This type stores 8-bit signed numeric values.
• UINT8: This type stores 8-bit unsigned numeric values.
• INT16: This type stores 16-bit signed numeric values.
• UINT16: This type stores 16-bit unsigned numeric values.
• INT32: This type stores 32-bit signed numeric values.
• UINT32: This type stores 32-bit unsigned numeric values.
• BOOLEAN: Ideally, this type is an enumerated type that names the boolean values TRUE (1) and FALSE (0). However, some compilers may not store this efficiently. An alternative is typedef UINT8 BOOLEAN;
That simply defines BOOLEAN as an 8-bit unsigned value which is distinct from UINT8. In this case, the constants TRUE and FALSE will have to be defined constants.
Rule 31関数は1つのreturn出口しかないはずです
Rule 32明確に定義されていないパラメータは使用しないでください
Rule 33関数returnポインタfailureの場合はreturn NULLが必要です
Rule 34関数パラメータは単列配列で明確なサイズは必要ありません
(Correct Usage)
void functionName
(
UINT8 x[], /* array with "size" elements */
UINT8 size /* number of elements in x */
);
(Incorrect Usage)
void functionName (UINT8 x[10]);
Rule 35マクロ定義の拡張にはカッコを付けて定義する必要があります
(Correct):
#define A_CONSTANT (ANOTHER_CONSTANT + 1)
a = ACONSTANT * 2;
(Incorrect):
#define A_CONSTANT ANOTHER_CONSTANT + 1
a = ACONSTANT * 2;
Flow control, expressions
Rule 36 Switch caseはbreakで終わる必要があります
Rule 37 Switch defaultは制御以外の状況が必要です
Rule 38 Gotoは使用しない
Rule 39は比較時に左に定数を入れます
// NOT RECOMMENDED, imagine you forget one of the “=” signs
If (PHONE == IS_RESET)
{
}
// GOOD, the following statement eliminates the possible errors explained above
// and easier to follow the value that you are looking for
If (IS_RESET == PHONE)
{
}
Rule 40 else ifを使用する場合、elseの部分に
Rule 41 if/else/while/for/doのブロックは1行でも複数行でも必ず{
// NOT RECOMMENDED
if (something)
if (something else)
doThis();
else
while (input)
doThat();
// GOOD
if (something)
{
if (something else)
{
doThis();
}
else
{
while (input)
{
doThat();
}
}
}
Memory
Rule 42は、必ず呼び出し関数から割り当てられたメモリが使用済みになった後にメモリを解放することを保証し、必ずここで関数コメントを呼び出して注意する.
Dangerous memory management
error_code_type* myfunction(void)
{
error_code_type* p_temp = malloc (sizeof(error_code_type));
return p_temp;
/* p_temp is never de-allocated and the user of myFunc cannot de-allocate*/
/* because a temporary copy of that instance is returned.*/
/* Calling user code shall take of the memory deallocating which will create*/
/* complexity and confusion*/
}
Rule 43は、deferenceがポインタを参照する前に、ポインタがNULLであるか否かを必ず判定する
UINT32* p_number = NULL;if (NULL == p_number){}
その他
Rule 44コンパイラ関連の拡張は必要に応じて使用
#ifdef _HC11_
#define DIRECT _direct_ram
#else /* not _HC11_ */
#define DIRECT
#endif
/* nSize located in direct RAM in embedded, normal RAM in UNIX */
DIRECT UINT8 nSize;
Rule 45コンパイラ関連の拡張は必要に応じて使用
Rule 46すべての失われたタイプの変換を明確にするにはcast
INT8 signed_value;
UINT16 long_value;
UINT8 short_value;
/* Loss here is in accuracy going from signed to unsigned */
signed_value= (UINT8) short_value;
/* Loss here is in size, going from a 16 bit value to an 8 bit */
signed_value= (INT8) long_value;
Rule 47配列のアクセスは角カッコでのみアクセスできます.deference*ではアクセスしないでください.
/*INCORRECT*/
*(masterList + 10) = 0;
/*CORRECT*/
masterList[10] = 0;
Rule 48はcondition判定の場合はなるべく肯定論理を用いる