{//何もしない}は必要か否か?という議論が若干の盛り上がりを見せました。圏論的思考論、パターンマッチング、そしてプログラミング実務家も入り乱れ議論は混迷の様相でした。個人的にも議論の行く末が気になっていたところ、この議論を踏まえてその後コーディングしていて気づいた点があったので、実例を交えて私見をまとめてみることにします。{//何もしない}を書くべき/いやいやこんなん不要やろ」といった具合です。←elseで何もしない場合でも、else句を書くべき?それとも邪魔なだけ?}※筆者はプログラミング実務家であり数学者ではありません。数学的議論は含まず実務家目線で論じます。用語の使用が変な可能性がありますがご容赦ください。passなど、言語仕様として組み込まれている場合があります。暗黙的にパターンマッチを行ってもよい。{//何もしない}を書くのか?考察:ifはswitchと違いdefault句がない言語が多数派のため、議論を呼ぶswitch文におけるdefault句の取り扱いについても考え方は同じ(2022/11/20追加)閑話休題。暗黙的にパターンマッチを行ってもよい。「要は場面次第であり、可読性の観点でelse{//何もしない}があった方がよい場面がある」、「パターンの存在を明示する必要がある場合にelse{//何もしない}があると良い」というのが私的な(現段階での)結論です。{//何もしない}を省略する)ケースがあっても違和感はありません。要/不要の二元論でとらえるべきではないだろう、と考えています。具体例を示しながら、検討していきます。{//何もしない}が不要と思われるケース例えば以下のように処理中に早期リターンするといった用途でのifは頻出です。//(前段のifは早期リターンの意図が明確。//そのためあえてelse句で正常処理をくくったりはしない)}このケースでは「早期リターンする」という実装者の意図が明確に見えるため、あえてelse句を使用する必要はないでしょう。使用すればネストが深くなりむしろデメリットの方が大きくなるように感じます。いったelseの省略を行っていても、意味的には「処理を実行するべき引数か?」「処理を中断するべき引数か?」のパターンマッチを暗黙的に行っていると言えます。{//何もしない}を書くべきケースを検討していきます。前述した通り、コードのレビュワーやコードを読む他者・後の自分に対して、処理パターンの存在を明示することが主な目的です。次の例のように、処理の種類ごとに返すページ変数取得経路をスイッチする場合を考えます。(UIからのユーザー指示により遷移するページを分岐する場面を念頭に置いています。//(いずれのパターンにもマッチしない場合、検索条件なしで一覧を返す。"";と処理しても良い。View(searchResult);}このケースにおける一連のif-else句は、ユーザーの入力内容を解析して、どのパターンを実行するべきか(簡易検索か?詳細検索か?ページ番号推移か?)を分岐して処理を振り分けています。いくつかのifはそのif句内部でreturnしていないものもあり、いずれのifにマッチしなかったケースも、一つの実行パターンとして存在(この例でいうと検索条件なしで一覧を返すというパターン)しています。{//何もしない}」があった方がベター、となるわけです。(パターンマッチを入出力機能を持つ箱と捉えるならば、入力はifに掛けられる変数、出力は「if句がスコープ内の変数に及ぼす作用の内容」といったところでしょうか。{//何もしない}を書くのか?の回答を書いてみます(繰り返しますがあくまで私見です)。全般的に言えるのが「見る人に対する配慮」が主な理由となります。よって、逆にその様な配慮が不要なほどコードが単純なケース(例えば単純なif+elseパターンでelseifを含まないような単純なifブロック)ではあえてこのような記法をせずコードの簡略性を優先しても良いと考えます。{//何もしない}を書くのか?一連のif-elseブロックで、どのようなパターンを想定しているのか?を示す。これにより、何もしなくてよいパターンがあったとしても「何もしない」場合のパターンの存在を明示する。一連のif-elseブロックが、後続処理にどのような影響を与えるのか示す。これにより、何もしない(後続処理に何も作用しない)ケースが存在していることを明示できる。考察:ifはswitchと違いdefault句がない言語が多数派のため、議論を呼ぶこれは単に考察ですが、switchはdefault句が強制されるためこのような議論は起きませんが、ifの場合はそうでない(ifにdefaultがない)言語仕様が多数派です。そのため何も意識せずelseなしifを書いてしまいがちであり、その中には上述のように「いずれのifにもマッチしない場合は何なのだ?考慮漏れか?この一連のifで実現したかったのは何なのか?」という疑問をレビュワーに抱かせるものが生じます。実務論的には、ネストが深くなるデメリットも考慮して、「いずれのifにもマッチしないケースは何か?」が明示するべき場面かどうか?を意識していけばよいでしょう。コメントをいただきまして、上記取り消し部「switchはdefault句が強制」という言語仕様については誤認であることがわかりました。この新たな知識をベースに↓セクションを追加しました。コメントを頂戴したyuki様、誠にありがとうございます。switch文におけるdefault句の取り扱いについても考え方は同じ(2022/11/20追加)switch文はif文と同様に条件分岐を実装することができ、default句を必須とするか否かという同種の議論が生じさせます。switch文の場合であっても基本的な考え方は変える必要がなく、パターンマッチの可視性の観点でdefault句を書くか否かを検討すればよいと考えます。簡単な例で考えてみます。month(月)というint型の変数でSwitch文を使用しています。1月、4月、7月、10月の時だけ処理を実行する意図でコードが記述されています。逆に左記以外の月では実行するものがない状態です。ここでdefault句をあえてつけている意味は何でしょうか?処理的には何も変わりませんが、「month=1、4、7、10以外のケースが存在し得ること」、「1月、4月、7月、10月以外では実行するものがない」ということをコードの読み手に伝えるのに効果的と言えます。下記例のように、default句にあえてケースの列挙などを示してみるとより親切といえるでしょう。break;}閑話休題。{//何もしない}が必要になってしまう、あまりに長いif句」が出来てしまうのは、実は網羅的パターンマッチ機能(switch句)を使うべき場面である、ということ以外に関心の分離が不十分である可能性があるように思います。ポリモーフィズムを用いたりしてクラスや関数を関心毎に適切に分離していくと、自然とifを書く回数が減っていき、コードが簡潔になっていく様子が見て取ることが出来ます。詳細については、(関連記事)【関心の分離/責務の分離】変更に強いプログラミング実践手法にて解説しています。近隣の話題になりますので、是非合わせてご参考ください。当社では、IT活用をはじめ、業務効率化やM&A、管理会計など幅広い分野でコンサルティング事業・IT開発事業を行っております。この記事をご覧になり、もし相談してみたい点などがあれば、ぜひ問い合わせフォームまでご連絡ください。皆様のご投稿をお待ちしております。記事筆者へ問い合わせする※ご相談は無料でお受けいたします。14:58yuki様、コメントありがとうございます!嬉しいお言葉、励みになります。すみません、Switch文の実装に誤認があったようでした。syntaxの言語ではdefault句は省略可のようですね。該当の箇所を修正しました。ご指摘誠にありがとうございます。感想やご意見等、お気軽にコメントください。公序良俗に反するコメントはお控えください。管理者が承認したコメントはこの箇所に公開させていただく可能性がございます。返信通知先Emailアドレスは、筆者のみに通知され、公開されることはありません。返信通知先Emailを入力された場合は、コメントへの返信をこちらに掲載した際に通知させていただきます。その他の目的には使用いたしません。スパム対策のため、コメントは日本語のみ受け付けております。運営するブログメディアサイトです。業務の一環として、中小企業の経営×IT活用術やプログラミングの話題を中心に発信しています。経営コンサルティング全般からシステム設計、コーディングまで最前線で何でもこなしている、代表者の堺が執筆しています。ご一読のほどよろしくお願いします。プロダクト開発者)現役の財務・金融コンサルタントであり、システム開発者でもあります。自社のアプリ、ホームページ、ブログなど、全て自らコーディングしています。【関心の分離とSQL】複雑なSQLを書くべきではないという問題提起について依存性注入/DIは実はシンプルな概念なので、シンプルに解説する。「ソフトウェア工学」カテゴリをもっと見る自社PRトップページ運営会社お問い合わせ当サイトはリンクフリーです。記事の内容には相応の注意を払い掲載しておりますが、ご利用にあたっては読者の皆様のご判断とご責任の下にお願いいたします。partial",relevance:0},{begin:e.IDENT_RE+"\\s*(<[^=]+>\\s*)?\\(",returnBegin:!0,contains:[e.TITLE_MODE,E],relevance:0},{match:/\(\)/},{className:"params",begin:/\(/,end:/\)/,excludeBegin:!0,excludeEnd:!0,keywords:n,relevance:0,contains:[g,i,e.C_BLOCK_COMMENT_MODE]},e.C_LINE_COMMENT_MODE,e.C_BLOCK_COMMENT_MODE]},b]}}})();hljs.registerLanguage("csharp",e)})();。