メルマガバックナンバー 第17回
こんにちは、プログラミング書籍の館の江畑です。
今回のテーマはズバリコードの焦げ臭さ(こげくささ)です。
「焦げ臭さ」ってなに?
それはプログラミング中に「あ、このままだとヤバいぞ」という予兆の事です。
早く焦げ臭さに気付かないと、後になってコードが極上のカオスを起こします。
逆に言うと直ぐに察知できれば、問題の発生を未然に防げるわけです。
今回はそんな焦げるパターンをいくつか紹介したいと思います。
「プログラミングあるある」みたいなノリで読んで貰えれば嬉しいです。
私も偉そうなこと言える立場では無いので、反省も込めながら。。。
もくじ
コードの焦げ臭さ
コピペ、コピペ、コピペ、
とりあえずコピペして直して動かす
↓
あとで関数化・共通化しよう
↓
でも面倒だから放置だ放置
こんな事した経験ありませんか?
私は数え切れない程やってます…
もちろんこれを繰り返すとカオスになります。
ちゃんと共通化するのがベスト!
んなことは分かってます。
でも分かっていても、共通化の実装(関数作ったり、クラス抽出したり)とテストで時間を取られるのが嫌なんですね。
特に期限が迫っているときは、共通化してる暇なんてありません。
そのジレンマとどう向き合うか?
前にもメルマガで話しましたが、私はコピペは2回(==重複3箇所)まで許すという妥協策を取ってます。
なお根拠は一切ナシ!の経験則です。
仏の顔も三度までにちなんで、3をブッダナンバーと勝手に呼んでます。
興味のある方は、こちらのバックナンバーコピペはどこまで許される?もご覧下さい。
どんどん長くなる引数
関数やメソッドの引数がどんどん多くなって、ややこしくなる。
そんな現象です。
省略可能な引数ならまだマシですが、必須のやつだと気軽に呼べなくなりますね。
こういう場合よく行うのがオブジェクト化です。
簡単に言うと、関連する引数をまとめて構造体やクラスにする方法です。
例えば start と end をまとめて Range(範囲)を定義するみたいな。
ただこれも一長一短で、モジュール・クラス間の依存が高まるデメリットがあります。
これまで色んな本を読みましたが、どの著者もこの「どんどん長くなる引数」の明解は断言できない様子でした。
だから単純ですが奥の深い問題と言えます。
結局の所、その時々の状況によってオブジェクト化する、という事になるでしょうか。
うーん実にあいまい。
ちなみに DirectX9 の D3DXCreateFont関数 には引数が11個もあります。
さすがにコレは何とかして欲しかった…
フラグが多すぎる問題
ソースの中にフラグが多くなってくると危険です。これはマジです。
大雑把な言い方ですが、フラグは「例外措置」みたいなものです。
これが目立って増殖すると、例外がこんがらがって制御不能になります。
特に、if文の中で更に別のフラグを設定するケースは危険な兆候です。
if(フラグA){
フラグB,フラグCを設定
}
またフラグのtrueとfalse両方にデカい処理ブロックがあるのも、かなり怖いです。
if(フラグ){
デカい処理ブロック
}
else{
デカい処理ブロック
}
初心者ほどやってしまいがちなので、気を付けて下さい。
対策はアルゴリズムを見直すこと、これに尽きます。
私の経験上シンプルなアルゴリズムにすれば、フラグの数は大きく減らせます。
この「シンプルさ」を保つというのは、本問題に限らず、カオスを防ぐ本質です。
修正の散弾銃
軽微な変更(例えば文字サイズを変えるとか)するだけなのに、あちこちに修正が必要になっちゃう現象です。
むかし私はウィンドウの位置を変えても、ボタンが元の場所に居続けるコードに出会った事あります。
この場合はデータ構造やクラス設計を見直す必要があります。
関連するデータを同じオブジェクトに集める、関数やメソッドを移動する、共通部を抽出するなど
出来るなら一つの機能は、一箇所(1クラス、1モジュール、1メソッド)の修正で済むようにしたいものです。
まあ既に組み上がってるものを保守する時は、そうも行かないんですけどね。
仕事では盛大にカオスってるソースを、ポンと丸投げされることもありますから…
おすすめ書籍
以上「コードの焦げ臭さ」について4つ紹介しました。
もちろんこれだけでなく、他にも様々なパターンがあります。
もっと色んなケースと対策を知りたい方には、以下の書籍をオススメします。
どれも歴史的名著なので、パラパラ拾い読みするだけで役立ちます。
リーダブルコード~より良いコードを書くためのシンプルで実践的なテクニック~
Twitterハイライト
こんな事つぶやきました
レトロゲームとアダルト描写の関係
昔のファミ通より、なかなか攻めた企画
「ファミコンでHはどこまで表現できるのか?」おふざけと思いきや…
今読むと秀逸な内容で、表現ラインがあいまいだった時代状況がよく分かる
メーカーごとに見解が異なるのも興味深い#レトロコンシューマー愛好会 pic.twitter.com/K2c3ytUEJe— K-Eba@プログラミング書籍の館 (@EndymionProgram) 2019年7月12日
ゲーム広告と謎の子供
レトロゲームの広告あるある
ドヤ顔を決める謎の子供写真は怒3
ラルフでもクラークでもないテキトーなコス
せめてバンダナの色くらい合わせろと言いたい#レトロコンシューマー愛好会 pic.twitter.com/kxG3qcLjxW— K-Eba@プログラミング書籍の館 (@EndymionProgram) 2019年6月6日
8730通から選ばれた8人
ロックマン2 ボスキャラ発表!
本作はシリーズで初めて、ボスキャラの公募が行われました応募総数じつに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に緑広場で待ち合わせましょう」
と書いてあった。さて犯人は次のうち誰か?推理して欲しい。
1:栗山 学 大学生
2:橋田 清 消防士
3:石元 健一 駅員
正解は3の石元健一(駅員)でした。
その理由は
午後6時を18:00と呼ぶのは駅員だから!
です。
あ、物を投げないで下さい…
トホホな答えですが、マジで昭和の本にあった問題なんです。
なお今回は正解した方はいませんでした。反省してます。
ちなみに興味深い解答として
犯人は1の栗山学(大学生)
理由:学生にはOLの良さが分からないから
というのがありました。
うむむ、妙な説得力を感じる。
ろんりが!キャンペーン
では今回のクイズです。
私が作ったろんりが!というブラウザゲームを使ったキャンペーンです。
——————–
【問題】
このゲーム、全40面をクリアするとスタッフロールが流れます。
その中で一つだけ他と色が異なる単語があります。
さて、その単語とは何でしょうか?
——————–
※1回クリアするとスタッフロールは何度でも見られます
ウソみたいだろ…
このクイズをやりたいがために、開発から仕込んでおいたネタなんだぜ。
ただ自分でプレイしても後半のステージは超絶な難易度なので、人類には早すぎたような気もしてます…
果たしてクリア者はいるんだろうか。不安になってきたぞ。
分かった猛者は本メールに返信してご応募下さい。
※募集は終了しました
正解した方の中から抽選で3名様に、Amazonギフト券コード(キャリーオーバーで1000円)を送信致します。
1人しかいなかったら、3000円は総取りです。
今回はここまでです。読んでいただきありがとうございました。
プログラミング書籍の館 江畑