人によって様々なソースコードの書き方があるようなのですが実際どのような書き方をしているのか知りたいです。・・・っといっても、細かく言い始めるとキリがなさそうなのでこれだけは絶対にしてる!とかこうしたほうが処理が速い!といったことを教えていただけると嬉しいです。書き方だけでなくファイル分割等も、何かわかりやすくするコツがあれば教えて欲しいです。自分は速度なんてあまり気にしないようにしています。そもそも、最近のPCなら多少無理しても動きますし、遅いから~って言ってる人は実際計測したのか疑問に思います。(あ、もちろんそういうことが必要な現場もあるのは知っていますよ)あとは、いろいろありますが、継承をしないってことですかね。あとは、いろいろありますが、継承をしないってことですかね。理由が気になりますね。自分の知識不足のせいです。自分のソースコードの書き方がむちゃくちゃなのは分かるのですがどうすればよいのかがわかりません。なにかキーワードがひとつでも見つかればそこから色々見つかるのではと思いとりあえず質問をさせていただきました。自分は速度なんてあまり気にしないようにしています。そもそも、最近のPCなら多少無理しても動きますし、遅いから~って言ってる人は実際計測したのか疑問に思います。確かに最近のは十分速いですもんね。綺麗でわかりやすいソースを書くことを優先したいと思います。あとは、いろいろありますが、継承をしないってことですかね。どのような問題点があるのでしょうか?多重継承の問題は沢山あったのですが継承自体はしない方がいいというものは見られませんでした。派生クラスの追加等に伴ってそれが失われてしまうことがあります(大抵そうなる)。この変数はすべての派生クラスに必要だ→こいつには必要ないな...ってことが起こるのは容易に想像できます。それなら、Interfaceを実装して、メンバ変数とかはたとえほとんどのクラスに共通でもそれぞれのクラスに書いたほうがいいと思います。これなら、不変性が証明できたとき、あとでまとめるといったこともできますしね。あとは、コンポジションやらで十分だった、ってことがおおいってのもありますね。継承をするときは、それなりの理由がある&それを人にちゃんと説明できるって時にすればいいかなーと思います。継承をするなと言い切るよりは、どうしても理由があるとき以外はするな、といったほうが良かったかもしれません。【追記】たまに勘違いされている方がいるのですが、インターフェースの実装と単なる継承は、C++では構文はたしかに同じですが、意味するところは結構違いますので、気になったらググってもらえるといろいろ情報が集まると思います。人のプログラムをまずはパクって使ってみて覚えます。こんな処理のときはこれを使うみたいな、お決まりなパターンが見えてくる気がします。自分も人のことは言えませんが極力無駄な処理を減らして保守しやすく、見やすいようにすることを心がけています。わかりやすいのは第3者が見てもわかるソースを作ることを心がけると良いと思います。最低限、インデントとコメントくらいは必要かと思います。自分で作ったプログラムでもコメントがない場合、1ヵ月後に見たらさっぱり訳がわからないこともただあります。こればっかりは自分で試行錯誤を繰り返して経験を積んでいくと良いのかと思います。無駄に継承するとかえって扱いづらいということですね。後の仕様なども考えてまず変更が無いであろう部分、かつ継承したほうが効率のいいものだけ継承を使おうと思います。人のプログラムをまずはパクって使ってみて覚えます。こんな処理のときはこれを使うみたいな、お決まりなパターンが見えてくる気がします。自分で1から作るのではなく、その作ろうとしている処理を他の人がどのように実装しているのか調べながら作っていってみます。自分も人のことは言えませんが極力無駄な処理を減らして保守しやすく、見やすいようにすることを心がけています。わかりやすいのは第3者が見てもわかるソースを作ることを心がけると良いと思います。最低限、インデントとコメントくらいは必要かと思います。自分で作ったプログラムでもコメントがない場合、1ヵ月後に見たらさっぱり訳がわからないこともただあります。処理をひと通り書き終えたら、しばらく見なおしてみるようにしてみます。いう心がけが大切なのですね。こればっかりは自分で試行錯誤を繰り返して経験を積んでいくと良いのかと思います。7年前どんだけリファクタリングするかも大事でしょうね。書きっぱなしのコードはたいてい可読性がよくありません。方針:私は仕組み・考え方を理解して欲しいので直接的なコードを回答することはまれですので、すぐコードがほしい方はその旨をご明記下さい。私以外の方と交代したいと思います(代わりの方がいる保証は出来かねます)。7年前xUnitのテストがあること。7年前わたしはできるだけ継承を使うように設計しますね。ゲームのフレームワークで、いわゆるタスク管理には継承が便利です。継承を使わないと実装できません。継承を使うときは派生クラスが基底クラスの存在を意識しなくて済むように実装します。派生クラスに必要かどうかという観点で基底クラスの実装をすることはないですし、派生クラスの実装が基底クラスに影響を与えることもないです。それ自体が必要十分に機能し、余分なものは載せない。基底クラスに限らずそうあるべきだと思います。それから、次に活かせるように完成したあともモジュール化を意識してリファクタリングに時間をかけてます。ある程度の規模のアプリケーションになると一から全部作ることはもはやないと言っていいくらいにはなってると思います。C++特有の話としては、一時オブジェクトを意識するくらいですかね。C++に限ったことではないですが、コンパイルした時点でミスに気付くように修飾子を活用するとか、コメントがなくても困らないくらい自然にコードが読めるように識別子を付けるとか。7年前<たいうち様xUnitというものがあったのですか。どんだけリファクタリングするかも大事でしょうね。書きっぱなしのコードはたいてい可読性がよくありません。後で修正することは大切なのですね。継承を使うときは派生クラスが基底クラスの存在を意識しなくて済むように実装します。派生クラスに必要かどうかという観点で基底クラスの実装をすることはないですし、派生クラスの実装が基底クラスに影響を与えることもないです。それ自体が必要十分に機能し、余分なものは載せない。基底クラスに限らずそうあるべきだと思います。基底クラスは1つの機能であり、その機能を使いたい時に呼び出しその機能以外は持たせない様にすればいいということですね。それから、次に活かせるように完成したあともモジュール化を意識してリファクタリングに時間をかけてます。ある程度の規模のアプリケーションになると一から全部作ることはもはやないと言っていいくらいにはなってると思います。テスト用にまず作って、それからリファクタリングをしっかししていこうとおもいます。C++特有の話としては、一時オブジェクトを意識するくらいですかね。C++に限ったことではないですが、コンパイルした時点でミスに気付くように修飾子を活用するとか、コメントがなくても困らないくらい自然にコードが読めるように識別子を付けるとか。その変数や関数にアクセスできる範囲を前もって考えて無駄な部分で呼び出されないようにすればいいのですね。基底クラスは1つの機能であり、その機能を使いたい時に呼び出しその機能以外は持たせない様にすればいいということですね。基底クラスは、派生クラスにとって自分自身(is-aの関係)でなければいけません。クラスには、外側に向けた実装と、内側に向けた実装があるわけですが、派生クラスが基底クラスの内側に向けた実装を利用して、外側に向けた実装(いわゆる振る舞い)をオーバーライドするのは自然です。派生クラスが基底クラスの機能を使って、基底クラスにない振る舞いを実装するのであれば、その基底クラスはただのユーティリティクラスです。基底クラスの機能を便利に使うという発想を持つことが、is-aの関係を正しく理解していないと言えると思います。その変数や関数にアクセスできる範囲を前もって考えて無駄な部分で呼び出されないようにすればいいのですね。他のスレでも話題になっていますが、あらかじめ制限をキツくしておいて、必要に応じて緩くしていきます。緩くするときには本当にそれでいいのかいったん検討します。コメントがなくてもいいというとグラフィックハンドルを代入しておく変数に[img_]をつけるといった感じでしょうか?これもしばしば話題になりますが、コード上の識別子を並べたときに、できるだけ英語として自然に読めるように変数名や関数名あらゆる名前を工夫します。工夫すると言っても一定のルールに従えばいいので慣れれば自然にできるようになると思います。able_Namesこちらのサイトにいろいろのっているみたいなのでc++の勉強をしながらここに書いてあることを理解していこうと思います。最初は制限をできるだけキツくするようにします。クラスというものを知っているというだけで正しい使い方等は知りませんでした・・・わたしも正しいと胸を張って言えるほどのものではありませんが。入門書にしばしば継承の説明として、「『動物』クラスを継承して、『犬』クラスや『猫』クラスを作る」というのがあります。間違いではないのですが、実はここに落とし穴があるのです。#プログラミング入門書というのはこういった落とし穴があちこちにあるものです。これは、『動物』という枠組みのルールできちんと成立する世界(フレームワーク)があってはじめて意味があります。『犬』『猫』の共通点を探して『動物』を作るのは設計の話で、実装の話ではありません。『動物』クラス→(継承)→『犬猫共通』クラス→(継承)→『犬』or『猫』という構成にしなければ世界が変わってしまうわけです。設計が大切だということですね。設計と実装は、頭を切り替えてきちんと切り離して考えないと、プログラムはどんどんぐちゃぐちゃになります。構造化を進めてフレームワークとしてまとめるほどの力が付けば、プログラマとしてはリーダー格になれると思います。オブジェクト指向も自然と身に付くでしょう。able_Namesこちらのサイトにいろいろのっているみたいなのでc++の勉強をしながらここに書いてあることを理解していこうと思います。それは一企業のコーディングルールなので、その企業に関係のないひとが守るべきようなものではないです。参考になるところはたくさんありますけどね。書かれている内容を鵜呑みにしないで吟味してください。今、自分のゲームにはどういう機能があり、また、それに関連する情報はどのようなものがあるのかきちんと理解し、それらを皆様の意見を参考にしながら設計していこうと思います。今のうちに実用的な力を身に着けて将来に役立つよう頑張ります。雑談スレだし私からも質問させて下さい。リファクタリングという言葉が何度も出てきてますが、xUnitによる単体テストで保護された状態で行っていますか?私の経験上では、十分設計を洗練させるためのリファクタリングには単体テストが不可欠です。満足できるリファクタリングができなかったり、デグレを起こしたりでした。内部処理に限れば単体テストを書くことが多かったです。Web系などでもUI以外の部分は単体テストが作成可能で、UIと内部処理をできるだけ分離する必要があると思うのですが。再度質問を書くと、、、1.単体テストは書ける?書いたことがある?2.有益だと思う?有益だった?3.どういう時に役に立った?どういう時に役に立ちそう?4.単体テストを書くことのディメリットは?5.単体テストなしのリファクタリングはうまくいく?いかない?こんな感じでしょうか。回答を分析して、とか何も考えていませんので、プロアマ問わず気が向いた人はてきとーに書いてくれるとうれしいです。7年前1.単体テストは書いたことがある。2.とても有益だと思う。単体と結合の区別が結構あやふやになることが多いので、テストというくくりで以降は話を進めてみる。3.簡単なバグつぶしには結構役に立った。コード量はテストを書く分、確かに増えるけどもその後のデバッグに占める時間も考えるとなかなか良い感じ。あとは、テストがしやすい設計にしようと日頃から考えることになるので、今まで適当に組んでいたところで考えたり出来る。テストが目的にはなってはいけない。4.やっぱり最初はサボリ気味。テストを書くのが億劫になってしまうことがある。ちなみに、TDDの考え方では、テストを失敗させる→動くようにする→リファクタリングってサイクルを早く回すような考え方が黄金パターン。ここでのリファクタリングはとても重要。適当なこと言ってるかもしれないので、鵜呑みにはしないでくださいね。あと、テストを書くと、謎の自信がつくことがあります。7年前わたしは、ゲームプログラムという特殊な形態(?)のせいかもしれませんが、フレームワークを使った単体テストは行ったことがありません。プロジェクトごとの独自性が大きいので、リファクタリングも、フレームワークとして使い回せるコードの抽出が中心で、単体テストには向きません。各種ペリフェラルにアクセスするモジュールを作成しますが、基礎研究としてハードに造詣のある担当者が最初からモジュールとして設計したものを作ります。少なくともわたしが関わったプロジェクトに関しては単体テストが用意されたことはなかったですね。一年も掛からない中小規模のプロジェクトにしか関わったことがありませんが。フレームワークを使った単体テストというのは、幾つもの工程を経て出力が得られるようなシステムでは役に立つと思いますが、即応性の高いモジュールが互いに影響しながら並行動作するゲームプログラムだと使えるところがないと思うのです。私もゲーム業界では単体テストユニットを使って書いたことが無いです。昔はメモリがカツカツだったので、そんなものを入れる余地さえ残っていないことが多々ありましたね。ライブラリのテストで単体テストはテスト・ドライバを書いたりして実施してましたが単体テストユニットは使ったがなかったです。さんの言われる通り、ゲームにおいてはシーケンシャルな単体テストに通ったところで論理的整合がゲーム中で取れなくなるバグのほうが多いので余り顧みられなかったと言ったところでしょう。ゲームでxUnitを使った人がいたら私も聞いてみたいですね。方針:私は仕組み・考え方を理解して欲しいので直接的なコードを回答することはまれですので、すぐコードがほしい方はその旨をご明記下さい。私以外の方と交代したいと思います(代わりの方がいる保証は出来かねます)。書けるようにするべきだと思っています。これは演算子のオーバーロードレベルの話ですが、たとえば"関数の内積"だとか、"合成関数"とか"変換"だとかその他独特な書き方をどうやって(自分にとって)直観的に書くことができるかということを最近考えてます。(でないとあとから読めたものじゃない)まぁ人に見せるものじゃないので、別に自分が分かればいいのですが。いう記号を割り算(division)と解釈する人はいるでしょうけれど、僕はそれを直観的でないと感じるのでそうしません。7年前ゲームだと確かにバグが発生する部分までの処理が長い(?)ので単体テストは使いづらいのですかね。式を直感的に書くことはやはり大切なのですね。こまめに変数にわけたり関数化したりしてどういう計算をどのように組み合わせているのか分かりやすいようにしてみようと思います。最近は、分かりにくくするために、あえてC++で実装するということをやったりと、かなり邪道に走っています。楽な実装方法を選択すると、安易に業者変更されたりするので、自衛策としてやっています。Libraries、かつPHPで前処理とかやっていると、まず他社でメンテナンスできなくなりますから(できても安価にはならない)。世知辛い世の中になったものです。ほとんどのお客さんは、こんなことをする必要はないんですけどね。世知辛い世の中になったものです。ゲーム移植の仕事をしてて、きっちりモジュール化してるので最初の一回しか仕事が回ってこず収入が無い、というのは世知辛いと言うんでしょうかね。Javaですが、MOVA(i505)時代に移植したソースがずっと使い回されているということをひょんなことから5年後に知りました。Androidにも使い回されているんじゃないかなあ。7年前Suikabaさん、ISLeさん、softyaさん、回答ありがとうございました。良い設計にはリファクタリングが不可欠で、リファクタリングにはxUnitが不可欠という思いなのですが、かくいう私も、仕事では書けないことの方が遥かに多いです。ミクプラは自由にリンクできます。