プログラマ専用SNS ミクプラ

プログラムを作る時に、ソースファイル、ヘッダファイル等を分けますが、
これは機能ごとに分ける、で良いのだろうか。等、プログラム制作時の
守っておくほうがよい共通のルールを詳しく知りたいなと思っております。
（専門や仕事でなく、独学なため、熟練の方はどうなのかが気になるため）

たとえば、上記のように、
1, .cpp .hを分ける際の基準。機能の規模等なのか

2, 配列でも構造体でも、メモリ割り当て、初期化、メモリ解放　の順が必須だと考えていますが実際どうなのか。

3,　関数や変数名はなにか心がける規則があるのか。大文字小文字等。

これは今思いついたことですので、この３つやそれ以外にも、
もしよければ詳しく教えていただけたらと思います。

熟練レベルではありませんが、個人的には以下のような感じです。

> 1, .cpp .hを分ける際の基準。機能の規模等なのか

機能ごとに分割します。
ソースコードの分量はあまり気にしません。
＃機能分割を見直さなければならない兆候かも知れませんが。

> 2, 配列でも構造体でも、メモリ割り当て、初期化、メモリ解放　の順が必須だと考えていますが実際どうなのか。

動的に確保する必要がある場合は必須だと思います。
初期化に関しては、静的に確保する場合でも必須だと思います。

> 3,　関数や変数名はなにか心がける規則があるのか。大文字小文字等。

絶対的な規則はありません。同じ規則で終始一貫させるとこが重要です。

返信ありがとうございます。
参考にさせていただきます。

1, .cpp .hを分ける際の基準。機能の規模等なのか

機能と規模ですね。
まず機能で分けて、それでも大きければサブ機能に分けます。
使い回しを考えて最初からサブ機能に分ける場合もあります。

2, 配列でも構造体でも、メモリ割り当て、初期化、メモリ解放　の順が必須だと考えていますが実際どうなのか。

そうしないとまともに動かないと思います。

3,　関数や変数名はなにか心がける規則があるのか。大文字小文字等。

ハンガリアン記法（細かすぎて最近は嫌われている）とか色々とありますが、ルールはご自身で決めてください。そして出来るだけ守ることが大切です。

プログラムの分割や構造に関しては「構造化プログラミング」が参考になると思います。その他に関してはコーディング規約と呼ばれるものです。
オブジェクト指向設計の前に知っておいて欲しいですね。

「構造化プログラミング - Wikipedia」
http://ja.wikipedia.org/wiki/%E6%A7%8B% ... 3%E3%82%B0
「構造化プログラミング」
http://www2.cc.niigata-u.ac.jp/~takeuch ... cture.html
「構造化プログラミングを知らない子供たち - 新・日々録 by TRASH BOX@Eel」
http://d.hatena.ne.jp/eel3/20090629/1246276396


人や会社、チームによって変わるコーディング規約の色々。
「コーディング規約」
http://www.geocities.jp/bleis_tift/cpp/codingrule.html
「コーディング規約メモ」
http://www.6809.net/tenk/html/prog/cstyl_ex.htm
「GNU コーディング規約」
http://www.sra.co.jp/wingnut/standards-j_toc.html

詳細な解答感謝です。
「構造化プログラミング」は恥ずかしながら知りませんでした。
各ＵＲＬとも参考にします。

答えてみます。

1, .cpp .hを分ける際の基準。機能の規模等なのか
僕はクラスであれば定義(h)と実装(cpp)で分けます。
他のcppには絶対に共通で１つのヘッダをインクルードして、
他は複数のcppにまたがって必要なヘッダがない限りはヘッダは使用していません。

チームで作るのであればチームの方針を基準に、
自分だけが触るならば自分が一番分かりやすいと感じる分け方で良いと思います。
これは試行して色々試すしかないと思います。

2, 配列でも構造体でも、メモリ割り当て、初期化、メモリ解放　の順が必須だと考えていますが実際どうなのか。
最近ではメモリが膨大な事とプログラム終了時に開放される特性から
生成と解放全てを対にしないでも良いような考え方もあるみたいですが、
僕はなるべく作ったメモリは責任持って解放するようにした方が良いと思います。

3,　関数や変数名はなにか心がける規則があるのか。大文字小文字等。
僕はハンガリアン＋キャメルケースでやっています。
ハンガリアンは公式というより自分の分かりやすいように頭に付けています。
これも自分が一番ピンとくるのが一番かと思います。
ただ、語句の統一は意識した方が良いですね。「Count・Cnt」「Idx・Index」みたいなものなど
まばらに存在していると「書き直したくなる病」が発生します。

ありがとうございます。
ヘッダは共通のひとつ、は私もシンプルでいいなと思っております。
メモリ関係はみなさま大切だとのことで、より意識してみようと思います。

ハンガリアン等、記法はこれから勉強してみます。


みなさまの解答感謝します。もう少し、待ってみて
時間がたってから解決済みにさせていただきます。

> 1, .cpp .hを分ける際の基準。機能の規模等なのか

第一に、別の翻訳単位に公開するかどうかで分けます。
第二に、言語仕様上の制約から、分けざるを得ないものを分けます。

インライン関数やテンプレートとして定義する場合、基本的にはヘッダファイルに記述するしかありません。
しかし、それらの定義を単一の翻訳単位でしか使わないのであれば、ヘッダファイルに記述する必要はありません（要するに.cppに記述できる）。場合によっては、ヘッダファイルに記述すべきではないでしょう。

インライン関数やテンプレートではない関数や非局所オブジェクトの定義の場合、ヘッダファイルに記述することは言語仕様上無理があります。
こうした場合は、ヘッダファイル以外（要するに.cpp）に記述せざるを得ません。

> 2, 配列でも構造体でも、メモリ割り当て、初期化、メモリ解放　の順が必須だと考えていますが実際どうなのか。

可能であれば、それらを意識しなくてもよい構造にします。
メモリ割付け/解放は、ライブラリ内部に隠蔽することで、クライアントコードが直接制御しなくてもよくなります。
初期化もコンストラクタで確実に行うことで、やはりクライアントコードが特別な初期化関数を呼び出さなくてもよくなります。

つまり、ライブラリを作るのであれば当然それらは意識すべきですが、末端のアプリケーションレベルではそうした低水準の操作は不要になるように設計すべきです。

> 3,　関数や変数名はなにか心がける規則があるのか。大文字小文字等。

一貫性を持たせることが第一です。
同じ意味を指すには同じ用語を使うのが最低条件かと思います。

たかぎさん、ありがとうございます。

未熟ものですので、「翻訳単位」「クライアントコード」
の２単語が初見で、グーグルを使って調べて定義をみても、
使いどころ、なんのことをさしているのかが
よくわかりません。よろしければ、少し具体的に教えてくださると
幸いです。自分でも調べてみます。

「一貫性」、記法も合わせて、一貫した自分のやりやすい方法を
作ってみます。

> 「翻訳単位」

翻訳単位の概念が分からないと、

> 1, .cpp .hを分ける際の基準。機能の規模等なのか

この問題について正しい判断をすることは無理だと思います。
翻訳単位というのは、ソースファイルとそこから#include指令で取り込むヘッダやソースファイルをひっくるめた単位です。
大多数の処理系では、翻訳単位ひとつにつき、ひとつのオブジェクトファイルが生成されることになります。

> 「クライアントコード」

簡単にいえば、クラスとかライブラリを利用するソースコードのことです。

例えば、文字列を扱うにはstd::basic_stringクラステンプレートを使いますよね。
このクラス（テンプレート）では、コンストラクタでメモリの割付けと初期化を行い、デストラクタでメモリの解放を行います。
std::basic_stringを使うクライアントコードでは、自分でメモリの割付け/解放や初期化を自分で操作する必要がありません。
生のnew/deleteやmalloc/freeを使う機会というのはそう多くなく、特に末端のアプリケーションではほとんど使うことはありませんし、そうすべきです。

何度も本当にありがとうございます。
とても勉強になります。

翻訳単位は理解できました。

クライアントコードは例えば、
Ａのクライアントコードなら
Ａを使ってるソース、コードですね。
顧客（クライアント）の名の通り。

しかしながら、入門書や、参考書だと、new,delete,malloc,freeの類を
使ってるのをよくみるため、最後の使うべきでない。が
しっくりきません。

クラス単位で扱うならば、コンストラクタ、デストラクタで割り当て/解放
するのはわかります。しかし、配列を使う場合には割り当て/解放が必要で、
配列を多く使った場合には、割り当て/解放は多くならないのでしょうか。

自分はC++にてゲームプログラミングを試みています。すると自然配列を多く使います。
プログラム終了時に解放されるのだろうかどうかもいまいち把握しておりません。

末端のアプリケーションとはどの段階をいうのでしょうか？
例えば、Dxlibを仕様しているプログラム自体は「末端」ということで
良いのでしょうか？

> 配列を使う場合には割り当て/解放が必要で、
> 配列を多く使った場合には、割り当て/解放は多くならないのでしょうか。

静的記憶域期間または自動記憶域期間を持つ配列の場合は、確かに割付け/解放は行われますが、これは処理系が勝手に行うので、プログラマが意識する必要はありませんね。
それ以外については、生のnewやmallocで割付けるのではなく、std::basic_stringやstd::vector、あるいは他のコンテナを使えばよいので、直接割付け/解放を行う必要はほとんどありません。固定長の配列でよいのであれば、std::tr1::arrayを使うこともできます。

> 末端のアプリケーションとはどの段階をいうのでしょうか？
> 例えば、Dxlibを仕様しているプログラム自体は「末端」ということで
> 良いのでしょうか？

DXライブラリを使っているかどうかは問題ではありません。
ライブラリやフレームワーク、ミドルウェア、デバイスドライバなどを自分で作るのでなければ、末端のアプリケーションのみを扱っていると考えてよいでしょう。

たかぎさん、再度詳しくありがとうございます。

みなさんの解答のバックアップをとっておいて、
参考にしながら精進していこうと思います。

ありがとうございました。