命名規則とは、プログラミングにおいて、使用する識別子等の名称を定めるためのルール集です。C言語での命名規則のポイントと実例をとりまとめてみます。
命名規則(めいめいきそく)とは、プログラミングにおいて、使用する識別子等の名称を定めるためのルール集です。主にコードの可読性を高めるために導入されます。英語では、Naming conventions。命名規則は、命名規約、ネーミング規則、ネーミング規約とも呼ばれます。
命名規則を導入すると、ソースコードの可読性を向上させることができます。識別子の名称に含まれる付随的な情報より、その識別子がどのようなものかをすぐに判断することが可能となるからです。
可読性の向上は2つのことをもたらします。1つはコードの保守性の向上です。これは、読みやすいコードはメンテナンスしやすいということです。
もう1つは、開発の効率アップです。規則に従ったコードは見た目にも美しく、気持ちよく作業ができます。また、命名規則に従ってコーディングすれば、識別子の名称の中にいろいろな情報が含まれることになります。それらの情報が不具合を未然に防ぐ手がかりとなります。コーディングした時点で不具合がわかるということは、C言語のプログラミングでは他の高級言語と比べてより重要となります。低水準な記述が可能なC言語は、解析に時間のかかる不具合を生むことが多いからです。
命名規則の導入はソフトウェアの品質の保証にもつながります。命名規則が制定され、遵守されているということは開発の管理が適切であることの証明です。逆に命名規則が制定されていない、あるいは制定されているにもかかわらず、守られていないということは適切な管理がなされていないことになります。管理が適切でなければ、ソフトウェアの品質が低いと推測できます。命名規則の制定と遵守は、コーディング規約の遵守と同様にソフトウェアの品質を保証する1つの指標といえるでしょう。
命名規則の導入には、このようなメリットがありますが、コストがかかることも事実です。ルールが厳しければコーディングにかかる時間も増えることになりますので、コスト対効果を考慮してルールを制定する必要があるでしょう。
C言語のプログラムに対する命名規則を考えるにあたり、検討しなければならないことには次のようなものがあります。
C言語の識別子の種類には次のようなものがあります。
これらの中から、プロジェクトの方針に応じてルールの対象となる識別子を選定します。また、識別子ではありませんが、開発環境のディレクトリ名、ソースファイル名等も検討の対象とするほうがよいでしょう。
識別子の名称を記述する際にどのような記法を使用するかを検討します。記法には次のものがあります。
アッパーキャメルケースは、複合語を作る際に各単語の先頭文字を大文字で記述する記法です。パスカル記法ともいいます。例えば、Pascal case exampleならPascalCaseExampleと綴る方法です。
ローワーキャメルケースは、複合語を作る際に各単語の先頭文字を大文字で記述するが、複合語の先頭だけは小文字とする記法です。キャメル記法ともいいます。例えば、Camel case exampleならcamelCaseExampleと綴ります。
スネークケースは、複合語を作る際に各単語をアンダースコアで区切る記法です。例えば、Snake case exampleなら SNAKE_CASE_EXAMPLE、あるいはsnake_case_exampleと綴る方法です。
複合語の各単語を-(ハイフン)で区切る記法はチェインケースと呼ばれます。例えば、Chain case exampleならchain-case-exampleです。しかし、この記法はC言語では文法上誤りとなりますので使用できません。
ハンガリアン記法とは、識別子の名称に、意味を持つ接頭文字や接尾文字をつける記法です。ハンガリアン記法にはアプリケーションハンガリアンとシステムハンガリアンの2種類があります。
アプリケーションハンガリアンは、その意味や使用目的から接頭文字や接尾文字を決定する方式です。例えば、rwはrowを意味する接頭文字、colはcolumnを意味する接頭文字と決め、行数ならrwNum、列数ならcolNum、行数の最大ならrwNumMax、列数の最大ならcolNumMaxというふうに識別子の名称を決定する方法です。
システムハンガリアンは、そのデータ型から接頭文字や接尾文字を決定する方式です。例えば、unsigned long型の変数名に接頭文字ulをつけるというような決め方です。
ハンガリアン記法には賛否両論あり、その採用には十分な検討が必要だと思われます。
識別子の名称に使う単語を基本的に略すのか、略さないのか、略すとしたらどう統一性を保つのか等を検討する必要があります。同じ単語なのに略したり、略さなかったり、違う略し方だったりすると、コードの統一性が失われ可読性が低下します。これを避けるためです。
まず、基本的なスタンスとして単語を略すのか、略さないのかが検討点として挙げられます。単語を略さない場合、意味が正確になるという利点がありますが、文字数が多くなるという欠点もあります。単語を略す場合の長所短所はその逆です。
また、単語を略す場合と略さない場合の基準も検討の対象となります。例えば、単語が何文字以上なら必ず略す等です。
略した場合に、開発者によって略し方が異ならないような仕組みづくりも必要です。例えば、略語一覧を制定する、単語の略し方のガイドラインを制定する、等です。
ちなみによく使われる単語の略し方には、次のパターンがあります。
以上の検討を行い、単語の略し方を定めます。もちろん命名規則の対象外とするという決定もあり得ます。
これは例えば「複数の製品に共通して使用するライブラリのソースファイル名には特定の接頭文字をつける」「特定の製品でしか使用しない関数にはその製品を示す接頭文字をつける」といったようなことです。
C言語には予約済み識別子があります。以下の2項は、C99の「7.1.3 予約済み識別子」の記載です。
このことより、アンダースコアで始まる識別子は禁止しておいたほうがよいでしょう。
MISRA-C:2012には「可視性が重複して、同じ名前空間にある識別子は、表記上明白でなければならない」というルールがあります。複数の識別子の異なる点が以下に挙げる違いだけということを避けるというルールです。
このようなルールをコーディングルールや静的解析ツールで採用しないのであれば、命名規則で紛らわしい綴りについて言及するかを検討すべきでしょう。
略語は通常全て英大文字で表現されます。例えば、ID、USAなどです。キャメル記法を採用する場合には、これらの単語をどう扱うかという問題が発生します。HDTV(高精細テレビ)とIDで例を挙げると、hoge HDTV IDをhogeHDTVIDと表現するか、hogeHdtvIdと表現するかということです。どちらの表現も一長一短あります。どちらを採用するか決めておかないと、開発者によって表現が異なるという事態が発生し、コードの統一性が損なわれます。専門用語には略語も多いので命名規則で決めておいた方がよいのではないかと思います。
以下は、簡単な命名規則のサンプルです。
省略形を作る場合は、以下の手順で行う。