7月が。

早く、納車確定連絡来ないかな－。

と、インディ500 ツインリンクもてぎ でのCR-Zパレード走行に当選しました。
計100台のCR-Zがオーバルコースをパレードしちゃいます！

9月とずいぶん先ですが、楽しみ楽しみ。

CR-ZのルームランプやらをLEDに換装しようかと…
…って一般市販品たけぇ(´д｀)
ショップのやつ、ごつくて入るのか微妙…(´・ω・`)

ここは、もしかして、久しぶりの半田ごての出番かっ!?
(Let’s 電子工作！ワンオフ制作だぜっ!?)

確かに、面積いっぱいにLED敷き詰められるから、既製品よりも明るくなるのも魅力的。

うーん、ありかも？

ようやく、あと1月…

こうなったら、1～2週間長期休暇を取って、日本1周の旅しちゃうぞー！
…って言い出すほど、へんなテンションでワクテカしまくってます。

だめだこりゃ。

RAYS gram LIGHTS 57 Ultimate SCの見積もりとパンフももらってきちゃいました。
1stロットも既にいっぱいでバックオーダーらしく、今注文しても8末なんだとか。

と毎月恒例のお買い物！
今月は、応援中のAngel Ringと…

きゃん☆フェスです。

あとは、おとぼく2ですね。

RAYS gram LIGHTS 57Ultimate SC Specに一目惚れwwww
クリアブルー + ホライゾンターコイズ で青に染める！(サッカー日本代表を特別意識している訳じゃないよ！)

タイヤはMichelin Pilot Sport3あたりとかはどうだろう？
コンセプト的にCR-Zに近いものがあって、ぴったりな気がするwww

チューニングの第一歩としては無難だし、ありかも？

私以外はなんにもうれしくないカウントダウンwwww

ただ単に、自分のモチベーションの為だけであります…orz

さぁ、明日からはまた仕事だ…

おかえり、はやぶさ。といいうことで、記念にキャプチャー。

ちなみに、日本だけみたいで、本土は通常営業でした。

たまには、違うのを試すのも良いかな…と完全に予定にもなかった衝動買い。

ついでに、Sofmap Premium Clubにも入会。

1年に1回のご利用で年会費無料だと…？

毎週1回は利用してますが、ナニカ？

昨日から続いちゃいました。

ポイント2 – 例外の動作を理解せよ

例外を使い出したはいいものの、よく理解せずに使っているケースも多々見受けられます。

void MainProc(void)
{


   try {
      funcA();
   }
   catch (clsException e)
   {
      // エラー処理
      printf("エラー説明: %s", e.getDescription());
   }
}


void funcA(void)
{


   try {
      funcB();
   }
   catch (clsException e)
   {
      throw e;   // …ぇ？
   }
}


void funcB(void)
{


   if (globalAnyPointer == NULL) {
      throw clsException("NULL ポインター例外");
   }


   // 何か処理…
}

こんな、何もせずただ再度例外をスローするだけの無意味な try ～ catch が存在するプロジェクトをいくつみてきたことか…
これも、戻り値でエラーを返す習慣が抜けていないのでしょう。

例外処理の場合、プログラム上で意識しなくても自動的にコールスタックを遡ります。
また、この時通過する関数は引き継ぐ処理を行わなくとも、自動的にエラー情報は引き継がれます。

void MainProc(void)
{


   try {
      funcA();
   }
   catch (clsException e)
   {
      // エラー処理
      printf("エラー説明: %s", e.getDescription());
   }
}


void funcA(void)
{


   funcB();
}


void funcB(void)
{


   if (globalAnyPointer == NULL) {
      throw clsException("NULL ポインター例外");
   }


   // 何か処理…
}

上の例では、funcAは特に必要がなければ、例外を受け取る必要はありません。
このようにしても、funcBで起きたNULL ポインター例外はちゃんとMainProcへ通知されます。

今日はちょっと愚痴混じりのまじめな話。

今の仕事は別の会社が作成したプログラムの改修・保守をしているのですが、
それが改修を行うと、必ず潜在不良が見つかるという品質・保守性の悪さに工数は爆発的に増加。

原因は、元々の担当者が今まで業務プログラムしか経験がなかったのが、
突然一般パッケージソフトを担当したことかと思っています。
そこで、こんなことを避けるためのいくつかのポイントを挙げてみようと思います。

業務担当から、他の担当(基盤や一般パッケージ)を担当することになったアナタ、必見です(大嘘)

ポイント1 – 関数の戻り値はエラーコードを返すものじゃない

業務でよく使用される COBOL(85) は、エラーがあった場合、
プログラムの戻り値としてエラーコードを返すほか通知方法がありませんでした。
(※COBOL 2002では、構造化例外処理がサポートされましたので、厳密には今は違います。
ただ、COBOLで存在するプログラムは古くに作られたものをそのままストコンする場合が多いので)

COBOLの考え方をそのまま踏襲すると、関数は戻り値がエラーコードを示す、ということが多いのですが、
以下のようにその部品を使う呼び出し元の制御処理が煩雑で、処理フローが読みづらくなります。

int Proc(const char * arg)
{
   int intResult;


   // 関数を呼ぶよ！
   intResult = funcA(arg);
   if (intResult != S_OK) {
      return intResult;
   }


   // 次も！
   intResult = funcB();
   if (intResult != S_OK) {
      return intResult;
   }


   return S_OK;
}


int funcA(const char * arg)
{
   // 引数は正しい？
   if (arg == NULL) {
      return E_POINTER;
   }


   // 何か処理…


   return S_OK;
}

C++やJava、Visual Basicなど最近の言語には構造化例外処理という仕組みがあります。
システムエラーとして扱うべきものは、この例外というものを使うようすべきです。

void Proc(const char * arg)
{


   funcA(arg);
   funcB();
}


void funcA(const char * arg)
{
   // 引数は正しい？
   if (arg == NULL) {
      throw clsNullPointerException();
   }


   // 何か処理…
}

結果的に、関数の戻り値は正常値しか扱わなくなり、インターフェースがわかりやすくなります。
また、呼び出し側も条件分岐がなくなり、これは単体テスト工数の削減に大きく寄与します！

※注 サンプルコードは色々端折っています。

自宅が一軒家ではないので、ガレージなんてものはありませんwwww
普通に駐車場を借りるので、車上荒らし対策もしっかりとね！

というわけで、カープロショップに相談してみた。

あと、キャンセル品が売ってたので、購入。

…というか、このブログ、異色すぎない？ なにこの組み合わせwww