「拡張性」(2005/12/23 (金) 23:38:28) の最新版変更点
追加された行は緑色になります。
削除された行は赤色になります。
プログラムって言うのは、現在実現しようとしている機能のみ実現できてしまえばいい、というものではないと思っている。
個人の趣味でやっている場合でも、後から機能を追加したくなったりすることはあるし、しばらくたってから自分のプログラムを見直すこともあるだろう。使ってるうちにバグを発見したりもするだろうし。
その為にも、何度も書いているけど、将来のメンテナンスと拡張性を考慮したつくりにするべきだ、と私は考えている。
ひとつは、可読性をよくすること。
なんども書いていることなので、ざっくりといくけど、
①コーディングスタイルの統一
②変数の命名方法の統一
③コメントの充実
④機能・処理ごとに関数を分ける
⑤即値を避け、極力定数を宣言する
などがある。(他にもあるだろうけど)
①~③は今まで何度か書いているのでそちら参照
④は異存のある方もいるかもしれない。関数呼び出しのオーバーヘッドが増えるのが気に入らない、一箇所からしかコールしないなら、関数に分けないでそこにコードを埋め込んでしまえばいい、など。
でも最近のコンパイラは優秀で、ちゃんとstaticなどの宣言を適切に使って関数を宣言・定義してやれば、一箇所からしかコールされていない関数などは最適化の段階でサブルーチンとしてではなく呼び出し元の箇所に展開する。
ならばソースコード上は分けておいたほうが、読みやすい。
それに、後からその機能(関数)を他で使いたくなったときにも簡単に対応ができる。
ふたつめは、できるだけロジックに頼らないこと。
具体的には、
①テーブルなどを利用して項目の追加・削除が簡単に行えるようにする
②機能・処理ごとに関数を分ける
③即値を避け、極力定数を宣言する
プログラムって言うのは、現在実現しようとしている機能のみ実現できてしまえばいい、というものではないと思っている。
個人の趣味でやっている場合でも、後から機能を追加したくなったりすることはあるし、しばらくたってから自分のプログラムを見直すこともあるだろう。使ってるうちにバグを発見したりもするだろうし。
その為にも、何度も書いているけど、将来のメンテナンスと拡張性を考慮したつくりにするべきだ、と私は考えている。
ひとつは、可読性をよくすること。
ざっくりといくけど、
①コーディングスタイルの統一
②変数の命名方法の統一
③コメントの充実
④機能・処理ごとに関数を分ける
⑤即値を避け、極力定数を宣言する
などがある。(他にもあるだろうけど)
①~③は今まで何度か書いているのでそちら参照
④は異存のある方もいるかもしれない。関数呼び出しのオーバーヘッドが増えるのが気に入らない、一箇所からしかコールしないなら、関数に分けないでそこにコードを埋め込んでしまえばいい、など。
でも最近のコンパイラは優秀で、ちゃんとstaticなどの宣言を適切に使って関数を宣言・定義してやれば、一箇所からしかコールされていない関数などは最適化の段階でサブルーチンとしてではなく呼び出し元の箇所に展開する。
ならばソースコード上は分けておいたほうが、読みやすい。
それに、後からその機能(関数)を他で使いたくなったときにも簡単に対応ができる。
ふたつめは、できるだけロジックに頼らないこと。
具体的には、
①テーブルなどを利用する
②機能・処理ごとに関数を分ける
③即値を避け、極力定数を宣言する
④引数をchar*を使う
①は、テーブルに項目の追加・削除をすることで処理の追加が簡単に行えるようにする。
②、③は可読性とともにロジックを避けるのにも役に立つ。
②の場合は可読性の話の最後でも言ったけど「部品」を使いまわすことができる。③は、定数にしておけば即値よりも意味がわかりやすい上に、ソースコード上の同じ意味を持つ数値を一気に変更できる。
④は、処理を振り分ける上位の関数などの場合。
引数でデータを渡そうとするとき、ある決まった型の変数や構造体を渡してしまうと、変更が利かなくなってしまう。
charのポインタを引数とすることで、キャストして拡張された構造体としてもアクセスできるし既存の構造体や型としてもアクセスできるようにすれば、処理を追加するときに容易であるし、既存の処理と拡張した処理で処理の流れに差異がなくなる。
charのポインタを渡すのはもちろん、C言語で一番最小単位の型だから(厳密には規格にそんな文言はないけど)
見やすく、拡張性の高いプログラムを、目指しましょう。それがタフなプログラムを作るコツだと思います。
表示オプション
横に並べて表示:
変化行の前後のみ表示: