プログラムを書くときの決まり事
集団で共通，もしくは共有のプログラムを書くときに，いくつかの決まり事を決めておくと，混乱が少なく理解が早まります．
そこで，ここではいくつかのプログラムを書くときの決まり事を紹介しておきます．
また，やってはいけない禁じ手等も掲載していきます．
このページは今な亡き，「C Magazine」のプログラミングの禁じ手Web版 C言語編，C++編を一部参考にしています．
Contents
命名規則
変数や関数の名前の決め方についての参考例を述べたいと思います．
これは，あくまで個人的に決めているものであり，最適であるかは分かりません．
変数
変数名は基本的に小文字で表現します．つまり
int count;
float ans;
MyClass my_class; // クラスのインスタンス
などです．
また，これは私はあまり使っていませんが，
ポインタは「p」，参照は「r」，グローバル変数は「g」
をつけたりする習慣もあるようです．
関数
関数名は大文字から始めます．
void Function();
int Clear();
とかです．
また，単語が並んでいるような名前は単語の頭を大文字にします．
個人的にはアンダースコアはあまり好きではありません．
void GetValue();
int AddText();
などです．
一般的には，最初は小文字でその後から大文字というのもあります．
void getValue();
int addText();
とか．
型，構造体，クラス
構造体やクラス名などは，基本大文字から始めます．
また関数命名規則と同じく，単語の頭は大文字とします．
class PrintString;
struct DataPoint;
などなど．
ヘッダファイルの書き方
ヘッダファイルを書くときとの決まり事について説明します．
例えば以下のようなヘッダファイルがあるとします．
//
// sample.h
//
void FunctionA(); // 関数の宣言
void FunctionB();
さて，このヘッダファイルが複数のソースでインクルードされている場合を考えます．
例えば，
//
// main.h
//
#include "sample.h"
...
--------------------
//
// main.cpp
//
#include "main.h"
#include "sample.h"
...
int main(){
...
}
という2つのファイルがあるとします．
つまり，最終的なmain関数のあるファイルから見ると「sample.h」が2回インクルードされていることなります．
これをコンパイルすると
error: redefinition of ‘void FunctionA()’
error: ‘void FunctionA()’ previously defined here
...
とコンパイラにおこられます．
このエラーは「main.cpp」の5行目の「#include "sample.h"」の時点で「FunctionA」はすでに定義されていますという風にいっているのです．
つまり，同じ関数が2回定義されているということです．
これは分割コンパイルするようになると，よく出てくる問題です
さて，このような問題が起こらないようにするための方法があり，ヘッダファイルをつくるときは必ず行う必要があります．
先程のヘッダファイルは次のように変更します．
//
// sample.h
//
#ifndef _SAMPLE_H // もし「_SAMPLE_H」が定義されていなければ
#define _SAMPLE_H // 「_SAMPLE_H」を定義する
void FunctionA(); // 関数の宣言
void FunctionB();
#endif // _SAMPLE_H
// このヘッダファイルを以前読み込んで入れば，「_SAMPLE_H」が定義されていて，
// 関数の定義がされないようになる
このようにすることで，関数の宣言が重ならないようになります．
「_SAMPLE_H」の名前は，ヘッダファイルの名前にちなんだものにしておけば大丈夫でしょう．
コメント
コメントは重要です．
しかし，コメントの入れ方にも気をつけるべき点がいくつかありますので，注意しましょう．
コメントがない
怠慢はいけません
プログラムの理解を遅くすることになります．
また，たとえ自分が書いたプログラムでも1週間そのプログラムを見なかったら，もうそのソースは他人が書いたのに等しいです．
このようなときにもコメントの存在はありがたいものとなります．
コメントの量は沢山あればそれにこした事はありません．
およそ，プログラムコードの倍の量があれば十分と言えます．
とにかく，コメントはこまめに入れるようにしましょう．
コメントが嘘
これは，コメントの内容とプログラムが一致しない場合です．
たとえば，プログラムを一部変更したにもかかわらず，コメントは古いままなどの場合です．
注意が必要です．
コメントが英語
これは難しい問題です．
しっかりとした英語であれば問題ないのですが，ニセ英語のようなもので書かれていた場合，そのコメントが意味不明になる場合があるからです．
そのことから，コメントはなるべく日本語がいいと思います．
しかし，できればしっかりとした英語で書かれている方が望ましい場合もあります．
それは日本語の場合，プログラムソースのエンコードによって文字化けする場合があるからです．
これをなるべく生じさせないために，英語で書いてある方がいい場合もあります．
英語で書かれている場合，たいてい文字化けする事はありません．
プログラムにインデントをつけない
非常に見づらいプログラムになりますので，絶対に避けるべきです．
読みづらいという事は，プログラムの理解を妨げ，間違った認識を指定し舞う可能性があるという事です．
ですので，かならずインデントはつけましょう．
コンパイル時のWarningを無視する
コンパイルエラーでなければ問題ないと考えて，無視している人が多く見られます．
しかしこれは，後々どんな問題を引き起こすか分からないので危険です．
基本的には，警告はなくすようにプログラムを書きましょう
一般に，コンパイル時にコンパイルオプションに「-Wall」をつけて，の警告レベルを最大にし，すべての警告をすべて出力するようにしましょう．
そして，その全ての警告をなくすようにしましょう．
最終更新：2010年12月03日 13:00
