制作日記

こういうの作った方が、逃げにくいじゃない

クソコードをリファクタリング

そろそろ、広告出そうなんで
MUGENはなんか気になったのあったら調べるわ


http://blue1st.hateblo.jp/entry/2016/08/23/235506

衝撃的だった、リファクタリング結果のほうが糞やんけ
褒められる点はdrawの判定方法だけなんだよなあ
これはクソだと思ってるけど、リファクタリングとして適切であるなら
後学のためにどこが良いのか教えてほしいわ
jsもperlもよく知らんが、それでもこれはクソコードやなって思った

勝敗結果を標準出力に吐かずに文字列を返す点
実行結果変えておいて、リファクタリング名乗るのやめてもらえません?
関数も小さいのに可搬性とか考慮されてもなあ、必要になった時に書いたほうが早いよね
文字列返すのも標準出力に出力するのもテストの手間は大してかわらんというか
適切に判定できることに加えて、適切に結果が"出力されること"のテストが必要
ユースケースもわからん状態で敢えてやる必要性は感じない

「# 前の手に勝つ順番でリストを記述」の部分
リスト弄れば手が増えても対応できるとか拡張性考えてるのか知らんが
これからハッシュ作成してっていうのは3手だから可能なのであって
RPS7とか手が増えると成立しないんですが

「# 手をキーとしたとき、負ける手が取れるようにする」
変化しないhashを毎回動的に作成するという、汚物まき散らしクソコード
こんなもん静的かつROで持っとくべきなんだよなあ
生成用のリストをハードコーディングしてるなら
リストを書かずに、hash生成自体をハードコーディングしたほうが遥かにマシ
スマートに書いたつもりがアホコード書いてる典型例

おかげでじゃんけんというくっそ簡単な処理なのに
ぱっと見でじゃんけんだと理解できないクソコード
これコードレビューで出されたら、一から書き直させる

自分が実装するならCになっちゃうけど
普通に初めのコード書く or 2次元配列で勝敗のリストを静的に持っておいて、それ参照
配列定義するとこで丁寧にコメント書いておけばええ話やし?

GAのジャンケン十三奥義みたいな、ふざけた手を考慮せず
一定の関係性を保って手が増える前提なら、各手と勝敗の関係性を書くかな
RPS7なら、Rock、Water、Air、Paper、Sponge、Scissors、Fireやろ
どっかの円形になってる図を見ればわかるけど
自身の手から時計回り3つに負ける、その次の3つに勝つ、自分はあいこっていう関係
ちょっと一手間いるけど、各手に番号振って、差分取るだけやで

3手ならくっそ簡単
グー、チョキ、パーに0、1、2と番号振って、自身の手をa、相手の手をbとすると
a == bならあいこ、(a+1)mod3== b なら勝ち、他の(a+2)mod3== bは負け

それがどうしてあんなクソコードになるんですかね
プロフィール

Author:drab
霊夢改変キャラ
「12 3 ! {V} [_]」
公開中
L霊夢でもl_reimuでも好きなように読んでください

最新記事
最新コメント
月別アーカイブ
カテゴリ
検索フォーム
RSSリンクの表示
リンク