コードの焦げ臭さ

メルマガバックナンバー第17回

こんにちは、プログラミング書籍の館の江畑です。

今回のテーマはズバリコードの焦げ臭さ（こげくささ）です。

「焦げ臭さ」ってなに？
それはプログラミング中に「あ、このままだとヤバいぞ」という予兆の事です。

早く焦げ臭さに気付かないと、後になってコードが極上のカオスを起こします。
逆に言うと直ぐに察知できれば、問題の発生を未然に防げるわけです。

今回はそんな焦げるパターンをいくつか紹介したいと思います。
「プログラミングあるある」みたいなノリで読んで貰えれば嬉しいです。

私も偉そうなこと言える立場では無いので、反省も込めながら。。。

コードの焦げ臭さ
Twitterハイライト
クイズ昭和のミステリーの答え
ろんりが！キャンペーン

コピペ、コピペ、コピペ、

とりあえずコピペして直して動かす
　↓
あとで関数化・共通化しよう
　↓
でも面倒だから放置だ放置

こんな事した経験ありませんか？
私は数え切れない程やってます…

もちろんこれを繰り返すとカオスになります。

ちゃんと共通化するのがベスト！
んなことは分かってます。

でも分かっていても、共通化の実装（関数作ったり、クラス抽出したり）とテストで時間を取られるのが嫌なんですね。
特に期限が迫っているときは、共通化してる暇なんてありません。

そのジレンマとどう向き合うか？

前にもメルマガで話しましたが、私はコピペは２回（==重複３箇所）まで許すという妥協策を取ってます。
なお根拠は一切ナシ！の経験則です。
仏の顔も三度までにちなんで、３をブッダナンバーと勝手に呼んでます。

興味のある方は、こちらのバックナンバーコピペはどこまで許される？もご覧下さい。

どんどん長くなる引数

関数やメソッドの引数がどんどん多くなって、ややこしくなる。
そんな現象です。
省略可能な引数ならまだマシですが、必須のやつだと気軽に呼べなくなりますね。

こういう場合よく行うのがオブジェクト化です。
簡単に言うと、関連する引数をまとめて構造体やクラスにする方法です。

例えば start と end をまとめて Range（範囲）を定義するみたいな。

ただこれも一長一短で、モジュール・クラス間の依存が高まるデメリットがあります。

これまで色んな本を読みましたが、どの著者もこの「どんどん長くなる引数」の明解は断言できない様子でした。
だから単純ですが奥の深い問題と言えます。

結局の所、その時々の状況によってオブジェクト化する、という事になるでしょうか。
うーん実にあいまい。

ちなみに DirectX9 の D3DXCreateFont関数には引数が11個もあります。
さすがにコレは何とかして欲しかった…

フラグが多すぎる問題

ソースの中にフラグが多くなってくると危険です。これはマジです。

大雑把な言い方ですが、フラグは「例外措置」みたいなものです。
これが目立って増殖すると、例外がこんがらがって制御不能になります。

特に、if文の中で更に別のフラグを設定するケースは危険な兆候です。
if(フラグA){
　フラグB,フラグCを設定
}

またフラグのtrueとfalse両方にデカい処理ブロックがあるのも、かなり怖いです。
if(フラグ){
　デカい処理ブロック
}
else{
　デカい処理ブロック
}

初心者ほどやってしまいがちなので、気を付けて下さい。

対策はアルゴリズムを見直すこと、これに尽きます。

私の経験上シンプルなアルゴリズムにすれば、フラグの数は大きく減らせます。
この「シンプルさ」を保つというのは、本問題に限らず、カオスを防ぐ本質です。

修正の散弾銃

軽微な変更（例えば文字サイズを変えるとか）するだけなのに、あちこちに修正が必要になっちゃう現象です。

むかし私はウィンドウの位置を変えても、ボタンが元の場所に居続けるコードに出会った事あります。

この場合はデータ構造やクラス設計を見直す必要があります。
関連するデータを同じオブジェクトに集める、関数やメソッドを移動する、共通部を抽出するなど

出来るなら一つの機能は、一箇所（1クラス、1モジュール、1メソッド）の修正で済むようにしたいものです。

まあ既に組み上がってるものを保守する時は、そうも行かないんですけどね。
仕事では盛大にカオスってるソースを、ポンと丸投げされることもありますから…

Twitterハイライト

こんな事つぶやきました

レトロゲームとアダルト描写の関係

昔のファミ通より、なかなか攻めた企画
「ファミコンでＨはどこまで表現できるのか？」
おふざけと思いきや…
今読むと秀逸な内容で、表現ラインがあいまいだった時代状況がよく分かる
メーカーごとに見解が異なるのも興味深い#レトロコンシューマー愛好会 pic.twitter.com/K2c3ytUEJe
— K-Eba@プログラミング書籍の館 (@EndymionProgram) 2019年7月12日

ゲーム広告と謎の子供

レトロゲームの広告あるある
ドヤ顔を決める謎の子供
写真は怒３
ラルフでもクラークでもないテキトーなコス
せめてバンダナの色くらい合わせろと言いたい#レトロコンシューマー愛好会 pic.twitter.com/kxG3qcLjxW
— K-Eba@プログラミング書籍の館 (@EndymionProgram) 2019年6月6日

8730通から選ばれた8人

ロックマン２　ボスキャラ発表！
本作はシリーズで初めて、ボスキャラの公募が行われました
応募総数じつに８７３０通
その中から栄えある採用となった８体の発表号です
ちなみに私も自信作「アックスマン」で応募しましたが・・・#レトロコンシューマー愛好会 #ロックマン pic.twitter.com/HE4cRB36au
— K-Eba@プログラミング書籍の館 (@EndymionProgram) 2019年6月26日

マジでよく分からんカプコンの広告

カプコンスーパー宣言
なんか変なおっさんが訴えかける広告
意味は分からんが、凄さは伝わったと思う#レトロコンシューマー愛好会 pic.twitter.com/d8ysmlHGEO
— K-Eba@プログラミング書籍の館 (@EndymionProgram) 2019年7月10日

ファミコンに吹いた奇跡の追い風

本日は #ファミコンの日
ファミコンが大成功した理由は色々ですが、大きな一つが風俗営業法の改正
改正で子供がゲーセンへ行けなくなり
　ゲーセンでドンキーコングできない→じゃあファミコンで遊ぼう！
となりました
上村雅之氏いわく、奇跡の追い風だったそうです#レトロコンシューマー愛好会 pic.twitter.com/poOTk1DIGl
— K-Eba@プログラミング書籍の館 (@EndymionProgram) 2019年7月15日

クイズ昭和のミステリーの答え

さて、前回出題したクイズ昭和のミステリーの答えです。
こんな問題でした。

ある年の12/25、OLのAさんが何者かに殺された。
警察がAさんの部屋を捜索したところ、手紙を発見する。
そこには
「12/25の18：00に緑広場で待ち合わせましょう」
と書いてあった。
さて犯人は次のうち誰か？推理して欲しい。
１：栗山学　大学生
２：橋田清　消防士
３：石元健一　駅員

正解は３の石元健一（駅員）でした。

その理由は
　午後6時を18:00と呼ぶのは駅員だから！
です。

あ、物を投げないで下さい…
トホホな答えですが、マジで昭和の本にあった問題なんです。

なお今回は正解した方はいませんでした。反省してます。

ちなみに興味深い解答として
　犯人は１の栗山学（大学生）
　理由：学生にはOLの良さが分からないから
というのがありました。

うむむ、妙な説得力を感じる。

ろんりが！キャンペーン

では今回のクイズです。

私が作ったろんりが！というブラウザゲームを使ったキャンペーンです。

——————–
【問題】
このゲーム、全40面をクリアするとスタッフロールが流れます。

その中で一つだけ他と色が異なる単語があります。
さて、その単語とは何でしょうか？
——————–
※1回クリアするとスタッフロールは何度でも見られます

ウソみたいだろ…
このクイズをやりたいがために、開発から仕込んでおいたネタなんだぜ。

ただ自分でプレイしても後半のステージは超絶な難易度なので、人類には早すぎたような気もしてます…
果たしてクリア者はいるんだろうか。不安になってきたぞ。

分かった猛者は本メールに返信してご応募下さい。
※募集は終了しました

正解した方の中から抽選で3名様に、Amazonギフト券コード（キャリーオーバーで1000円）を送信致します。
1人しかいなかったら、3000円は総取りです。

今回はここまでです。読んでいただきありがとうございました。

プログラミング書籍の館江畑

コードの焦げ臭さ