SAP Knowledge Wiki
ABAP/CASE
の編集
Top
/
ABAP
/
CASE
-- 雛形とするページ --
(no template pages)
処理の分岐に使用する。 * 概要 [#aa6daf29] [[IF>ABAP/IF]]と同じく、分岐に用いる。なお、[[IF>ABAP/IF]]との差異は下記の通り。 -特定の[[変数>アドオン/変数]]や値を軸とする 複数の判断要素は採用できない。例えば[[会社コード>財務会計/会社コード]]など、処理の軸を規定して使用する。 -判断の優先順位がない 複数の条件に合致する場合でも[[IF>ABAP/IF]]ならば優先順位をつけられるが、こちらにはない。 -等号での比較に限られる 大なり・小なりなどは使用できない。但し、[[OR>ABAP/OR]]は使える。 ** 用法 [#x4112779] 概要の通り、つまり「ある変数を軸とし、優先順位のない等号による比較」に用いる。 また、逆にこの命令を使うようなシーンでは[[IF>ABAP/IF]]と違い優先順位や条件分岐を深慮せずに済むため、ラジオボタンやコンフィグの追加などがあり得る場合には非常に有効と言える。 その際、実装担当者が修正箇所を発見しやすかったり、デグレのリスクが低減されたりすることもプラスの点と考える。バリエーションを増やすのも楽だし。 但し、柔軟性で言えば100%[[IF>ABAP/IF]]に軍配が上がるため、考えなしに使うのはやめよう。 ** サンプル [#t500008b] CASE BKPF-BUKRS. WHEN C_JAPAN. L_REGION = 'ASIA'. WHEN C_US. L_REGION = 'NORTH AMERICA'. WHEN OTHERS. CONTINUE. ENDCASE. ポイントとしては、''「必ずOTHERSで想定外の値を引っ掛けること」''。 どんなプログラムにでも言えることだが、他の仕様変更に引きずられたり想定に漏れがあった場合、「想定外の動きのためエラーで止まってしまう」か「想定外にもかかわらず動作し、後続が流れてしまう」の二択となるが、最もまずいのは後者であるため、必ず例外処理としてOTHERSを組み込んでおくこと。 * その他 [#sfa34de9] ある担当者が、下記のようなコーディングをしていたことがあった。 CASE 'X'. WHEN RADIO_A. PERFORM PROCESS_A. WHEN RADIO_B. PERFORM PROCESS_B. WHEN RADIO_C. PERFORM PROCESS_C. ENDCASE. 何をやっていたかというと、選択されたラジオボタンに応じた処理に遷移するというもの。 CASE文の本来的な用途に反するため、脊椎反射でNoいう答えを出したが、可視性という観点ではどうか。 非常にわかりやすいのだ。 これは、あるべき論あるいは綺麗事と実利・実益の交差点ともいえる利用法で、個人的には、自分は絶対にこういう書き方をしないが、わかりやすいのは事実だ。 諸兄はどう思われるか？ ~ ~ CENTER:【スポンサードリンク】 #htmlinsert(amazon_book_sap_system_implement) ~ ~ ---- #pcomment(reply)
タイムスタンプを変更しない
処理の分岐に使用する。 * 概要 [#aa6daf29] [[IF>ABAP/IF]]と同じく、分岐に用いる。なお、[[IF>ABAP/IF]]との差異は下記の通り。 -特定の[[変数>アドオン/変数]]や値を軸とする 複数の判断要素は採用できない。例えば[[会社コード>財務会計/会社コード]]など、処理の軸を規定して使用する。 -判断の優先順位がない 複数の条件に合致する場合でも[[IF>ABAP/IF]]ならば優先順位をつけられるが、こちらにはない。 -等号での比較に限られる 大なり・小なりなどは使用できない。但し、[[OR>ABAP/OR]]は使える。 ** 用法 [#x4112779] 概要の通り、つまり「ある変数を軸とし、優先順位のない等号による比較」に用いる。 また、逆にこの命令を使うようなシーンでは[[IF>ABAP/IF]]と違い優先順位や条件分岐を深慮せずに済むため、ラジオボタンやコンフィグの追加などがあり得る場合には非常に有効と言える。 その際、実装担当者が修正箇所を発見しやすかったり、デグレのリスクが低減されたりすることもプラスの点と考える。バリエーションを増やすのも楽だし。 但し、柔軟性で言えば100%[[IF>ABAP/IF]]に軍配が上がるため、考えなしに使うのはやめよう。 ** サンプル [#t500008b] CASE BKPF-BUKRS. WHEN C_JAPAN. L_REGION = 'ASIA'. WHEN C_US. L_REGION = 'NORTH AMERICA'. WHEN OTHERS. CONTINUE. ENDCASE. ポイントとしては、''「必ずOTHERSで想定外の値を引っ掛けること」''。 どんなプログラムにでも言えることだが、他の仕様変更に引きずられたり想定に漏れがあった場合、「想定外の動きのためエラーで止まってしまう」か「想定外にもかかわらず動作し、後続が流れてしまう」の二択となるが、最もまずいのは後者であるため、必ず例外処理としてOTHERSを組み込んでおくこと。 * その他 [#sfa34de9] ある担当者が、下記のようなコーディングをしていたことがあった。 CASE 'X'. WHEN RADIO_A. PERFORM PROCESS_A. WHEN RADIO_B. PERFORM PROCESS_B. WHEN RADIO_C. PERFORM PROCESS_C. ENDCASE. 何をやっていたかというと、選択されたラジオボタンに応じた処理に遷移するというもの。 CASE文の本来的な用途に反するため、脊椎反射でNoいう答えを出したが、可視性という観点ではどうか。 非常にわかりやすいのだ。 これは、あるべき論あるいは綺麗事と実利・実益の交差点ともいえる利用法で、個人的には、自分は絶対にこういう書き方をしないが、わかりやすいのは事実だ。 諸兄はどう思われるか？ ~ ~ CENTER:【スポンサードリンク】 #htmlinsert(amazon_book_sap_system_implement) ~ ~ ---- #pcomment(reply)
テキスト整形のルールを表示する
