空elseの有無

職場などでもそれぞれなのですが、if～elseでifのみに処理があり、elseで処理がある場合で、空elseを置くことって何か用途があるのでしょうか？

処理負荷etcなところで言うと、コンパクトな方がメモリが見る範囲が～といった内容もあったので、コンパクトにしておくに越したことが無いように思います。
また、中の処理が空であれ、elseに入るという行為そのものが、何かしらの処理をしているということはないのでしょうか？
処理がされるのでしたら、やはり邪魔になってくるように思います。

また、可読性という観点で考えると、仮にコメントで何もしないなどが記載されていても、elseが記載されている時点で、elseの中が何もしないのかを認識する必要性が出てきます。
if文を分かっている人間なら、elseがそもそも無い時点で、ifの条件外では何もしないの認識ができると思いますので、わざわざ何もしないを伝えるためにelseを置く必要性が無いように思います。

途中にあるご質問箇所のご回答についてもですが、ご意見いただければと思います。

No.3 回答者： WindFaller 回答日時： 2015/09/14 00:26

こんばんは。

人によっていろんな考え方はあるとは思います。
最終段階では、コードは、そのようなことはしません。あるとすれば、消し忘れです。
言語は何か書かれていませんが、後々、そのようなコードをみるとなると、VBAだとは思います。
私自身の開発の時ですが、

If ～　Then
　・・・・
Else
'ここが空白
End if

Else 自体よりも、If 構文の条件に多少の不安を感じたりした時に、Else の空の部分には、Stop キーワードを置いておいて、様子をみることがあります。ElseIf は、空きにすることはありませんが、あくまでも、Else は、IF 構文の条件のすり抜けを検査するためです。

>何かしらの処理をしているということはないのでしょうか？
それはありませんね。

No.2 回答者： Glory_777 回答日時： 2015/09/13 13:48

そういった議論が良くなされるので、

仕事での開発ならば、コーディング規約と言うのを作って開発PJ内で統一します。

この内容は自由でして、「特に制約を設けない」という規約を作っても良いです。

こういった規約が何故あるかと言いますと、

プログラムソースを納品するにあたり、作成者が発注者に悪意を持ち、

改行コードを全部抜いて、1行で納品するなどという事件が（昔は）あったからです。

逆に、無駄に改行をいれてライン数を稼ぎ、請求額を水増しすることもありました。

ライン数ｘ単価＝請求額。

という発注の仕方が主流だったからです。

こういった悪意（または作為）に対しては、一定の常識が必要ですよね。

規制する以上、納品物の品質が損なわれるという論法が必要でしょう。

そこで、ソースプログラムを維持するにあたり、

「可読性を阻害するため」

という論法をあてて、幾つかの規約をつくるわけです。

けっして、個人のソースの書き方を擁護したり、否定するために用いる論法ではありません。

また、言語やコンパイラによっては例外節を用いても、コードとして生成されない場合は、

不要な処理を作らないように（いまは大概そうなっているはずですが）なるため、

処理負荷の原因にはならないと思います。

前述事例は極端なものですので、

コーディング規約は、PJ内の意思統一を図るために用いられています。

あたかも一人の人が作成した印象にすることで、作成者の個性の違いを消します。

また必要な情報を記載させるために、定めます。

例えばソースの冒頭に、

「本プログラムソースは、開発案件ｘｘの納品物であり、規約ｘｘに従う。」

と記載しておけば、後に製作者がいなくなっても、納品物であると判別がつきます。

しかし、そういった記述を書くのは面倒です。

こういう部分（冒頭に記載する文章）を規約にしておけば、

全てのソースのヘッダーには、先ほどの前文が挿入されることになるでしょう。

とても良い規約の一つです。


この様に、一般に流布されているソースの記載内容やコミュニティで語られている

作法は、発注元が定めた規約に従っている場合が多く、

これに従事した開発者が、習慣や好みで紹介しているものが大部分のはずです。


金銭を頂いていない開発者はプロではありません。

そのプロがどうやって仕事の料金を得られるのかを考えますと、

コーディング担当として発注元の開発部門から委託されているケースが多いでしょう。

大規模な開発PJに参画した場合は、規約に従い仕事をしているはずです。

（違反した場合は、納品物にならないので、仕方がありません。）

ベテランが集まれば、嗜好での混乱は想定されますから、コーディング規約で統一します。


次にコーディングの位置づけについて誤解があるのでご説明します。

言語が生まれる前は、マシン語をパンチカードで表現し、

これをマシンに読ませて実行させていました。

その時代に、タイプライターがありまして、

これとの融合で開発言語が生まれたわけです。生産性が飛躍的に伸びました。

タイプライターが魅力的であったのであり、”言語”である必要は全く無かった

と言う事です。

今の時代でも言語と言うものが延命されておりまして、キーボードの配列は

タイプライターそのものです。

開発言語の登場当時は、

こうした”仕方ない事情によるナイスアイデア（開発言語）”は歓迎されたでしょう。

しかし同時に、

個人の考えで設計とは別の意図しない記述を混ぜることが気軽にできるように

なってしまいました。

これが多くの問題を生み出しています。


それまでは、図面や文書により思考を続けないと、

設計そのものが出来ませんでした。

パンチカードの穴をみて考えるわけにはいきませんから。

そのため昔も今も開発とは、図面による設計であり、文章による言及なのです。

言語やPC上での開発環境は、パンチカードとリーダーに相当する道具であって、

昔も今も、ソフトウェア開発という行為は、文書による記述です。


なのでプログラマーの扱いは、パンチカードを打ち込む人という扱いになります。

コーダーという差別用語があります。コードを生成する機械です。


例として、

フローチャートを記述した設計書があります（今は主流ではない）。

これには言語が持つ条件分岐や繰り返し処理を記述できます。

ここまで制約されますと、コード自体は誰が書いても同じになります。

同時に、他の言語へ変更する場合も楽になります。

プログラマーが思考をして、コードを記述するという世界は、

存在しなかったと言う事です。


こうした扱いを不満に感じ、PCを進化させ、プログラマーの尊厳を確保しようと言う

動きがありました。

（MSの創始者であるビル・ゲイツは、パンチカードのデバッカーだったそうです。）

Windowsは消費者にアピールを繰り返し、PCとOSを普及させ、

これをベースにC言語を主力とした開発環境を無料で配りました。

（今も継続していますよね）

日本のゲーム業界にアピールし、任天堂と協調しようとしたり（成立しなかった）、

単独でDirectXを作り、これを無料で配り、今で言う洋ゲーの世界を作り上げました。


今わたしたちが携わることが出来るプログラミングの世界は、

こうした戦いの果てに生まれた物といえるでしょう。


さてご質問の例外節ですが、

プログラマーが自分で作成することは出来ないはずです。

もとのIF節ですら、設計書の中で記載されているはずです。

プログラム構造自体は、既に上流工程で完結しており、プログラマーの打ち込みミス

や記述ミス以外ではバグは出ない状態になっています。

ところが設計と言うのは文書や図面ですから、色んな指示ができてしまいます。

例えば設計書には記載されているが、実現方法が検討中であったり、

他の部門が開発中であったり、

次期バージョンによる実装が定められている場合があります。


このときに、設計書には例外節があるが、コードの実態を生成しない。

などと書いてあるときもあるでしょう。


プログラマーにとってはおかしな指示なのですが、

こういう経験が強く印象に残り、

ノウハウとして大事にする人もいるでしょう。

これらを仲間や後輩に指導するかもしれません。（想像ですが）

いずれにしても、仕事の上では勝手に考えてはいけませんよね。

上流工程からの指示文書に従うことです。



例えば、

次期開発により実装が予定されていると、上流工程で定められており、

その旨（空の例外節を記述する）を指示されていたり、コーディング規約で定められ

ている場合に限り、記述するのが正しいでしょう。


個人として実施する場合は、そういった意思（次期開発や他モジュールとの連結予定）

が自分の中にあるとし、

「いずれはここにｘｘｘを記述する。」

とコメントでも残せば良いかと思います。

しかし、これらは汎用的に活用できる極意じゃありません。


また、より正確に可読性を定義するならば、

「指示された内容が文書にて他にあり、

　それと一致するかを確認する受け入れ担当がおり、

　この受けいれ担当が確認することを想定して、

　確認者に見やすくアピールすること。」

です。

（受けいれ試験という工程がありまして、試験に合格しないと納品になりません。）


例えば、

「ｘｘの場合はこうする。それ以外は検討中であり、実装内容は書かないように。」

という設計上での指示もあるはずです。

これを読んだ確認者が指示通りであるかをチェックするとき、

「空の例外節があり、その旨コメントで記載されているはず」と想像します。

これが見つからない無い場合は、設計書を確認します。

例外ルートにIDが振られていた場合は、例外節が必要であると指示するはずです。


逆の場合があったとします。

指示されていない空の例外節があれば、

文書や指示書（設計書や契約書）などを見てやはり確認します。

どういった意図でこのような記述を残したのか？　大問題になります。

（セキュリティホールを作ろうと意図していたか疑われますよ。）

未実装のまま納品しようとしたか、後に改造を試みてタグをうったことになります。

また、例外の必要を認識していたのに、それを隠していたことになります。

もしくは、説明できない暗黙知があり、当事者がこれを言葉化して説明できないか、

表現できないという能力不足になります。


総じて良いことはないと思います。

（受けいれ担当が納得できるように説明できてしまえば、解決しますが）



最後に、

言語の文法以外に、作法という概念があり、これの出所で不明なものが多くあります。

標準的な文法以外のノウハウは、契約時にリセットされると覚えて起きましょう。

ここを深堀しても実効的な技術の上達はしません。

お金を得るときは相手に従い契約どおりにし、必ずこれは確認することです。



趣味で行うときは、

自分の生産性を上げるために、表記法を統一しておくと良いでしょう。

しかし、これで他人と論議をすると大喧嘩になります。

瑣末時ではあっても、頻発し、仲間割れすら起きます。

そこで、お仕事として開発をするときは、

コーディング規約を作ることがPMの責任になっています。



以上、ご参考に成れば。

No.1 回答者： artoo 回答日時： 2015/09/13 12:32

まず、

＞処理負荷etcなところで言うと、コンパクトな方がメモリが見る範囲が～といった内容もあったので、コンパクトにしておくに越したことが無いように思います。
＞また、中の処理が空であれ、elseに入るという行為そのものが、何かしらの処理をしているということはないのでしょうか？
処理がされるのでしたら、やはり邪魔になってくるように思います。

ソースプログラムのサイズ増加は微々たるものです。
また、実行時には何も残りません。elseを書かないのと全く同じです。
つまり負荷面では影響無しです。

空のelseを書くのは、thenに対応したelseが下の方にあるのでは？と目で探しに行くのを途中で止めてくれるというメリットくらいでしょうか。
書かなくて十分見やすければ、書く必要は無いでしょう。
if ～then～else if～then～else if～thenの連鎖が長く続く場合は、最後にelseを入れておいた方が見やすい気がします。
まあ、言語によると言うこともあるでしょうね。