「世界一IQの低い」ソースコード 235
ストーリー by hylom
定期的に出てくる酷いコードの話題 部門より
定期的に出てくる酷いコードの話題 部門より
Twitterに投稿された、「世界一IQの低いソースコード」が話題になっている。
このコードは書籍にサンプルコードとして掲載されたもので、延々とif～else文が続くというもの。とはいえ、プログラミングの初心者が書きそうなコードではある。
Twitterに投稿された、「世界一IQの低いソースコード」が話題になっている。
このコードは書籍にサンプルコードとして掲載されたもので、延々とif～else文が続くというもの。とはいえ、プログラミングの初心者が書きそうなコードではある。
未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー
手抜きのできない奴はプログラムをやるべきではない (スコア:4, 興味深い)
とはいうものの，プログラム自体，
2KB～8KBぐらいのBASICから始めてるから
無駄で冗長なものが許せないだけなのか。
プログラムの初心者に教えることは
「ラクをしろ」
「ロジックにデータを混ぜんな，外に出せ」
「サブルーチンでうまく使い回せるように（関数はまあ，後だ）」
ぐらいなもん。
まあ，else if を３回ぐらい繰り返したあたりで，
「もっと良い手があるんじゃないか」と考えることができなければ，
日曜プログラマすら向いてないような。
とはいえ，小学６年生にArduinoをどう教えるか，
と入門書もどきを作る羽目になっていて，その辺の信念も揺らいではいるがｗ
（ラクに教えるなら，Arrayとかは抜きにしたほうが早いから）
【重要】ここがアマチュアとプロの違い (スコア:2, おもしろおかしい)
坊主、若いな。
私も若いころはエレガントなコードを書こうとしたさ。
でも、それは結局自己満足でしかないんだ。
●生産性について
コード行数を人月で割った指標で評価で、生産性が評価されます。
「もっと良い手があるんじゃないか」とか余計なことを考えて浪費される時間や、
コードが短くなることで、成果（アウトプット）が減少することを考えてください。
コード品質なんて、客に見えないものは実績評価の対象になりません。
●可読性について
リフレクションとかswitch文とかトリッキーな文法を使うと、ソースの可読性が低くなります。
忙しい上司の身になって、(300行のif文を書くなど)素直な解りやすい書き方に統一してください。
私の上司(55才、元4ビットマイコンのプログラマー)の有りがたい教えをまとめてみました。
Re:手抜きのできない奴はプログラムをやるべきではない (スコア:2)
深い意味はない（自分語りだと思うなら無視しろよｗ）。
短いソースを書くことが善，ってこと自体が
昔の限られたリソースで育ったからかなあ，と。
Re:手抜きのできない奴はプログラムをやるべきではない (スコア:2)
メンテも込みで「ラク」を目指せると吉。
でも，それはさすがに初心者に無理。
デバッグの段階で「こりゃダメだ」と一度経験すれば，多少は気を付けるというか。
メンテしにくいコードといえば，件のサンプルコードがまさにそれっすよね。
Re:手抜きのできない奴はプログラムをやるべきではない (スコア:2)
まあ，コピペで済ませるなら，
せめて筋のよいものをコピペしたいよね。
（ツイートで言ってたリフレクション使った奴とか）
入門書でelse ifがエンドレスしたコードを
「アリ」として紹介するのは害悪以外の何者でもないですねえ。
真似されたら困るなあ。
Re:手抜きのできない奴はプログラムをやるべきではない (スコア:2)
行数も稼げるし時間もそれなりに経過してゆくから、これこそが楽して給料をもらう手法。だったりして
Re:手抜きのできない奴はプログラムをやるべきではない (スコア:2)
Re:手抜きのできない奴はプログラムをやるべきではない (スコア:2)
ロジックが明確に表現できるのなら，
記述が冗長になるのはむしろウエルカムな気がします。
Cプリプロセッサパワーを読んで学んだことですがｗ
システム開発に従事して１１年目 (スコア:4, 興味深い)
Re:システム開発に従事して１１年目 (スコア:2)
もしかしてエンドレスエイト (スコア:2, 興味深い)
「プログラム」の初心者向けということなら、まず if else の羅列を見せてうんざりさせてから switch を教えるというのはありだと思う。
大昔、私が初めて「プログラム」という仕掛けを知った時の本(多分ブルーバックス)での BASICの説明がこんな調子だった、多方向分岐も条件ループも IF文とGOTO文だけのプログラムで動きを示してから、ON だの FOR だのそれぞれの構文を示していた。
Re:もしかしてエンドレスエイト (スコア:2)
ややズレますが、switch文 という話だと、『単純に置き換えていい』と思わせちゃっていいのかな？ と：
Stringとかオブジェクト類 だと、ちょっと意図と変わりますよね (中身でなく、同一インスタンスかどうか の比較だから)。
こういう状況で 文字列比較したいわー というとき よくありますけど、
Javaのswitchだと その周りの理由で 正しく中身の比較 にならなかったと思います。
//まあ、『==』をまんま置き換えてるだけなので、Javaの『==』の仕様ですが。
//JavaScriptだと 比較とか型とか適当だから 勝手に合わせて 中身の比較にしてくれたりしたような。
比較周りの話で教えるべき かもしれませんけど、意外とswitch あんまり簡単でもないよなー、と。
//数ページずらー が ないわー；とは思います(；^ω^)
Re:もしかしてエンドレスエイト (スコア:2)
Java の switch では、Java6以前だと 整数とenumだけでそれ以外のオブジェクトは使えなかったと思います。
7 で String が使えるようになり、equals による中身の比較を行うようです。
ついでに言えば、一つの switch の中で 整数やStringを混ぜて使うなんてこともできないです。
むしろ、JavaScript の switch の方が、=== のまんま置き換え、となるようです。
（https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/switch）
=== による比較なので、== とは違って、型を勝手に変換したりもしないみたいです。
文字列同士の場合に中身の比較になるのは、JavaScriptの === の仕様ってことになるのでしょうね。
svn-init() {
svnadmin create .svnrepo
svn checkout file://$PWD/.svnrepo .
}
Re:もしかしてエンドレスエイト (スコア:2)
あ、昔は そもそも型で弾かれて使えない → 今 文字列の中身比較になった；なんですね。
ちょっと間違えて覚えてたようです。
Re:もしかしてエンドレスエイト (スコア:1)
＞「プログラム」の初心者向けということなら、まず if else の羅列を見せてうんざりさせてから switch を教えるというのはありだと思う。
それでも3回繰り返したらわかりそうっすね。
Re:もしかしてエンドレスエイト (スコア:1)
なるほど
だからsync; sync; syncと3回繰り返すんですね（多分違う）
Re:もしかしてエンドレスエイト (スコア:3, 参考になる)
2回までは理由あります。
1回目のsyncがブロッキングコールなので、2回目が走るときは1回目が終わってることが保証されたはず。
3回目の理由は知りません。おまじない？
＃これ、特定の実装に依存して「3回」じゃないのかなぁ？
＃STOP-A sync は書き込み終わるまで帰ってこなかったような
Re:もしかしてエンドレスエイト (スコア:3, おもしろおかしい)
sync 自分の為
sync みんなの為
sync 念の為
擁護するつもりは毛頭ないが (スコア:2)
初心者向けならこれでいいんじゃないかね？
イベントクラスやらAPI使えばラクだけど初心者にはそこからまず説明しないといけないわけだし
古い本ならバージョンごとのことを考えるとイベントが用意されていないときのことも考えてローテクで泥臭い手法で実装するなんてことは別に珍しくもないわけだし。
# ちなみにハゲではありません
# が、将来にわたってハゲでない保証もありません
文句を言う資格のある奴はより良い案を出した奴だけだ。 (スコア:2)
Re:文句を言う資格のある奴はより良い案を出した奴だけだ。 (スコア:2)
ここは、C/C++ならマクロの出番なんでしょうけどねぇ…
#define KEYTOSTRING(code) case KeyEvent.KEYCODE_##code: ret = "KEYCODE_"#code; break
KEYTOSTRING(1);
KEYTOSTRING(2);
KEYTOSTRING(3);
…
Re:文句を言う資格のある奴はより良い案を出した奴だけだ。 (スコア:2)
> "KEYCODE_1"のIDが本当に8でよいのかどのようにコードレビューしますか？
･ω･ 。o ( ドキュメントを見るんだ！ )
KeyEvent | Android Developers [android.com]
public static final int KEYCODE_1
Added in API level 1
Key code constant: '1'
key.Constant Value: 8 (0x00000008)
羅列よりもスペースがあるべき所に無い方が気になる… (スコア:2)
最近の人はK＆Rとか読まないんだろうね。
このコーディングスタイルは気持ち悪くて、ソース整形ツールで直したくなる。
Re:羅列よりもスペースがあるべき所に無い方が気になる… (スコア:2)
いや、IDE使ってる奴も変なコーディングスタイルでかいてるぞ
そもそも、わざわざ整形する人は少数派な気がする
Re:羅列よりもスペースがあるべき所に無い方が気になる… (スコア:2)
相当前だけど2回は読んだ
しかし、複数人のプロジェクトだとそれは全く違うよ
周りに合わせる事が重要だと普通は書いてあるよ (当たり前の事だと思うが)
その時に共通認識としてK＆Rがあると思ってたけど
昔メンテしたコード (スコア:2)
Xのイベント処理が延々３０００行以上（もしかしたら、もっとだったかも。）。（X toolkitは使われず、全部Xlib）
違う会社の人が書いたコードのため、「もう捨てましょう」とも言えず…
あ、当然、まともに動きませんでしたよ。どうしてもって部分を、修正してお茶を濁しました。
のけぞる本 (スコア:2)
のけぞる本リストに追加しておいたら初学者の人の参考になるんじゃないですかね
時代 (スコア:2)
KeyEvent.keyCodeToString() を使えばすぐみたいな指摘もありますけど、2010年の本らしくて当時はそのメソッドはなかったって話もあるみたいですね。
確かに1対1だとこれは考えちゃいますが(汗
Re:時代 (スコア:2)
では、API Level 1の
else if ( keyCodeMap.isPrintingKey(keyCode)) {
ret = "KEYCODE_" + Character.toString(keyCodeMap.getDisplayLabel(keyCode));
}
で ( 26 + 10 ) x 2 行を置き換える案 ・ω・
# keyCodeMap.isPrintingKey 自体には 22文字ほど記号も含まれています
もしかして高速化のため？ (スコア:1)
最適化の期待できないVMで高速に動かすためのテクニックだったりして。（たぶん過去の遺物だと思うけど）
# 組込機器のjavaでリフレクション使って怒られた経験から。
notice : I ignore an anonymous contribution.
Re:もしかして高速化のため？ (スコア:2)
それにしたって、「自動生成されたコードがこうなってました」ならまだしも、こんなの手で打ち込むとかありえないでしょ。
Re:もしかして高速化のため？ (スコア:1)
ちなみに現在(API12(Android 3.1)以降)は、標準で変換できるKeyEvent#keyCodeToStringという専用メソッドが用意されてるので、それなりに需要はあったのかなーと
http://developer.android.com/reference/android/view/KeyEvent.html#keyC... [android.com]
Re:もしかして高速化のため？ (スコア:1)
ダイナミックにキーコードが変化するんだよ
予想通り (スコア:1)
予想通り小飼がtwitterコメントに湧いてて笑った
基礎から (スコア:1)
Re:これだけではなんとも (スコア:2)
もしかしたら、写経とかそういう修業の一環なのかもしれない。
Re:これだけではなんとも (スコア:5, おもしろおかしい)
16進ダンプを延々入力してたI/O読者には遠く及ばない。
Re:これだけではなんとも (スコア:1)
確かにアレは写経異常じゃなくて以上だ。
でも、チェックサムがあるだけDQ2復活の呪文よりはましかもね。
#むやみにオフトピ
打ち込む作業は写経だったのですね (スコア:2)
ソースコードを打ち込む作業は写経だったのですね。
1982年当時「はるみのゲーム・ライブラリー」PC-8001版 BASICをコツコツ写経しましたよ。
ところで今は21世紀なのに復刻！はるみのゲーム・ライブラリー（P8版） [applion.jp]が
iPhone用アプリ（400円）として販売中です。お笑いネタとして400円出す人もいるかもしれない。
（当時BASICのプログラムを「ソースコード」と呼んでいなかった気もしますが記憶あやふや）
Re:打ち込む作業は写経だったのですね (スコア:2)
すげー、芸夢狂人さんとか思い出したけど、あちらだと版権絡みそう。
#kanimiso って誰が作ったゲームか忘れたけど面白かった。
Re:これだけではなんとも (スコア:1)
＞書籍で4ページも費やしていること以外は
テーブルを使わないということじゃなくて、サンプルコードとしてこげなものに4ページをも費やしたこと自体が問題ということじゃあ。
(1ページや2ページならともかく)
Re:これだけではなんとも (スコア:5, すばらしい洞察)
Amazonで調べて見たところ、件の書籍はこれですよね。
⇒ http://www.amazon.co.jp/%E5%9F%BA%E7%A4%8E%E3%81%8B%E3%82%89%E5%AD%A6%... [amazon.co.jp]
# ダウンロードサイトの方は、こちらでしょうか。
# ⇒ http://www.ks-pro.org/Home/candr-android [ks-pro.org]
表紙のイメージ(2枚目の方)で『開発環境の構築から配布までを、具体的なサンプルの作成
を通じて開発手順を解説』とあるので、少なくとも利用する言語については知識があること
を前提としていると考えて差し支えはないでしょう。
したがって『if-elseだと面倒なので、switch-caseとかテーブルを使いましょう』等の言語
に関する説明を行う意味や必要が無いので、『単に著者が普段書いているものを出した』と
考える方が自然だと思います。
# わざわざ書く必要があると思っているならば、それはそれで別の意味で問題ですが。
これを踏まえると、『著者が(Javaを含め何かを)理解できていない』『著者が人にものを教
えられるほどの実力(プログラミング含む)がない』にも関わらず、Androidの話題性に便乗
して書いたとしか、私には思えません。
むろん、編集は書籍の専門家であり、コンピュータの専門家ではない方が自然だと思います
ので、中身の検証は期待できないでしょうし。
# 他の書籍でもこの様な事を見かける事がありますが、Cで言えば『`#include '
# はおなじない』とか、中身を理解出来ていないか、きちんと説明できないのに書いている
# ようなものを平気で出しているのと同じ…と言う事では?
Re:これだけではなんとも (スコア:1)
この人フォローしてますが、フリーランスで他社で新人研修したりもしてるみたいなので、（教材として）初学者向けの本を買ってみることはおかしくないです。
Re:だめなコード見てどうこういうのではなく (スコア:1)
> 優れたコードを見て感じ入るほうがよくないですかね？
優れたコードを見て感じ入るってのは、達人への道なんだよね。そうじゃない人は優れたコードのどこが凄いのかが全く分からない。そして世の中、そうじゃない人が大多数だったりする訳だ。
Re:だめなコード見てどうこういうのではなく (スコア:1)
まあtwitterだからなんだこりゃと思った感情を何も考えずにそのまま書いたんだろうけど
とはいえそういうなにげないコメントから人間性とか考え方が透けて見えてきちゃうところが
バカ発見器と言われるところですな
Re:だめなコード見てどうこういうのではなく (スコア:5, 参考になる)
Twitterでもコメント(発信者にRT)したんだけど、Amazonの☆２のレビュー見たらもっとひどいことが書いてあったんだな・ω・
http://www.amazon.co.jp/product-reviews/4863540450/ie=UTF8&filterB... [amazon.co.jp]
『Android開発にあたって購入したが、リフレクションを使えば10行程度で書けるコードを
6ページにまたがるelse ifの山で記述したサンプルコードを見た瞬間に投げ捨てた。』
『実際に読んでいくと、一つ一つのつながりが無く
何をどうしたら、こうなるのかというのが、全くと言って良いほど解らない本でした。』
『本書内での加速度に対する記述（理解）が一貫して誤っている
（加速度センサーに関するコーディングの間違いではなく、加速度という物理量の次元や、極基本的な物理的意味を一貫して誤解して記述されている）。
力学の教科書ではないとはいえ、これは別の意味で大問題である』
『既存スケジュールを上書きして登録してしまう、割と大き目のバグ。
サンプルコードにかなり痛いバグが残っているのは、この手の書籍にとっては致命的だと思います。』
逆を突き詰めた珍書ですねｗ (スコア:2)
あれ，そんなにひどかったっけ（棒）
まあ，少年時代，手に入れたわけですが，
実践できなくて，「ああ，おれは駄目なんだ」と悩んだことすらありますｗ
純真ですね。今だったら叩きつけてると思います。
Re:炎上商法 (スコア:4, おもしろおかしい)
Amazonなら\125円 コンディション - 床に投げつけられた跡があります。
Re:IFネストの山といえば (スコア:2)
CHOOSE関数のことか？
http://office.microsoft.com/ja-jp/excel-help/HP010069830.aspx [microsoft.com]
Re:COBOLで (スコア:2)
01 IQ PIC 99.
だったりしない？