私はこう書く - GOTO文

今月は久しぶりにコードを書いた。

==

僕個人のクセでもあるのだが、GOTO文をよく使う。一般的には構造化の妨げやデバッグしにくさの原因になるので、エラー処理・例外処理での活用が多いですね。

...
　　if( foo_func() == -1 ){
　　　　/* エラー発生 */
　　　　goto retired;
　　}
...
retired:
/* ファイル操作の後処理 */
　　if( fd != -1 ){
　　　　close(fd);
　　　　fd = -1;
　　}
/* 動的領域の後処理 */
　　if( ptr != (hoge_t*)NULL ){
　　　　hoge_t_free(ptr);
　　　　ptr = (hoge_t*)NULL;
　　}
/* エトセトラ */
...
　　return(rc);
}

後処理をまとめておくことで、クローズ漏れや解放漏れの防止やレビュー時の可読性も向上するんじゃないかと思ってます。

私はこう書く - IF文

レビューしやすくすれば品質は向上する、というシンプルな気持ちでコーディング規約を勉強。

==

僕個人のクセでもあるのだが、IF文には大きく分けて2種類あると思ってて、それによって組み方を変えてる。

1. 正常系と異常系のIF文

例えば、ファイルアクセスなどのエラー処理をあらわす条件分岐など。
...
...
if( 条件A ){
　　/* 異常系処理（＝エラー処理） */
　　retire();
　　hoge1();
　　return(ERROR);
}
if( 条件B ){
　　/* 異常系処理（＝エラー処理） */
　　retire();
　　hoge2();
　　return(ERROR);
}
if( 条件C ){
　　/* 異常系処理（＝エラー処理） */
　　retire();
　　hoge3();
　　return(ERROR);
}
/* 正常系処理 */
...
...


フローチャート図でいうと、本線がすべて正常形の処理を表し、異常系（エラー）処理が根っこのように外側に伸びる感じ。さらに言えばすべての根っこは後処理（クローズ処理や解放処理など）を共通化して実行させる。



2. 正常系と正常系のIF文

例えば、右に行くか左に行くか、IEかFirefoxか、JISかSJISかEUCかUTF-8か、といった正常系の大きな条件分岐など。SWITCH文にも似ている。

...
...
if( 条件A ){
　　/* 条件Aが真である、正常系の処理 */
　　funcA();
}
else{
　　/* 条件Aが真でない、正常系の処理 */
　　funcB();
}
/* unreachable */


特徴として、比較的大きなブロックになったり、それぞれのブロック内で終了し、ブロック外は到達しないものとか。

このパターンで実装することで、可読性や保守性などが向上する。と思う。

[シンポジウム]JaSST 2008 東京 - 参加できないけど。

品質問題で痛い目にあってましたが、徐々に復活せねば。明日はフェデラー録画するぞ。

==

来週はJaSST東京です。あっという間の1年ですな。申し込みたかったけど、余裕がなかったので今回は涙を呑んで不参加。WACATEの実行委員によるライトニングトークがあったり、みたいのがたっぷしあるのになあ。12月にWACATE、1月にJaSST、2月にはJSTQB試験もあるねえ。

事例、実例からのテスト仕様書をどう書くか、という記事が載っていたり。技法道場はカバレッジのお話。