ファイル分割(構造体・関数)の分け方

Question

初歩的な質問になってしまうのですが、ファイル分割の際に構造体と関数をヘッダファイルとソースファイルをどのように分割すればいいのか分かりません。
例えば

1.車の構造体
2.車を描画する関数
3.車を移動させる関数
4.車を大きくする関数

などがあるとすると、↑の4つをどのようにファイル分割すればいいのでしょうか？
いままでは下の3つの方法を試して、最近では基本的に2つ目のやりかたでやっているのですが、どれが正しいのでしょうか？
構造体をほかのファイルに分割しておけば、新しいenemyCar.h・enemyCar.cなどのファイルを作ったときに使用できると考えたのですが、構造体をわざわざほかのファイルに分割する必要はないのでしょうか？
それと、どこからがファイル分割をする際の境界になるのかが分かりません。
例えば、1～4の敵バージョンを作った際にヘッダファイルも同様にenemyCar.h・enemyCar.cなど新しく作ってcar.h・car.cとは別に宣言・定義したほうがいいのか、
それとも、car.hとcar.cにそのまま宣言すればいいのか、
車は車で、構造体も全て、car.h・car.cで定義・宣言すればいいのか分かりません。

ファイル分割する際のポイントやおすすめのサイトなどがあれば教えていただければ幸いです<(_ _)>

1つ目
carDatabese.h ----- 1　構造体宣言
car.h ----- 2・3・4　宣言
car.c ----- 2・3・4　定義
main.c

2つ目
car.h ----- 1・2・3・4　宣言
car.c ----- 2・3・4　定義
main.c

3つ目
car.h ----- 2・3・4　宣言
car.c ----- 1・2・3・4　定義
main.c

Comments

[actorbug]

構造体の「宣言」と「定義」とを、どのような意味で使い分けていますか。
「宣言」と「定義」がともに struct Car { int x; }; の意味なら、3つ目がコンパイルできません。
(3つ目の car.h に暗黙的に struct Car; が含まれているという意味かもしれませんが)
「宣言」が struct Car; 「定義」が struct Car { int x; }; の意味だと、すべてコンパイルできません。

Answer 1

構造体をわざわざほかのファイルに分割する必要はないのでしょうか？

それと、どこからがファイル分割をする際の境界になるのかが分かりません。

なんだろう，話が全体的におかしい気がします．

単一のソースファイルに何から何まで全て書けばいいじゃないですか．
例えば，main.c に全て書けばいい．

なのに，分割する，と．
一か所に書けばコンパイルが通ってプログラムが無事に動くのに，あえてコードに手を入れる，と．

それは　なぜなのか？　何のためなのか？

そこには　分割｛する/したい/しなきゃならない｝理由があるハズ．
→だったら，その理由に従って分ければいい．

逆に言えば，理由に無い分割はしなければいい．

だから，「わざわざ」とか見えることはあなたには必要ないのだし，
「どこで分けるか？」なんて話は分けようと思った時点で（その理由から）自明である．

Answer 2

誰がソースファイル(.c)を読み、誰がインクルードファイル(.h)を読むかをよく考えてください。

• ソースファイルとインクルードファイルを読むのが現時点のhiru.jp3さんだけの場合。

つまり、将来修正や機能追加するつもりがない場合。
どーでもいいです。書き殴っておけばいいでしょう。

• ソースファイルとインクルードファイルを読むのが未来を含むhiru.jp3さんだけの場合。

つまり、他の人には見せるつもりがなくて、将来修正や機能追加するつもりがある場合
記憶力が良ければ工夫する必要はありません。
3ヶ月後に自分が書いたことを覚えておけないのであれば自分に分かるように分けましょう。

作成したものを別のアプリで使う場合
経験でいうと、どういうことを想定してプログラム分割しておいても、別目的で使う場合は不満が出る場合が多いです。適当に分けておきましょう。別のアプリで使う場合は、その時点で最適と思う分割に変えるのが楽です。そして今のアプリは、次に改版するときに新しく分割したコードを使うようにしましょう。
つまり、必要に迫られる前に分割するのではなく、プログラミングの経験と歴史に従ってプログラム分割を進化させた方がよいという意味です。

• ソースファイルとインクルードファイルを読むのがhiru.jp3さんの共同開発者の場合。

つまり、チームでプログラムを開発している場合。
作業分担を考慮して、チームで話し合いましょう。

• インクルードファイルを読むのが不特定多数の場合。

つまり、ライブラリとして広く公開する場合

インタフェースを変えられないので、その設計に十分時間をかける必要があります。
場合によってはコーディングよりもこちらに時間がかかることもあります。

Comments

[hiru.jp]

ppaulさんご返答ありがとうございます！
今まで、ファイル分割のやり方みたいのがあって、それに沿ってファイルを分割しないと、後々エラーが起きてしまったり、見にくくなってしまったりしてしまうかもしれないと、ファイル分割の時点でいろいろ悩んでしまっていましたが、結局は自分のわかりやすいように、また、誰かに公開する場合には、見る人が読みやすいようにすればいいんですね！
モヤモヤがすっきりした気がします！
ありがとうございましたʅ（◞‿◟）ʃ

Answer 3

基本的には『仕様による』ですね。

[定義]

1.車の構造体
2.車を描画する関数
3.車を移動させる関数
4.車を大きくする関数

という定義で、

1つ目
carDatabese.h ----- 1　構造体宣言
car.h ----- 2・3・4　宣言
car.c ----- 2・3・4　定義
main.c

2つ目
car.h ----- 1・2・3・4　宣言
car.c ----- 2・3・4　定義
main.c

3つ目
car.h ----- 2・3・4　宣言
car.c ----- 1・2・3・4　定義
main.c

であれば、

３つ目は『特定の関数内でしか使わない場合』ですね。

例えば2〜4のどれかの中だけとか。

つまり、car.c内でしか使わず、引数や戻り値等では使えないです。

見える範囲を考えるとわかるはずです。

そういう風に定義や仕様によります。

Comments

[hiru.jp]

BeatStarさんご返答ありがとうございます！
BeatStarさんがおっしゃった、３つ目は『特定の関数内でしか使わない場合』は確かに言われてみればそうだなと思いました。
自分なりに色々模索してファイル分割していきたいと思います！
ありがとうございましたʅ（◞‿◟）ʃ

Answer 4

こればっかりは、あなたなりにいろいろやってみて、あなたなりの解答を見つけるしかないです

構造体をほかのファイルに分割しておけば、新しいenemyCar.h・enemyCar.cなどのファイルを作ったときに使用できると考えたのですが

つくるときには、こういう場合も使えるようにしよう、といろいろ考えてやるんですが、それが実際に役に立つことは、、、めったに無いですね

Comments

[hiru.jp]

y_waiwaiさんご返答ありがとうございました！
いままでファイル分割の型みたいなものに当てはめようと、ファイル分割をしてて、その型みたいなものをネットなどで調べながらやっていたのですが、納得できるものがなく、ファイル分割の時点で色々悩んでしまっていましたが、y_waiwaiさんがおっしゃった、「あなたなりの解答を見つけるしかないです」でモヤモヤがスッキリしました。
これからは自分が納得いく(見やすい)ようにファイル分割していきたいと思います！
ありがとうございましたʅ（◞‿◟）ʃ