私はこう書く - IF文
レビューしやすくすれば品質は向上する、というシンプルな気持ちでコーディング規約を勉強。
==
僕個人のクセでもあるのだが、IF文には大きく分けて2種類あると思ってて、それによって組み方を変えてる。
- 正常系と異常系のIF文
- 正常系と正常系のIF文
例えば、ファイルアクセスなどのエラー処理をあらわす条件分岐など。
...
...
if( 条件A ){
/* 異常系処理(=エラー処理) */
retire();
hoge1();
return(ERROR);
}
if( 条件B ){
/* 異常系処理(=エラー処理) */
retire();
hoge2();
return(ERROR);
}
if( 条件C ){
/* 異常系処理(=エラー処理) */
retire();
hoge3();
return(ERROR);
}
/* 正常系処理 */
...
...
...
if( 条件A ){
/* 異常系処理(=エラー処理) */
retire();
hoge1();
return(ERROR);
}
if( 条件B ){
/* 異常系処理(=エラー処理) */
retire();
hoge2();
return(ERROR);
}
if( 条件C ){
/* 異常系処理(=エラー処理) */
retire();
hoge3();
return(ERROR);
}
/* 正常系処理 */
...
...
フローチャート図でいうと、本線がすべて正常形の処理を表し、異常系(エラー)処理が根っこのように外側に伸びる感じ。さらに言えばすべての根っこは後処理(クローズ処理や解放処理など)を共通化して実行させる。
例えば、右に行くか左に行くか、IEかFirefoxか、JISかSJISかEUCかUTF-8か、といった正常系の大きな条件分岐など。SWITCH文にも似ている。
...
...
if( 条件A ){
/* 条件Aが真である、正常系の処理 */
funcA();
}
else{
/* 条件Aが真でない、正常系の処理 */
funcB();
}
/* unreachable */
...
if( 条件A ){
/* 条件Aが真である、正常系の処理 */
funcA();
}
else{
/* 条件Aが真でない、正常系の処理 */
funcB();
}
/* unreachable */
特徴として、比較的大きなブロックになったり、それぞれのブロック内で終了し、ブロック外は到達しないものとか。
このパターンで実装することで、可読性や保守性などが向上する。と思う。
| 固定リンク
| コメント (2)
| トラックバック (0)
最近のコメント