［ホーム］>［JCL］>治郎吉コーディング規約

Products and Services

治郎吉コーディング規約

治郎吉商店におけるコーディング規約を示します。

命名規則

共通事項

関数であれ変数であれ、名前を見ただけで用途が分かるように心がける。

グローバル定数（マクロ定数も含む）

定数名に接頭辞「k」を付ける。次に例を示す。


#define kMaxBufferLength 1024
const long kMaxBufferLength = 1024;

グローバル変数

基本的に使わないが、使う時には「g」を接頭辞として付ける。次に例を示す。


long gGlobalVariable;

グローバル関数

属する関数群の名前を接頭辞として付け、次にアンダーバーを付けて単語の頭を大文字にして繋げる。 static宣言である場合は単純に単語の頭を大文字にして繋げる。次に例を示す。


extern void Jiro_Ary_Free( JIRO_ARY_HDL inAryHdl );
static long ResizeBuffer( JIRO_ARY_HDL inAryHdl, long inNewRecNum );

引数

関数の引数は、その関数内での扱いに応じて接頭辞「in」、「out」、「io」のいずれかで必ず修飾する。各接頭辞の意味は次に示すとおりである（各関数の引数を説明する項で[in]などと書いてあるものはこれを意味している）。

in
関数の処理に必要な情報としてのみ与え、関数呼び出し後もその値は変わらない。
out
関数から情報を受け取るために与え、関数呼び出し後は値が変わる。
io
関数の処理に必要な情報として与え、かつ関数呼び出し後はその値は変化する。

型情報は変数名に含めない。型が簡単に推測できるような変数名とするよう心がける。ただし、ポインタやハンドルである場合はそれぞれ「Ptr」、「Hdl」などの接尾辞で修飾することが望ましい。

クラスメンバ

既存のクラスにメンバを定義する際には基本的にそのクラスライブラリの命名規則に従う。次にMFC4(VC6)を利用する場合の例を示す。


class CMyMfcApp : public CWinApp
{
    // メンバー変数
    long m_DataCount;

    // メンバー関数
    long GetDataCount( void );
    void SetDataCount( long inNewCount );
    .
    .
    .

コーディングスタイル

記述スタイルはANSIのそれに従う。また、「見た目」の見通しの良さではなく「処理の」見通しの良さを考えて基本的に一行一命令とする。これは同時に再利用性の向上ももたらす。このために次のような事項を心がける。

関数の引数に関数を与えない。
演算子の前後、括弧の中、カンマの後に空白を入れる。
開き中括弧（{）はぶらさげない。
switch文は用いず「if/else if」文で表現する。
エラー値は定数定義する（#define、enum、const...）。
条件式には必ず比較演算子を用いて条件を明示する。

コメント付け

コメントは随所に入れ、コードを読まずともコメントを読むだけで処理内容が理解できるように心がける。また、コメントは基本的に日本語で書く。これにはコメント内容が検索に当たらないというメリットもある。

関数の宣言、定義の直前には関数名、機能、戻り値を説明するコメントを入れる。必要に応じて引数の説明、特別な注釈を加える。なお、これらの書き方に厳密なフォーマットは無い。次に例を示す。


//-----------------------------------------------------
// 関数名： Jiro_Ary_SetSize
// 機能： 配列のサイズを変更する。データはすべて0クリアされる
// 戻り値：（0:成功、-1：メモリ不足エラー）
//-----------------------------------------------------
int Jiro_Ary_SetSize(JIRO_ARY_HDL inAryHdl, long inSize);

変数定義

そのブロックで用いるローカル変数はそのブロックの頭ですべて宣言し、一行につき一変数を定義する。

演算子

ごく基本的な演算子のみを用いる。インクリメント、デクリメント演算子は基本的にfor文の中でのみ使う。また、前置インクリメント、前置デクリメント演算子は使わない。複合代入演算子（+=など）も使わない。

JiroNamazu対応フォーマット

ファイルヘッダ

治郎吉商店ではNamazuによるソースコードの全文検索システムを使用している。これを活用するために次のようなヘッダを各ソースファイルの先頭に記述する。

// TYPE:
プログラム言語やプログラムの形態（servelet、applet他）を記述する。
// PRJ:
そのファイルを使用したプロジェクト名を記述する。
// PGM:
プログラムの役割、固有な名前などの簡単な説明を記述する。
// VER:
リリースバージョンを記述する。なおリリースバージョンの変更は社内リリースなどが行われた場合に行う。
// USES:
使用開発環境、プラットフォーム、使用ライブラリ等、コンパイルおよび実行に必要な情報を記述する。
// CREATE:
プログラム作成日付を６桁の数字で記述し、その後に作成者の名前を括弧付けで記述する。作成者が複数人いる場合はカンマ区切りで記述する。
// UPDATE:
プログラムの最終更新日をCREATE:と同じ書式で記述する。

また、そのプログラムが別のファイルを元に改変、流用して作られた場合、参照元についての情報をヘッダの最後に記す。次に例を示す。


// TYPE: C++
// PRJ: Goroku
// PGM: Common
// VER: 1.00
// USES: VC, C++ Builder, JCL3.0, Win
// CREATE: 020901 (Tsunoda)
// UPDATE: 020910 (Tsunoda)

修正履歴ファイル

修正が発生した場合、修正個所の行末に修正ラベルを記述する。修正が複数あったら修正したすべての行に記述する。関数単位で修正した場合は関数のコメント部に記述する。ラベルの書式は、日付に修正番号を付加したものとし、例を次に示す。


//A = B + C;
A = B - C; // 20030815-1

修正番号を付加することにより各修正個所を特定することが可能になるので、プロジェクトフォルダ内に"UpdateHistry.txt"を作成し、その中にその修正についての情報を記載する。その書式例を次に示す。


●20030815-1
（現象）
部品配置を一度も行っていない図面に対して部品確認を行うと不正な部品（B-、P-など）が集計される。

（原因）
ドローイングヘッダに入っている部品配置情報を取得する共通モジュールでは以下の処理をしていた。
(1) ドローイングヘッダに部品配置情報が見つかった場合はその部品情報を返す。
(2) 見つからなかった場合は、部品情報の有効列数は1、WDHは空で初期化して返す。

今回の場合は(2)の処理になるため、不正な部品が集計された。

（修正方法）
(1) ドローイングヘッダに部品配置情報が存在するか判定する関数を追加。
    [追加関数]is_exist_place_parts_data_obj
(2) もし、部品配列情報が存在しなければクリアする関数を追加。
    [追加関数]clear_place_parts_data_obj


	↑UP	\| トップページ \| サイトマップ \| お問い合わせ \| プライバシーポリシー \|