雑記内検索 / 「拡張性」で検索した結果
-
拡張性
...将来のメンテナンスと拡張性を考慮したつくりにするべきだ、と私は考えている。 ひとつは、可読性をよくすること。 ざっくりといくけど、 ①コーディングスタイルの統一 ②変数の命名方法の統一 ③コメントの充実 ④機能・処理ごとに関数を分ける ⑤即値を避け、極力定数を宣言する などがある。(他にもあるだろうけど) ①~③は今まで何度か書いているのでそちら参照 ④は異存のある方もいるかもしれない。関数呼び出しのオーバーヘッドが増えるのが気に入らない、一箇所からしかコールしないなら、関数に分けないでそこにコードを埋め込んでしまえばいい、など。 でも最近のコンパイラは優秀で、ちゃんとstaticなどの宣言を適切に使って関数を宣言・定義してやれば、一箇所からしかコールされていない関数などは最適化の段階でサブルーチンとしてではなく呼び出し元の箇所... -
エレガントなプログラム
...う。メンテナンス性も拡張性も、感動するくらい違いますよ。ほんと。 -
メニュー
... タイミングの話 拡張性の話 取り込む話 staticな話 コンパイルの話1 コンパイルの話2:止まらぬビルド コンパイルの話3:マシン語に落ちるということ1:メモリの話 コンパイルの話4:マシン語に落ちるということ2:最適化 コンパイルの話5:マシン語に落ちるということ3:変数とスタック コンパイルの話6:コンパイラはそもそも何をやってくれるのか?? リンクの話 プリプロセッサの話 OS、というもの オブジェクト指向1 オブジェクト指向:2 オブジェクト指向:3 オブジェクト指向:番外 C言語のソースファイルの話 オブジェクト指向:番外 C言語での「再利用性」と「カプセル化」データ構造とアルゴリズム 抽象的な話 寝込んで布団の中で考えたこと こんなの、常識?? お仕事プログラミング ソフトでハードなプ... -
オブジェクト指向1
...容易) ②コードの拡張性・再利用性が高い あたりが大きいのではないでしょうか。 これらは確かに大きな利点ではあるのですが、これらの利点が生かされる局面というのは大規模な開発に限定されると思うのです。小規模な開発においては、オブジェクトという抽象的名概念によって余計にシステム全体の見通しが悪くなったりしてしまいます。 つまり、オブジェクト指向プログラミングの使いどころとしては、具体的な処理をいちいち把握できないような大掛かりな場面において、抽象的な「オブジェクト」という単位で状態および機能を把握する、という使い方です。 何でもかんでも「オブジェクト指向だ」ではなく、ターゲットに応じたパラダイムの選択肢の一つ、と考えたほうが正しいと私は思います。 -
数値 - 危険物取り扱い注意
コンピュータの中では、数値はすべて2進数で表されるのでした。 そして、負数は最上位bitがOnとなった、2の補数表記で表されるのでした。 では、例えば signed char c; signed int i; c = -1;/* 0xff */ i = c; のようなコードを書いた場合、どうなるのでしょう。 32bit環境ならば、当然intは32bitです。残りの24bitはどうやって埋めるのでしょう? この場合、「符号拡張」が起こります。符号付(signed)な値の場合、より大きな型に代入する際には上位24bit分には代入する数値の符号で埋められます。上の例だと、-1は0xffとなり、符合は1です。したがって、上位24bitが1で埋められ、0xffffffffとなるわけです。 これは32bitの場合での2の補数表記となっており、辻褄が... -
データ構造とアルゴリズム
プログラムとは、「データ構造+アルゴリズム」だという言葉があります。 アルゴリズム(ロジック)だけではなく、目的の機能に最適なデータ構造を選択することも重要です。 がんばってがんばって、ロジックをこねくり回して目的の機能を得たとしても、それは処理時間あるいは処理に要するメモリなどのリソースの面でかならずしも最適な処理とはなっていないでしょう。また、後から保守なり拡張なりで手を入れる際にあまりにロジックがひねくれていると修正しにくいものです。 そこで、「データの持ち方」というのが重要になるわけです。 例えばある要素の集合を「データ」として持ちたいとします。 この「データの集まり」をどう扱うかによって、最適な「データの持ち方」を選択するということです。 要素に並び順があり、かつ要素と要素の間に新たな要素を加えたりする場合には、連結リスト構造がいいでし... -
お仕事プログラミング
趣味でやるプログラミングと違って、お仕事にしてしまうといろいろと制限も出てくる。 そのなかで、割と軽視されている(少なくとも今の職場では)のが設計書とコーディング規約。これはホントに環境によると思うんだけど。 というわけで今日はコーディング規約のお話。 お仕事のプログラムに求められるのは、まず第一に仕様書どおりに動くこと。趣味の範囲ならそこまででもかまわないんだろうけど、その次にそのソフトウェア資産を次回新機種に使ったり、機能拡張をしたりとメンテナンスする必要がある。 しかも、最初にコーディングした人がメンテするとは限らない(むしろまれ)。頼りは、設計書とソースコード、およびソース内のコメントだけ。 そのため、設計書の精度とソースコードの可読性というものが非常に重要となる。前に言ったコーディングスタイルの統一も個人レベルだと有効だけれどそれが人によっ... - @wiki全体から「拡張性」で調べる