Letzte Änderungen

2012-09-21
2012-09-17

Neueste Datei-Release

This Project Has Not Released Any Files

Wiki Guide

Seitenleiste

Roast+ コーディング規約


名前

変数名や関数名、ファイル名等は基本的に全て小文字であり、単語毎にアンダーバーで区切る。ただし例外もある。詳細については以下にて説明する。


変数名

クラスメンバ変数

変数名の先頭に「m_」を付加する。(嫌う人も多いが、Roast+ではこのルールを用いている)

グローバル変数

まずそもそもグローバル変数は使わないべきである

現在Roast+内で使っている箇所もあるが、今後無くしていく方針である。

  どうしても使用したければ、変数名の先頭に「g_」を付加する。


それ以外

共通ルール(小文字、単語毎にアンダーバー区切り)に従う。


define定数/マクロ

大文字、単語毎にアンダーバー区切りでなければならない。

ただし一部例外的に小文字を用いてよい場合もある。(後述)


ファイル名

共通ルール(小文字、単語毎にアンダーバー区切り)に従う。

特にファイル名に関しては、Windowsでは大文字小文字が区別されないため、注意しなければならない。(大文字小文字が違うだけの同ファイル名は絶対に作ってはならない)

C++ヘッダファイル

Roast+の主役であるC++ヘッダファイル名では、拡張子は「.hpp」を用いる(Cでは使用出来ない事を明示する為、.hを用いてはならない)。それ以外は共通ルールに同じである。

Cヘッダファイル

Cでも使用可能なヘッダファイルであれば、「.h」を用いる事も出来る。ただし、そのヘッダファイルがincludeしている全ての子ヘッダファイルにおいてもCで使用可能である必要がある。(includeをしているだけでも、そのincludeしているファイルが.hppであればNG)

特殊なincludeのために使われるファイル

それをincludeしただけではヘッダファイルとして成り立たない、特殊なincludeのために使われるファイルは「.hpp」をつけてはならない

基本的に拡張子はなしであるか、例えば.csvファイルであればそのままの拡張子を用いる。勝手に拡張子を創りだしてはならない。

  ごめん。今勝手な拡張子作り出してる所あるんだよね。後で直しておくよ・・・。


STLとは拡張子無しファイルの扱いが異なるので注意すること。

C++ソースファイル

基本的に(テストコードを除き)ソースファイルは無くしていく方針ではあるが、テストコードでは使用されるので説明すると、拡張子には「.cpp」を用いる。

Cソースファイル

これも無くしていく方針ではあるし、テストコードでも使用されないが、一応説明しておくと、拡張子には「.c」を用いる。

単語の省略について

単語は基本的に省略することなく記述すること。必要に応じて省略しても構わないが、省略する場合は一般的に理解される省略の仕方でなければならない。

正しい例)

  • string → str
  • buffer → buf

間違った例)

  • text → tx
  • document_serial_iterator → dsi, docseriit(なんの事だかさっぱり分からない・・・)

また、略語とした結果、誤った解釈をされるような場合も避けるべきである。

  • super_type_record → str(「string」と解釈されてしまう可能性が高い)
  • document_name_string → dns(「Domain Name System」と解釈されてしまう可能性が高い)

局所的なローカルな変数の場合

局所的なローカルな変数の場合などでは、ある程度寛容であってもよい。

例えばループ変数にi,j,k等を使ってもよい。イテレータ変数としてitと言う名前も使って良い。

ただし、これらは関数内が非常に単純で、変数名に頼らずともコードを理解できるような場合に限られる。そうでない場合には省略せずに、正しく名前を用意するべきである。


書式

インデント

インデントにはタブを用い、4タブとする。


1行の長さ

特に明確なルールは設けていない。1行何文字かに拘るよりも、コードが見やすくなることにこだわるべきである。

一般的なコンソールでは横幅が80文字であるため、これを一つの目安とするべきである。これを死守する必要はないが、これを超える行が複数に渡る場合、一部の環境では見辛くなっている事を考慮しなければならない。

個人的には、インデントを含めて60文字程度を一つの目標としている。実際にはこれを越える事も多くある。ただ、この程度の文字数を目指すことにより、コードとしても余り詰め込みすぎになっていない見やすい1行となるし、80文字を越えることも少なくなる。自然と綺麗なコードが出来上がる。

マルチバイト文字

ソースファイル上でマルチバイト文字は使ってはならない。他のOSや、他の国に持っていったときに文字化けになるだろうし、コンパイルすら通らないかも知れない。

また、そのまま上書きされたものをいざUpdateしてみたら文字化けするようになっていた・・・と泣きを見るのは自分自身である。

基本的にコメントも含め、英文とすべきである。なんちゃって英語でも構わない(現に私がそうである・・・)。

ローカルな言語をASCII文字の範囲内で記述したもの(ローマ字など)を用いても良いが、他の言語圏の人間には理解されないため極力使用しないべきである(なんちゃって英語の方がまだ理解される)。

# Excite翻訳とか、そんな程度のものでもいいよ。(ある程度補正はして欲しいけど・・・)


中括弧

中括弧は基本的に改行して記述する。

例)

  1. void hoge(bool b)
  2. {
  3. if ( b )
  4. {
  5. /*
  6. hoge
  7. */
  8. }
  9. }

関数の内容がごくごく短い場合等には、状況に応じて改行しない事も許可される。

例)

  1. void hoge(bool b){ return !b; }
  2. void huge(bool b, bool b2, bool b3, bool b4){ // 1行に書くには長すぎるため途中で改行した
  3. return ( hoge(b) && hoge(b2) && hoge(b3) && hoge(b4) ); }

中括弧の省略

if文の内容が1行しかない場合には、下手に中括弧を入れるよりも入れない方が見栄えが良い場合もあるとの判断の元に、省略することが許可される。

ただし、中括弧の省略は最も下位レベルのものに限定する事とする。中括弧を省略したif文の中で更にif文を書いたり、for文を書いたりしてはならない。

なお、for文の場合は中括弧を省略してはならない。for文はその特性上、中身が後々処理が書き足される事が多いため、1行でなくなる事が多いからである。


空白の挿入

関数宣言

  1. bool connect(const char* host, int port, int socktype=SOCK_STREAM, int family=AF_INET)
  • 復帰値と関数名との間には半角スペースを一つ
  • 型名と変数名の間には半角スペースを一つ
  • 変数と変数の間には、「カンマ、半角スペース」の順番で半角スペースを挿入
  • 関数名とカッコの間には半角スペースを挿入しない
  • カッコと引数群の間には半角スペースを挿入しない

条件式

  1. if ( node_type == T().node_type && name == T().name )
  • ifとカッコの開始の間に半角スペースを一つ
  • カッコと条件式の間には半角スペースを一つ
  • 比較演算子、論理演算子の前後には半角スペースを一つ

関数呼び出し

  1. memcpy(p_renew, old_ptr, copy_byte);
  • 変数と変数の間には、「カンマ、半角スペース」の順番で半角スペースを挿入
  • それ以外に半角スペースは挿入しない

代入演算

  1. m_size = 0;
  • イコールの前後に半角スペースを挿入

  1. return (reg >> 1) | (feedback_bit << (BIT_COUNT-1));
  • 各演算子の前後に半角スペースを挿入。ただし見栄えを考慮し、一部この限りでなくとも構わない(上記例では、「BIT_COUNT-1」を一つの優先的なかたまりと見なしているため、半角スペースを省略している)
  • カッコ内側と式との間には半角スペースは挿入しない


コードの内容

構造体かクラスか

基本的にはクラスを用いるべきである。ただし以下の2つの場合には、構造体を用いる。

  • テンプレートプログラミング等のために、publicな型のみを定義する場合。
  • メンバ変数をpublicとして、外部から直接アクセス出来る場合。

2つ目の定義は、主にC元来からの、データの受け渡しに使うような構造体である。

Roast+では更に、コンストラクタを記述し、メンバ変数を初期化してもよい。また、メソッドや、オペレータオーバーロード等を記述してもよい。PODな型でなくともよい。

ただしやはり、単なる「幾つかの値を一つの型としてまとめたもの」の範疇に留めるべきである。余りこの範疇を越えるようならば、クラスを用い、プロパティメソッドを用意することを検討した方がよい。

オペレータオーバーロード

Roast+ではオペレータオーバーロードを積極的に活用している。

ただし、基本的にその演算子の意味に合わせて使用すべきであり、厳格な意味付け無しで乱用してはならない。

詳細は別途記述する。(未稿)

多重継承

特に規制しない。と言うかむしろ積極的に活用している。

virtualなメソッド

virtualなメソッドはその呼び出しにオーバーヘッドが発生する(基本的に。発生しないとしたらそれはvirtualメソッドである意味が無い、virtualメソッドとして活用していない、と言う事になる)ので、Roast+では出来る限り避けている。ただし無理に、テンプレート引数として派生クラスを指定させ、それを継承するようなテクニックを使う必要もない(なんでもかんでもこのテクニックを用いることは、かえって問題を生み出す)。もしその部分のオーバーヘッドが問題になるようであれば、きっと有識者が正しい形へと直してくれるはずなので、まずはそっとしておいた方がよい。


ディレクトリ階層

  • include
    • roast
  • source
  • test


ヘッダ

ファイルヘッダ

クラスヘッダ

関数ヘッダ