Brynhildr

KeroRemote

リモートデスクトップエンジニアのブログ。


Brynhildr(ブリュンヒルデ)はシェアウェアになりました
引き続きご利用される場合はライセンスのご購入が必要です
詳しくは「こちら」をご覧ください
とあるプログラムの開発技法。
とあるC言語で記述されたソフトウェアのプログラムの開発技法をメモしてみました。

---

「int型」を兎に角使っていない

変数の宣言に「int型」が1個もありません。int型に代わりに全て「long型」を使っています。

「構造体」を兎に角使っていない

構造体が全然ありません。殆どグローバル変数を使っています。あと変数名が長いです。

「クラス」を兎に角使っていない

クラスが全然ありません。恐らくクラスを理解出来ていないです。

「関数」を兎に角使っていない

関数が少ないです。その為にメインルーチンや1つの関数が非常に長いです。

「グローバル変数」が多い

グローバル変数が非常に多いです。マルチスレッド実装で混乱必至です。

「引数」が兎に角多い

数少ない関数の引数が非常に多いです。1つの関数で幾つもの処理が出来る様な複雑な仕組みで非常に長いです。

「記述方法」が兎に角古い

結果的にオブジェクト指向プログラミングでも何でも無く、まるで20年前のCOBOLのような時代遅れの書き方で全く新しさが感じられません。

---

とゆー上のような「速度向上」とゆー都市伝説を信じているかのよーな自分のソースなんですが、デメリットとゆーか特徴をズラズラと書いてみましたけど、メリットとしては、

ソースコードが非常に短い

です。比較的に非常に短くなります。但し、オブジェクト指向プログラミングでは無いので、一般的のプログラマーの方から見ると可読性は低いですが。で、ソースコードが短いとなると、

不具合が少ない

です。比較的に少ない方かと思います。個体差はあると思いますが、不具合発生対象個所が減りますのでこーゆー結果になると思います。で、さらに、

処理速度が速い

です。単純に処理(ステップ)が減りますので当然こーゆー結果になると思います。但し、細かく条件分岐させる事でソースは短くなりますが、逆に速度が落ちてしまいます。出来るだけ速度低下を許容範囲で抑える事が出来るように処理毎の速度計測をする事が重要ですかね。

そんな感じですが、C言語は習った記憶が無いので自己流とゆーか我流とゆーか完全にカウボーイコーディングになっておりまする。あんまり可読性を考慮せず、兎に角「シンプル」で「高安定性」で「高速性」にと思っていたらこーなりました。プログラム開発技法に正解は無いと思いますが、ソフトウェアの用途によってとゆー感じですかね。

ですが!自分も今年で40歳で人生の半分以上をプログラマーとして生かされてきたワケですが、まだまだコボラーとしての域を抜けておらん!まだまだ未熟者ぢゃ!とゆー事で、15年振りくらいに言語系の本をさっき本屋で買ってきてみました、C言語の基礎知識的な感じの本を。

2013年はC言語を勉強したいと思います!結構今更ですけど!


1件のコメント ... ( 管理人承認制 )



今気付いたんですけど、C言語て書いてますけど、C++言語ですよね・・・。クラスとか書いてますし、STLも使ってますし・・・。ま、いいか(´д`)


IchiGeki  2013/01/22




... 不具合報告の際は、アプリのバージョンやOS等の動作環境の記載を御願い致します。

表記されている会社名・製品名・システム名などは、各社の商標、または登録商標です。
当サイトはAmazon.co.jpアソシエイトプログラムに参加しています。
© 2010-2024 LAUNCELOT CO. LTD.