メモリ確保は一箇所に纏める派
プログラムで処理を行うときには、当然処理の対象となるデータが必要となります。
ん？逆か、
処理したいデータが有るからプログラムで処理するのか。
まあいいや
まあそんなデータなんですが、処理の近くで確保する派とどっかに纏める派がいると思っています。
ちなみに私はどっかに纏める派です。
とくにメインルーチンと実処理の間に、必ず一枚ラッパを噛ませて、ラッパ冒頭で使用するデータやクラスのインスタンスを纏めて確保、実処理に引数で渡して実処理抜けてきたら問答無用で全削除、という設計でリソースリークを防ぐ方に振り切っています。
また、ミューテックスなどのそもそもグローバルに置かなければ動かない、といったたぐいの物以外は死んでもグローバルには定義しない主義です。
利点としてはリソースやデータの管理が楽になること、
欠点としては、リソースやデータを把握していないと深い処理は作り込みにくいことでしょうか。
関数ポインタ大好き、っていうかポインタが好き
関数ポインタ大好きで多用します。
特に一連の処理は同じ戻り型の関数ポインタで定義も統一してしまい、Listコンテナに実行順に登録、パラメータはそれぞれ必要なものを全部纏めて構造体を作り、それをVoidポインタで受け渡す。
と言うような組み方をします。
ちょうどチェインオブレスポンシビリティパターンのような感じ。
処理が引数で渡された内容に対するもので完結するので、後からメモリ確保タイミングを組み替えてスレッドセーフな関数としても作り変えやすいのも大きな利点です。
なによりリストにスタックした順で処理の流れが一目瞭然ですし。
同時に読み慣れないと解りにくいというか、私の書いたコードを他の人が理解して改造するのがそこそこ難しいらしいので、そのあたりは頑張って平易に書く努力はシてるんですけどね。
困ったらジャンプテーブル
関数ポインタ好きっていうところでピンときた方もいるかもしれないですが、コマンド解析だったり場合分けだったりその他もろもろの処理は、関数ポインタをメンバにもつmapコンテナを多用したジャンプテーブルでダダっと組んでしまうのが好きです。
スイッチ文とか、私が組むプログラムに出てくることほぼないんじゃないかな。。。
当然組み込み分野のものを書くときはmapコンテナなんて使えない場合が多いので、そのときは関数ポインタの配列とか、手組みでリスト構造作ったりシて対応してます。
命名はしっかり略さず！
基本変数名関数名は略しません、だって今ごろのエディタって大抵コード補完がついてますからね、hoge_valとか書くよりはvalue_to_hogeほげをするための値とか説明的に書いたほうが、後々忘れなくていいし、いちいち不要なコメントでソースを汚すこともないですし。
継承包含は最後の手段
クラス同士はなるべく関連付けません。
他の人が読めなくなったりミスしたりすることにつながるので。。。
特に継承は、あっちではこの継承の同盟関数、こっちでは継承の同盟関数、え、個々で呼んでるのはどっち？
なんて状況が往々にして発生するので。
自分のプライベートプロジェクト以外じゃまず使わないですね。
最後に
皆様はどうでしょうか？
こういったプログラムの癖は、その人が働いてきた環境によっても形作られ方が異なってきます。
もちろん受け入れられる受け入れられないはありますが、
何が優れていて何が間違いなんて言うこともないと思うので、
色んな人の流派を聞いて、見て、色々勉強していけたらなぁと思う毎日です。
投稿
0 件のコメント:
コメントを投稿