1. コーディングスタイル
～美しいコードとは～ C言語Ver.
藤岡 光

2. 美しいソースコードとは
ソースコードの美しさとは時と場合によりさまざまな解釈の仕方がありますが、ロボ部のように
他人と共同開発する場合の美しさの定義は次の条件を満たしたコードであると考えられる。
• 可読性が良い
• メンテナンスしやすい
• 効率が良い
• シンプルである
などです。一言で言えば
美しいソースコードとは可読性を優位した効率の良いソースコードである！

3. なぜ美しく書く必要があるのか
一人で実験をする場合は必要ありません。自分ひとりしか見ないのならバグがなく正しく動きさ
えすればそれでいいです。しかしロボ部の場合、コードは他人に見られます。共同で開発したり、
プロジェクトを途中で引き継いだり、他人の作ったモジュールをアップグレードしたりします。
そのとき読みにくい、汚い、理解しずらいコードだと作業効率が悪くなり、バグの発生の原因に
なります。
また、可読性がよくメンテナンスがしやすいコードは移植性も良いのでコピペしたあとの手直しが
少なくなります。
なので、他人に見られることを意識してエレガントなコードを書きましょう。

4. 可読性とは
可読性とは読みやすさのことです。可読性のよいプログラムは読みやすく理解しやすいです。
 コメントを書く
ただむやみにコメントを書いてはいけません。コメントはそのコードの意図を表現するためのものです。
• 意図が表現されていること。
• 意図の理解が容易であること。
• 意図以外の記述が少ないこと。
• How (どうやってやるか) でなく What (何をやるか) が記述されていること。
• できれば、Why (なぜやるか) も記述されていること。
を意識しましょう。

5.  関数、構造体が単一責務であり、的確に記述されている
関数や構造体も適当に作ってはいけません。
• (関数や構造体や変数などの) プログラムの単位が唯一の仕事を記述していること。
• 且つ、(なるべくなら) その仕事がそのプログラム単位内で記述されつくされていること。(＝高凝集:
high cohesion)
• 同じ意図のものが重複して書かれていないこと。
• メソッド内が同じ抽象度の記述の集まりで構成されていること。
• メソッド内が、自然な粒度で記述されていること。 (話し言葉のように)
• ほどよい量 (記述が多過ぎない)
めんどいからあまり書かないけど構造化プログラミング、オブジェクト指向などを勉強してください。
C言語にはクラスがないのでインヘリタンス（継承）やポリモフィズム（多様性）を実現するのは難しい
（共用体、構造体、関数ポインタを駆使すれば出来ないこともない）けどカプセル化（実装とデータの
隠蔽）は実現できるのでがんばってください。(構造体を使いこなせるようになりましょう)
※インターフェースの意味が分かれば結構きれいな関数を作れるようになると思います。

6.  変数や関数をぱっと見で分かるように命名する
例えば a, b, c, tmp ,temp, foo, bar, hoge, piyo などの何のデータが入っているのか分からない
名前はやめましょう。 for文などのループ変数はi, j ,kなどの簡単なのでOKです。おすすめの命名規則
を紹介します。
キャメルケース
• アッパーキャメルケース（UCC）
複合語の先頭を、大文字で書き始める。主にtypedefの型名や構造体名に使うとよい。
例 typedef int HogeHoge; struct HogePiyo;
• ローワーキャメルケース（LCC）
複合語の先頭を、小文字で書き始める。主に変数名に使うとよい。
例 int hoheHoge; char piyoPiyo;
• スネークキャメルケース
アンダースコア“_”を区切記号として単語をつなげる。主に関数名に使うと良い。
例 int func_foo_bar(int a, int b);

7. ハンガリアン記法
ハンガリアン記法とは、変数名や関数名などに特別な接頭文字、または接尾文字をつけることで、他の
人がその識別子を見たときに、識別子の使用方法・データ型情報・スコープ範囲などを分かるようにする
ための命名法である。
• システムハンガリアン記法
システムハンガリアンとは変数名などを命名するときに、先頭に変数型を示すプレフィックスを書くように
する記法です。
例 int iHoge; char cPiyo; char *strFoo; unsigned int uiBar; int *piHogeHoge
ググったら分かりますがシステムハンガリアンは現在批判されることが多く、.NET Frameworkでは使わ
れていないそうです。
しかしポインタのプレフィクスの ’p’ や char * の ‘str’ は結構便利です。

8. • アプリケーションハンガリアン記法
アプリケーションハンガリアンは、間違えたコードを間違えて見えるようにする記法である。
たとえば、相対座標にRelative Positionのrp、絶対座標にAbsolute Positionのapというプレフィッ
クスとした場合、ウィンドウの位置を設定する window.SetPosition(rpX, apY); のような記述は明
確に誤りであることがわかる。
また、ドルにプレフィックスdol、円にプレフィックスyenとした場合、dolIncome + yenDeposit のよう
な計算は間違いであることが明確である。
このように、間違えているコードを間違えているように見えるように記述するのが元々のハンガリアン記法で
ある。
ここのサイトが丁寧に説明してくれているので読むべし。
(間違ったコードは間違って見えるようにする)

9. プログラムの例
これから片方向リストのプログラム例を使ってオブジェクト指向？のすばらしさを紹介します。
• 保守性のかけらもないゴミカスコード例 (list1_main.c)
• だいぶましになったコード例（list2_main.c, list2.h, list2.c）
だいぶましになったけどコンテナを変更（片方向リストから双方向リストや2分木などへ変更）
しようとすると、コード全体を書き換えなければならない。
• この中では一番保守性が高いコード例（list3_main.c, list3.h, list3.c）
コンテナを変更するときでも書き換える場所は変数の宣言部分だけですむ。