総合化学5社。　https://neovisionconsulting.blogspot.com/2024/11/5-20241111.html: プログラミングにおいてフラグを多用すると怒られるのですが、なぜフラグを使ってはいけないのか実例を用いて説明して頂けませんか？

フォロー

興味対象は、コンピュータサイエンス、リスク管理、会計、金融、航空。USCPA, Private Pilot 資格保持者。更新日時:4月30日

２値フラグを $n$

個使うと

2^{n}

通りの組み合わせができ、これをすべてテストしなければならないですね。

一方、そのようなフラグの組み合わせで表現したとしても、実際の条件成立パターンは QM 法 (クワイン・マクラスキー法

) で大きく簡略化・情報圧縮できることが多いわけです。そして簡略化・圧縮後の論理式というのは、人間が意味論的に理解しやすい論理であったりします。

わざわざ網羅テストを複雑化させて、人間が解りにくい形にする必要はないよね、ということになります。

加えて …

なぜ QM 法で圧縮できるかというと、各条件・各フラグが完全独立ではなく同時には成立しないケースや後続条件を考慮しなくてよい早期リターン可能なケースなどがあるからです。

論理的に成立しない/使われないパターンまで等しくテストしなければならない状況に持ち込むのは非効率だという遅延評価戦略的な見方もできます。

Junji Uehara

フォロー

IT系企業に勤務更新日時:3月18日

もし〇〇なら✕✕をする

という振る舞いをフラグ変数を使わずに素直に書き下せば、

if 〇〇 { 
   ✕✕をする 
}

こんな風に書くことでしょうね。

フラグ変数を導入するというのは、上を例えば

var フラグ変数x 
if 〇〇 { 
  フラグ変数x = y 
} 
★ 
if フラグ変数xがy { 
  ✕✕をする 
}

と書くということです。フラグ変数を介在させて、条件判断処理と、条件判断の結果に対応する処理の結びつきを間接化してるのです。

間接化しないほうがわかりやすく、バグも少ないだろう、というのはわかると思います。理由はフラグを使うと変数の値という状態を持ち込んでいて、その状態を意図しない箇所が変更する可能性を導入しているからです。特に上の場合、★のところに処理が挟まったりした場合などですね。変数が増えてくればなおさらですが、たとえ一個でも酷い話です。

しかしそもそも、間接化したかったのは、★に処理を挟みたいから、とかなのではないでしょうか。他に、フラグ変数を使いたくなる理由もあるかもしれませんが、できれば回避したほうが良くて、そのために回避方法をとことん考えるべきです。

上の場合であれば、フラグ変数は〇〇の判断の結果を保存するために用いられているので、

function is〇〇(....) { 
　return 〇〇 
} 
 
★ 
if is〇〇(....) { 
  ✕✕ 
}

のように結果を表す変数を導入するのではなく、結果を得る関数に切り出すことで、フラグ変数を排除できます。またこうすることで条件分岐が減り、複雑さが減り、カバレッジを上げるのが楽になり単体試験が容易になります。式を求めるために必要な情報が関数の引数の形で明確になり理解しやすくなります。長いブロックが処理単位で分割され読みやすくなります。関数名を適切につけることでコメントに頼らずに意味もわかりやすくなります。

ここでは、フラグ変数を参照している箇所を、フラグ変数を計算する関数呼び出しに置き換えています。その場合デメリットになるかもしれないのは、計算タイミングが遅延されたこと、また複数回のフラグ変数の参照が複数回の呼び出しになるので、計算にコストがかかる場合計算量が増えてしまう可能性があること、副作用を伴なう場合意味がかわることなどです。

副作用に関していえば、上記のような見易くなる変換を邪魔してスパゲッティを生じさせているなら、なおさら副作用や値の依存性の制御が必要だと言えるでしょう。計算コストに関してはメモ化を検討するのも良いでしょう。

メモ化 - Wikipedia

メモ化（英 : memoization ）とは、プログラムの高速化のための最適化技法の一種であり、サブルーチン呼び出しの結果を後で再利用するために保持し、そのサブルーチン（関数）の呼び出し毎の再計算を防ぐ手法である。メモ化は構文解析などでも使われる（必ずしも高速化のためだけとは限らない）。キャッシュはより広範な用語であり、メモ化はキャッシュの限定的な形態を指す用語である。メモ化という用語は 1968年にドナルド・ミッキーがラテン語の memorandum （覚えておく）から作った造語である [1] 。 memorization （記憶、暗記）は同根語であってよく似ているが、メモ化という言葉は情報工学では特別な意味を持つ。メモ化された関数は、以前の呼び出しの際の結果をそのときの引数と共に記憶しておき、後で同じ引数で呼び出されたとき、計算せずにその格納されている結果を返す。メモ化可能な関数は参照透過性を備えたものに限られる。すなわち、メモ化されたことで副作用が生じない場合に限られる。メモ化の実装ではルックアップテーブルなどの参照方式が使われるが、メモ化では参照されるテーブルの内容は必要に応じて格納されるという点で、通常のテーブル参照とは異なる。メモ化は関数の時間コストを領域コストに交換して、時間コストを低減させる手段である。すなわち、メモ化された関数は速度の面で最適化され、記憶装置の領域という面ではより多く消費する。計算複雑性理論は、アルゴリズムの時間と領域のコストを扱う。全ての関数には時間と領域についての複雑性が定義される。このようにトレードオフが発生するが、同様のトレードオフがある最適化とは異なる。というのも、演算子強度低減などの最適化はコンパイル時のものだが、メモ化は実行時の最適化であるためである。さらに言えば、演算子強度低減は例えば、乗算を加算の組合せで表すことで性能を改善しようとするもので、プラットフォームのアーキテクチャに深く依存している。一方、メモ化はプラットフォームからは独立した戦略である。次の擬似コードは n の階乗を計算する関数である。 function factorial ( n ) // n は非負整数 if n == 0 then return 1 else return factorial(n - 1) * n // 再帰呼び出し end if end function n ≥ 0 であるような全ての整数 n について、関数 factorial の結果は不変である。つまり、 x = factorial(3) としたとき、 x の値は常に 6 である。上記のメモ化する前のコードでは、結果を得るのに n + 1 回の再帰呼び出しが必要であり、それが計算における時間コストに相当する。プラットフォームのアーキテクチャにも依存するが、時間コストは以下のコストの総和である。関数のスタックフレームを設定するのにかかるコスト n と 0 を比較するのにかかるコスト n から 1 を引くのにかかるコスト再帰呼び出しのためのスタックフレームを設定するのにかかるコスト再帰呼び出しの結果と n の乗算を行うコスト結果を呼び出し側に返すのにかかるコストメモ化していない実装では、これらのコストのうち 2 番から 6番が n に比例した回数かかることになる。 factorial をメモ化したバージョンを以下に示す。 function factorial ( n ) // n は非負整数 if n == 0 then return 1 else if (テーブルに n の階乗が格納されている) then return (テーブルに格納された n の階乗の値) else x = factorial(n - 1) * n // 再帰呼び出し x を n の階乗の値としてテーブルに格納する return x end if end function このメモ化バージョンでは、「テーブル」は広域の永続性のある変数であり、 n をキーとする連想配列のようなものである。このルックアップテーブルが領域（すなわちコンピュータのメモリ）を使うことによって、 factorial を同じ引数で繰り返し呼び出したときに要する時間が削減される。例えば、 factorial を最初に引数 5 で呼び出すと、その後 5 以下の引数で呼び出したとき、それらの値は既にメモ化されている。なぜなら、 factorial は引数 5、4、3、2、1、0 で再帰的に呼び出され、それぞれの呼び出しについて結果が記憶されるからである。また、引数 5 で呼び出された後に引数 7 で呼び出されると、再帰呼び出しは 2 回で済み（7 と 6）、5! の値は既に記憶されているのでそれが使われる。このように、メモ化された関数は呼び出される度により効率化されていき、結果として全体の高速化が図られる。自動メモ化 [ 編集 ] 上述の factorial の例のように、メモ化は一般にプログラマが関数内部に明示的に施すものであるが、参照透過性のある関数は外部で自動的にメモ化することもできる [2] 。ピーター・ノーヴィグが採用した技法は Common Lisp （ノーヴィグの論文で自動メモ化の例に使われていた言語）だけでなく、様々なプログラミング言語で応用可能である。自動メモ化は項書き換え [3] や人工知能 [4] の研究でも応用が模索されている。関数が第一級か第二級オブジェクトであるようなプログラミング言語（例えば Lua ）では、自動メモ化は関数を特定の引数付きで実行するたびに、その結果の値で（実行時に）置き換えてやることで実装される。このような置き換えを行う汎用関数を本来の関数を呼び出す代わりに呼び出せばよい。擬似コードを以下に示す（この例では関数は第一級オブジェクトであると仮定している）。 function memoized-call ( F ） // F は関数オブジェクト if ( F には対応する配列 values がない) then allocate an associative array called values ; attach values to F ; end if; if F. values[arguments] is empty then F. values[arguments] = F (arguments); end if; return F. values[arguments] ; end function factorial を自動メモ化する場合もこの戦略を使い、 facto

https://ja.wikipedia.org/wiki/%E3%83%A1%E3%83%A2%E5%8C%96

閲覧数:4.8万回

65件の高評価を見る

1件のシェアを表示

スイト

フォロー

2016年～現在、C#プログラマー更新日時:金

こちら↓の山本聡様の回答が、とーーーっても参考になったので共有いたします。

山本聡

· 1月13日

最近、DRY原則のやりすぎや安易な共通化は良くないと聞きます。しかしその解決策が後のことや目的、ドメインを考えるなど曖昧です。明確な基準はないのですか？

長文です。長くなってしまいました。冒頭に追記、DRY原則って、オブジェクト指向の設計的な目的とかドメインとかの事だったらしいので、別の質問して自己回答してみました。誰かのご参考になるかもなのでリンクしておきます。システムの設計についての質問です。顧客クラスを多数の関連部署でそれぞれで実装を行うと処理がぶつかって破綻すると聞きますが、それに対しての解決策はどのようにするのがよいのですか？に対する山本聡 (Satoshi Yamamoto)さんの回答「最近、DRY原則のやりすぎや安易な共通化は良くないと聞きます。」そんなの聞きます？やりすぎDRYって俺以外に言ってる人ほぼ聞いたことなんだけど...... そんなこと気がついているくらいに技術レベル高い人、そんなにいるかなあ。お友達になれそうだわ。あ、ここにある程度書いているか...。この記事見て、私も気がついたんだったです。記事には次のように書いています。 > DRYは素晴らしい考えですが、やり過ぎると密結合を生んでしまう。んーー、ちょっと表現が微妙かな。それに解決策も示されてないなー。この記事。私が気が付いたことと私が思う解決策をここの回答で書いておきます。「DRY原則のやりすぎ」「安易な共通化」についてです。これはつまりは「DRY原則を正確に理解してない間違った形でのDRY原則の使用」「考えられていない形での共通化」ということです。私の日本語もあやしいもんですが、正しく表現すると、DRYは素晴らしいんですが、まちがったDRYのやり過ぎによって、DRYに違反して、だめになる。そんな感じです。やりすぎなDRYって、いうのは、実際には正しいDRYをやりすぎているのではなく、DRYに見えるけど、本当はDRYじゃないよ、ってことになりますもし、いつもうだうだと長文かいてしまう自分の発言で「DRY原則のやりすぎや安易な共通化は良くないと聞きます」という感じをうけていただけてたら、なんらか、こういうことに疑問持ってくれたら、それはとっても感謝です。日本の技術力の底上げ的になったら、嬉しいかなと思ってます。極めて単純に見えることでも、こういう積み重ねが大事というか、リアルワールドでお仕事する人の中で、自称上級者の人も、これをわかっている人は皆無でこういうのがわかっていないことで、スパゲティ(コード)を茹でて(作って)しまうことに通じてくるので、お気をつけくださいませ、と思います。ということで、DRY原則のやりすぎ、と呼んでいる、実際にはDRY違反の事例について細かく書いておきます。概念的ですが、下記のようなコードを100回くらいは見ました。いや、ちょっと大げさかな、目立つところでガッツリ使われてたのを見たのは2,30回くらいかも。プロジェクトのコードみてたら、枝葉末端みていると、ほぼ100%みかけますし、根幹部分にこういうのがあって、目くじらたてなくてもいいんだけど、ちょっと見苦しいな、まだまだコードの整理整頓が足りんな、と自分は思います。根幹部分はきれいにしておきたいものねー。なるべく。普通、人は下記コードがまだ整理整頓できてない、ってことに気が付きもしないです。これが汚いコードだって見分けられる人いるのかねぇ。人はよく、こういうコード書いてしまうと思うんですよ。というのが下記ね。 const onClickButton1 = () => { getData(`button1`); } const onClickButton2 = () => { getData(`button2`); } const onClickButton3 = () => { getData(`button3`); } const onClickButton4 = () => { getData(`button4`); } const getData = (param) => { // 前処理 100行 if (param === `button1`) { // 処理A 50行 } else if (param === `button2`) { // 処理B 50行 } else if (param === `button3`) { // 処理C 50行 } else if (param === `button4`) { // 処理D 50行 } // 後処理 100行 } 雑な概念コードですが、こういうの書いていたとします。これ、共通化じゃなく、DRY原則違反なんです。でも、ほんとーーーーーに多くの人がこれがDRYだと思ってる。共通化しているからいいじゃない！と思ってる。当社調べでは140%くらいの人が、これがDRYだとかって思ってるんじゃないかいね。 Webで調べました。 DRY原則同じ意味や機能を持つ情報を複数の場所に重複して置くことをなるべく避けるべきとする考え方。このようにあります。「getDataで1ヶ所にまとめているから、共通化じゃないか！」ではないんです。 buttonが分散(分岐)しているのを、getDataで集約しているのは、別に悪くないわけですがgetDataの内部で分離しているから、わざわざ集めたものを分散(分岐)しているから、不要な分散コードがまぎれているんす。やるならこう。下記のように。こんなコード例のように理想的にいくかどうか、いろいろ微妙ですが、突き詰めて正しくDRYを行うと、こうです。 const onClickButton1 = () => { getDataBefore(); // 処理A 50行 getDataAfter(); } const onClickButton2 = () => { getDataBefore(); // 処理B 50行 getDataAfter(); } const onClickButton3 = () => { getDataBefore(); // 処理C 50行 getDataAfter(); } const onClickButton4 = () => { getDataBefore(); // 処理D 50行 getDataAfter(); } const getDataBefore = () => { // 前処理 100行 } const getDataAfter = () => { // 後処理 100行 } これならgetData内の分散分岐処理がなくなっています。そもそもgetData内の分岐処理がいらなかったことがわかりますよね。 getBeforeをたくさん書いているから分散しているとか、そういう話じゃねーんですよ。 ifの分岐がなくなっているところを見て欲しいわけで。より多段階にリファクタリングかけて、JSのパワーを使ってよりリファクタリングするとこうかな。 const onClickButton1 = () => { getData(()=> { // 処理A 50行 }) } const onClickButton2 = () => { getData(()=> { // 処理B 50行 }) } const onClickButton3 = () => { getData(()=> { // 処理C 50行 }) } const onClickButton4 = () => { getData(()=> { // 処理D 50行 }) } const getData = (f) => { // 前処理 100行 f(); // 後処理 100行 } 最初のコードと上のコードくらべてみると、最初のコードが、DRYに沿ってないってのわかりますかねー。最初のコード内にあるgetData内部のifの分岐は、DRYしてるのに仕方なく分岐しているのじゃなくて、書かなくてよい余計な分岐なんですわ。 ifを関数引数に置き換えているだけじゃないか、ってことじゃないですよ。分散しているものをわざわざ集めたのにその集めたところで分散するな、ってことね。で、その、最初のコードにあるgetData内の分岐処理が、あとあと複雑になってきて何が共通化になるのかどうなのか、わけわかんなくなっていくわけですがそういうのを予防するのが、正しいコードの整理整頓、正しいリファクタリング、ということです。もう一個、例をあげておきます。 if (a) { // 処理A 10行 // 処理X 10行 } else if (b) { // 処理A 10行 // 処理Y 10行 // 処理B 10行 } else { // 処理Z 10行 // 処理B 10行 } 元は上記コードだったとしましょう。DRYを行おうとして、間違ったDRY=やりすぎなDRYをすると、次のようになります。「安易な共通化」とも呼べますね。 const commonProcess = (param) => { if (param === 'X' || param === 'Y') { // 処理A 10行 } if (param === 'X') { // 処理X 10行 } else if (param === 'Y') { // 処理Y 10行 } else if (param === 'Z') { // 処理Z 10行 } if (param === 'Y' || param === 'Z') { // 処理B 10行 } } // メイン処理 commonProcess( a ? 'X' : b ? 'Y' : 'Z' ); 上記は「共通化しなかったほうがよかったじゃないか！」と思わせるような意味で「やりすぎDRY」です。でも、それは決して「やりすぎ」なのではなく、やり方が間違っているということなんです。「安易な共通化」をスべきではない、のですが、共通化の方法を間違っているということです。正しく共通化を行うには次のようにするべきです。 const funcA = () => { // 処理A 10行 } const funcB = () => { // 処理B 10行 } if (a) { funcA(); // 処理X 10行 } else if (b) { funcA(); // 処理Y 10行 funcB(); } else { // 処理Z 10行 funcB(); } 共通化する位置が違うんですよ。正しく共通化するにはどのようにするかを正確に見抜いてコード書かないといけません。 > しかしその解決策が後のことや目的、ドメインを考えるなど曖昧です。明確な基準はないのですか？明確な基準がない、って、まあ、よくわかりませんが、これで何かあいまいなところはときほぐれますでしょうか？それともそういう話とは違ってたかな？私もDRY原則の原理主義とかじゃないので、コードに妥協せずになんでもかんでもリファクタリングしろ、ということではないです。 DRYは原則だけど、このプロジェクトの今のコードでは、リファクタリングが大変だからコードは理想形ではないからおいておこう、という場面があるのはしっています。リファクタリングは簡単ではないです。でも、こういうやり過ぎなDRY(まちがったDRY)という共通化した内部で分岐するというものが理想形ではないと知り、これが積み重なってくるとやっかいなことをいろいろ引き起こすものだということも知っておくとよいんじゃないかなー、共通化した内部で分岐する、が望ましくないことだ、と知った上で、コードをリファクタリングするともっともっときれいなコードを書けるようになります。ということで、だらだら書いてしまいました。長々書いたので、YouTuber的な定番のセリフですが最後までご視聴いただきありがとうございます。もしこの動画がいいなと感じましたら、高評価、チャンネル登録、ぜひよろしくお願いします！まあ、こんなマニアックなコードの良し悪しとか、わかってもらえないと思うので、いいですけどね。別に。高評価なんか。1件ももらえなくても！他の人に理解されなくても！俺は仕事がんばるよ…

この回答の中で言及はされていませんが、やりすぎDRYの例として提示されているコードがまさしくフラグ引数のアンチパターンに相当しています。

フラグ引数のリファクタリング方法は上記の回答を参考にしていただくとして、ここではご質問に沿って、フラグで処理を切り替える場合（下記、コード1）でどのような不都合があるか見てみましょう。

// コード1 
onButtonAClick() 
{ 
    onButtonClick(Flags.A); 
} 
 
void onButtonBClick() 
{ 
    onButtonClick(Flags.B); 
} 
 
void onButtonCClick() 
{ 
    onButtonClick(Flags.C); 
} 
 
void onButtonClick(Flags flg) 
{ 
    // 前処理 P 
 
    if(flg == Flags.A) 
    { 
        // 処理 A 
    } 
    else if(flg == Flags.B) 
    { 
        // 処理 B 
    } 
    else if(flg == Flags.C) 
    { 
        // 処理 C 
    } 
    else 
    { 
        // 想定外処理 X（ログ出しなど） 
    } 
 
    // 後処理 N 
}

よくあるフラグ引数のアンチパターンとして示されるコードです（処理 P, A, B, C, N ともそれなりのボリュームがあるものとします）。これをベースにご説明いたします。

このコードの着想は『buttonA～buttonCのいずれのクリックイベントに対しても前処理 Pと後処理 Nを実施するのだから、「P → A or B or C → N」という流れを共通化しよう』という思いつきによるものです。

確かに「P → 何かの処理 → N」の流れだけで言えば共通化できていそうに見えますが、現実的な実装はこんなに単純にはなりません。どんどん実装を進めていったときにコードの脆さが露見していきます。まあ見ていてください（ドヤ顔）。

例えば「処理 A, Bの実行結果によって後処理 Nの前に処理 Eを実行する」といった仕様が発生した場合、コードを以下のように書き変えることになるでしょう。

// コード2 
onButtonAClick() 
{ 
    onButtonClick(Flags.A); 
} 
 
void onButtonBClick() 
{ 
    onButtonClick(Flags.B); 
} 
 
void onButtonCClick() 
{ 
    onButtonClick(Flags.C); 
} 
 
void onButtonClick(Flags flg) 
{ 
    // 前処理 P 
     
    bool flgE = false; 
     
    if(flg == Flags.A) 
    { 
        ResultA resultA; 
 
        // 処理 A（resultAに何かを代入） 
 
        flgE = resultA.NeedE(); 
    } 
    else if(flg == Flags.B) 
    { 
        ResultB resultB; 
 
        // 処理 B（resultBに何かを代入） 
 
        flgE = resultB.NeedE(); 
    } 
    else if(flg == Flags.C) 
    { 
        // 処理 C 
    } 
    else 
    { 
        // 想定外処理 X（ログ出しなど） 
    } 
 
    if(flgE) 
    { 
        // 処理 E 
    } 
 
    // 後処理 N 
}

さらに、処理 Cでも同様の仕様変更（今度は処理 F）が必要になりました。コードを修正します。

// コード3 
onButtonAClick() 
{ 
    onButtonClick(Flags.A); 
} 
 
void onButtonBClick() 
{ 
    onButtonClick(Flags.B); 
} 
 
void onButtonCClick() 
{ 
    onButtonClick(Flags.C); 
} 
 
void onButtonClick(Flags flg) 
{ 
    // 前処理 P 
     
    bool flgE = false; 
     
    if(flg == Flags.A) 
    { 
        ResultA resultA; 
 
        // 処理 A（resultAに何かを代入） 
 
        flgE = resultA.NeedE(); 
    } 
    else if(flg == Flags.B) 
    { 
        ResultB resultB; 
 
        // 処理 B（resultBに何かを代入） 
 
        flgE = resultB.NeedE(); 
    } 
    else if(flg == Flags.C) 
    { 
        bool flgF = false; 
 
        // 処理 C（flgEに何かを代入） 
 
        if(flgF) 
        { 
            // 処理 F 
        } 
    } 
    else 
    { 
        // 想定外処理 X（ログ出しなど） 
    } 
 
    if(flgE) 
    { 
        // 処理 E 
    } 
 
    // 後処理 N 
}

ヤバさがわかってきましたか？

これでもかなりヤバめですが、buttonCの類似機能を持つ buttonC2が追加となったとします。C2の処理は Cと共通部分（C'）があるようです。ちょっとコード化してみます。

// コード4 
onButtonAClick() 
{ 
    onButtonClick(Flags.A); 
} 
 
void onButtonBClick() 
{ 
    onButtonClick(Flags.B); 
} 
 
void onButtonCClick() 
{ 
    onButtonClick(Flags.C); 
} 
 
void onButtonClick(Flags flg) 
{ 
    // 前処理 P 
     
    bool flgD = false; 
     
    if(flg == Flags.A) 
    { 
        ResultA resultA; 
 
        // 処理 A（resultAに何かを代入） 
 
        flgD = resultA.NeedD(); 
    } 
    else if(flg == Flags.B) 
    { 
        ResultB resultB; 
 
        // 処理 B（resultBに何かを代入） 
 
        flgD = resultB.NeedD(); 
    } 
    else if(flg == Flags.C || flg == Flags.C2) 
    { 
        // 処理 C' 
 
        bool flgF = false; 
 
        if(flg == Flags.C) 
        { 
            // 処理 C1（flgFに何かを代入） 
        } 
        else 
        { 
            // 処理 C2（flgFに何かを代入） 
        } 
 
        if(flgF) 
        { 
            // 処理 F 
        } 
    } 
    else 
    { 
        // 想定外処理 X（ログ出しなど） 
    } 
 
    if(flgE) 
    { 
        // 処理 E 
    } 
 
    // 後処理 N 
}

そろそろ読むのも嫌になってくるかと思います。

それでは・・・ここで、問題です（デデンッ！）

// コード5 
onButtonAClick() 
{ 
    onButtonClick(Flags.A); 
} 
 
void onButtonBClick() 
{ 
    onButtonClick(Flags.B); 
} 
 
void onButtonCClick() 
{ 
    onButtonClick(Flags.C); 
} 
 
void onButtonClick(Flags flg) 
{ 
    // 前処理 P 
     
    bool flgE = false; 
     
    if(flg == Flags.A) 
    { 
        ResultA resultA; 
 
        // 処理 A（resultAに何かを代入） 
 
        flgE = resultA.NeedE(); 
    } 
    else if(flg == Flags.B) 
    { 
        ResultB resultB; 
 
        // 処理 B（resultBに何かを代入） 
 
        flgE = resultB.NeedE(); 
    } 
    else if(flg == Flags.C || flg == Flags.C2) 
    { 
        // 処理 C' 
 
        bool flgF = false; 
 
        if(flg == Flags.C) 
        { 
            // 処理 C1（flgFに何かを代入） 
        } 
        else 
        { 
            // 処理 C2（flgEに何かを代入） 
        } 
 
        if(flgE) 
        { 
            // 処理 F 
        } 
    } 
    else 
    { 
        // 想定外処理 X（ログ出しなど） 
    } 
 
    if(flgE) 
    { 
        // 処理 E 
    } 
 
    // 後処理 N 
}

上記コード5は明確なコーディングミスがあります。どこでしょうか？

もしフラグ変数の何が悪いかわからない方は、ぜひとも間違い探しをしてみてください。その不毛さを身をもって実感するといいと思います。

さて、いかがでしょうか。

間違い見つかりましたか？

それでは適当な行稼ぎも済んだので・・・

正解発表です！（ジャジャンッ！）

まあ、そんなにもったいぶることでもないんですけどね。

51行目の

            // 処理 C2（flgEに何かを代入）

と、54行目の

        if(flgE)

が間違いでした。本当はここの処理では flgFが使われるべきところです。ちょっとずるいかもしれませんが、間違いが1つとは申し上げませんでした。

実際の開発も不具合の原因が1つとは限りません。そして、上記のコーディングミスは実行するまでその存在に気づけません。

フラグを多用する設計はコーディングミスを生みやすく、なまじビルドエラーなどが出ないため、実行しないと分からない（テストケースが甘い場合にはテストですら発覚しない）のです。

onButtonClickが肥大化しすぎてテストコードが書けないか、書けたとしてもメンテナンスに手間が掛かりすぎます。テストケースの作り込みも難儀することでしょう。結局、ブレークポイントで1行ずつ追っていくか、分岐の端々でログを出すかしかありません。

この例の場合「// 処理 A」とかで省略していますが、実際のコードは数百行に肥大化したものになります。if文の分岐もこの比ではないほど複雑になります。その数百行の中からたった1文字のミスを探し出すことを考えてみてください。

やりたくないでしょ？

それがフラグ引数が敬遠される理由です。

閲覧数:5,694回

13件の高評価を見る

なぜ、Pythonはプログラミング言語を混乱させると言われるのでしょうか？

プログラミングを勉強したいと思っています。プログラミングは何言語から始めるべきか、どのように勉強していったらいいかなどのアドバイスをお願いします。

Hantani Sadahiko

フォロー

元組込系プログラマ10ヶ月

フラグを使うのが問題なのではなく「多用」するのが問題なのではないでしょうか。

フラグにより状態が変わるわけですから、１０個のフラグがあると「１０２４通り」の状態が発生します。

テストケースもその全てのパスを確認しないといけないわけですから最低でも１０２４は書かないといけません。

全てのフラグの成立条件を変えて評価をされていますでしょうか？

また、関数・メソッドの中にフラグがあり、複数の箇所でフラグにより処理が変わるのであれば「元々１つにすべきでは無かった」可能性があります。

Hirota Ichiro

フォロー

プログラミング愛好家11ヶ月

フラグがいけないのではなく多用がいけない気がします。

フラグがあるってことは、フラグによる条件分岐があるってことですよね。条件分岐がひとつ増えるとプログラムの複雑度は1増えますので、KISS(単純にしておけ)原則に違反します。あとは熱力学の法則に従ってエントロピーは増大する一方、プログラム全体が汚部屋やゴミ屋敷のようになっていきます。

実例を示せとのことですが、ちょっと良い例は示せません。プログラムソースコードがわかりにくい例を掲げても結局わかりにくいままだと思いますので。今まで見たことのある、長い条件式や深いネストの嫌なif文を思い出して嫌な気分になってみてください。それがフラグを追加して悪くなる実例です。

フラグを追加しても複雑さが増えなければ良い訳です。

フラグによって条件分岐する箇所が少なければ複雑化を抑えられる
フラグ間に依存関係がなければ、条件分岐の複雑化を抑えられる

新しく追加するフラグを良く分析して、安易な条件分岐の増大を抑えましょう。

コンパイル時静的に決まるものはコンパイルオプションにする
feature toggle のような役割のものなら、そういうのを一元管理しているところにまかせる
フラグで分岐するのではなく、型の抽象化を使って型で分岐する

ああもうこれは誰が見てもフラグにするしかないよねっていう王道フラグを実装して、怒った人を見返してやりましょう。

Shimizu Hiroyuki

フォロー

Platform Software Engineer10ヶ月

フラッグを多用して、訳の分からぬ物をつくる前に、キチンと分析せよ、状態遷移モデルを描けという事です。

Finite-state machine - Wikipedia

Mathematical model of computation "SFSM" redirects here. For the Italian railway company, see Circumvesuviana . Classes of automata (Clicking on each layer gets an article on that subject) A finite-state machine ( FSM ) or finite-state automaton ( FSA , plural: automata ), finite automaton , or simply a state machine , is a mathematical model of computation . It is an abstract machine that can be in exactly one of a finite number of states at any given time. The FSM can change from one state to another in response to some inputs ; the change from one state to another is called a transition . [1] An FSM is defined by a list of its states, its initial state, and the inputs that trigger each transition. Finite-state machines are of two types— deterministic finite-state machines and non-deterministic finite-state machines . [2] For any non-deterministic finite-state machine, an equivalent deterministic one can be constructed. The behavior of state machines can be observed in many devices in modern society that perform a predetermined sequence of actions depending on a sequence of events with which they are presented. Simple examples are: vending machines , which dispense products when the proper combination of coins is deposited; elevators , whose sequence of stops is determined by the floors requested by riders; traffic lights , which change sequence when cars are waiting; combination locks , which require the input of a sequence of numbers in the proper order. The finite-state machine has less computational power than some other models of computation such as the Turing machine . [3] The computational power distinction means there are computational tasks that a Turing machine can do but an FSM cannot. This is because an FSM's memory is limited by the number of states it has. A finite-state machine has the same computational power as a Turing machine that is restricted such that its head may only perform "read" operations, and always has to move from left to right. FSMs are studied in the more general field of automata theory . Example: coin-operated turnstile [ edit ] State diagram for a turnstile A turnstile An example of a simple mechanism that can be modeled by a state machine is a turnstile . [4] [5] A turnstile, used to control access to subways and amusement park rides, is a gate with three rotating arms at waist height, one across the entryway. Initially the arms are locked, blocking the entry, preventing patrons from passing through. Depositing a coin or token in a slot on the turnstile unlocks the arms, allowing a single customer to push through. After the customer passes through, the arms are locked again until another coin is inserted. Considered as a state machine, the turnstile has two possible states: Locked and Unlocked [4] There are two possible inputs that affect its state: putting a coin in the slot coin and pushing the arm push In the locked state, pushing on the arm has no effect; no matter how many times the input push is given,

https://en.wikipedia.org/wiki/Finite-state_machine

Shinichi Kusunoki

フォロー

プロダクト・マネージャ10ヶ月

フラグも「大域変数になってて（後個からでも参照可能で）数が多い」とかだと訳わからなくなるんでアレなだけですね。

オブジェクトの整理がしっかりなされてて、そのインスタンス内で非公開メンバとして扱われて、尚且つ状態遷移がしっかりまとまってたら別にフラグが多くても問題にならないです。

Aというインスタンスの状態がXXの場合、Bのインスタンスが如何な状態であろうと無視できる。…とか、オブジェクト間の関係性を示す仕様の定義で整理できます。テストケースはクラスBの中でだけ完結するので、クラスAのテストケース分析に関し、クラスBの当該フラグの状態ケース全てを網羅する必要はないわけです。

単独で存在するフラグを無軌道に増やしたり、その責任範囲が特定しにくい（値の操作をあらゆる場所で行うとか…）等の設計の拙さが問題なのです。

多用することは別に間違いとはいえません。そのようなシステムはたくさんあります。

羽田拓央

フォロー

詳しい分野:英語(言語)10ヶ月

フラグの質が問題なんじゃないでしょうかね。指摘側も本質分かってなくてフラグ多用するな言ってるだけとかね。アクションをフラグ使ってディスパッチする位なら、関数分けろが一般論。メッセージキューとかはディスパッチいるかもしれんけど、プロセス跨がないなら関数ポインタとかデリゲートなどの動的クロージャをキューに渡せばよいってなりますよね。

怒ると褒めるをフラグ化する必要が本当にあるのか、まずは怒るメソッドと褒めるメソッドを用意して、DBやユーザによる入力に基づいて切り替えが必要な場合だけ、フラグをディスパッチする構造にするのがいい。こうするとディスパッチ関数もシンプルになっていいよね。ディパッチ項目が100とか行っても大丈夫になる。本当にフラグによる指定が必要？コードに怒る()、褒める()とか書いて済むならそっちの方がいいの。

コーディングルールなんて本質分かってない雑魚が適当に作ってるだけのもの多いからね。

テスト項目増えるほうは気にしてないな。自分は。本当に必要ならやるだけ。不要なテスト項目増やされるのは嫌だけどね。