酷いコードを収集する「ウンコード・マニア」 143
ストーリー by hylom
笑えないコード多数 部門より
笑えないコード多数 部門より
あるAnonymous Coward 曰く、
「ウンコード・マニア」という、「クソなコード」を収集・観賞するというサイトが最近オープンした模様。
「人気ウンコード」には、関数の最後が『return 0;』であったためにどんな単体テストも通ってしまうコードや、128個のcaseが並ぶswitch文、大量の再発明された車輪、謎の連番で命名されたクラス名/メンバ変数名など、リアルにクソなコードが並んでいる。
笑えるコードであればいいのだが、センスもなくただただコードを書いた人が残念だというコードばかりなのでチェックするのも苦痛である。それでも興味のある方はどうぞ。
「Ｃプログラミング診断室」を思い出しました (スコア:2)
すらっしゅどってっど？ (スコア:2)
色々なところで取り上げられてきてるためか大分不安定になってますね。
負荷が高いんでしょうか。
Re:すらっしゅどってっど？ (スコア:3, おもしろおかしい)
の
Re:すらっしゅどってっど？ (スコア:1)
最初「ウンコード」って見た時
uuencode の誤読かと思った。
Re: (スコア:0)
エラーで見られませんね。
サイトもウンコードで書かれていて止まったのかな?
Re: (スコア:0)
さくらVPSっぽいから大目に見ましょう。
n=n++; (スコア:1)
嗚呼、まじかる☆さゆりんは逝ってしまったorz
Rubyの例がまだない。 (スコア:1)
載っていないからといって、Rubyはクソコードがないかというとそうでもない。
自分自身が過去に書いたRubyスクリプトを今見直したら結構ひどかった。
例１：
配列にfillメソッドがあるのに、for文で全配列に同じ値を入れる初期化関数
例２：
Rubyらしい書き方といえばイテレータによる繰り返し。
しかし、ベンチマークを取ったら繰り返しはイテレータではなく、C言語に近いfor文を書いた方がベンチマークでの速度がアップすることに気づいてからは、配列は基本的にイテレータで書いていた。
ただし、連想配列に対してはfor文を適用する方法を知らなかったからイテレータというふうに使い分けていた。
自己フォロー。 (スコア:1)
例２：
配列は基本的にイテレータで書いていた。
→配列の全検索などは基本的にfor文で書いていた。
Re:自己フォロー。 (スコア:2)
例2が，例1に含まれていますよ．
結局「ウンコード」ってのは，記述が冗長，拙い，ってことなんでしょうね．
ちっちゃい事が気になった (スコア:1)
こういうコードの断片の著作権ってどうなるんだっけ？
と思ってたら注釈がありました。
http://unkode-mania.net/about [unkode-mania.net]
> ただし、投稿するウンコードは自分で創作したものだけにして下さい。
全部「創作」だったのか・・・
何がだめかじゃなくて (スコア:0)
何がいいかでソースコードを語って欲しい。
# 昔、ボツの杜というのがあってな
Re:何がだめかじゃなくて (スコア:1)
駄目なコードは例を出すのが簡単だけど、
非の打ち所のない理想的なお手本を作るのは非現実的だからね。
糞コードから議論を始めるのは、極めて現実的な手法だと思う。
Re: (スコア:0)
完璧てそもそも存在しないんじゃない？
将来の拡張性をどう想定するかで変わってくるし。
ここを詰めようとすると、議論が発散しがちでしょ。
逆に駄目なやつは、常に駄目ってケースがあるからね。
糞コードが駆逐された世界なんて天国じゃん。
サイコード・マニア (スコア:0)
じゃあ、最高なコード、サイコード・マニアを開催しようぜ。
まずは冪集合 powerset を求めるこの Haskell コード。初めて見たとき驚愕した。
powerset :: [a] -> [[a]]
powerset xs = filterM (\x -> [True, False]) xs
( http://learnyouahaskell.com/for-a-few-monads-more#useful-monadic-functions [learnyouahaskell.com] )
これだけ。filterM は標準ライブラリ関数。使うとこうなる。
g
Re: (スコア:0)
その例は強力なリストモナドをしょぼく使っているのでサイコーとは思わない
filterMの引数がconstじゃろ
Re: (スコア:0)
じゃあちょっとリファクタリングして
powerset = filterM $ const [True, False]
でどうかな。
かっこいいリストモナドのサンプルも頼む。
Re:何がだめかじゃなくて (スコア:1)
> たとえば、言語の入門書を見れば、いいコードの例がありますが
入門書が地雷ということも当たり前のようにあるのが恐ろしいところで…
Re:何がだめかじゃなくて (スコア:2)
Re:何がだめかじゃなくて (スコア:1)
アスキーの「入門C言語」「実習C言語」「応用C言語」3部作に頼ったおかげで、
しばらく標準的なCの記述ができませんでした。
入門書よりも、より多くのソースを読むことが大事、思いました。
Re:何がだめかじゃなくて (スコア:1)
「～すると失敗しました」じゃあダメですよね。
「～という条件では○○が成立しないことを確認しました」という論文じゃないとね。
ダメなものを批判していい気持ち (スコア:0)
昔、
Cプログラミング診断室
http://www.amazon.co.jp/dp/4774117870/ [amazon.co.jp]
というのを読むといいと勧められて読んだのですが、なんか作者の意地の悪さというか、批判の
しかたがいやーな感じでどうも評価できませんでした。
ダメなコードがなぜ生まれるのか、もっと体系的にまとめているのかと思っていたんだけど、
例もバラバラというか、酷いコードを見せては罵るみたいなパターンで。
別宮某の誤訳指摘本と同じで、こういうのって作者と一緒になって自分が上の立場から
悪口をいう快感を味合わさせるものになりがちな気がします。
Re:ダメなものを批判していい気持ち (スコア:2)
> なぜあの時代、「C言語はプログラマの基礎教養」「C言語ができずんばプログラマに非ず」「できなくても履歴書にC言語って書いておけ」みたいな風潮があったんでしょうねぇ。
いまさら、そんな話をされても……
当時のハードウェアで実用的なプログラムを書くことができ、生産性、移植性が高かったからですよ。
DOSマシンでも、8ビットマイコンでも、Unix WSでも使える言語、コンパイラが安く導入できる言語が他にありませんでしたから。
> 今の時代になっては、「アセンブラができずんばプログラマに非ず」なんて吹かしている人間は、流石に見かけないはず…と思いたい。
x86のシステムプログラムが書けるかという意味なら同意するけど、Z-80とか、8086でセグメントを越えないプログラムくらいは書けて欲しい。それらを事前に知らなくても、ポンとマニュアルを渡されたら、書ける程度の知識、能力。
人をプログラマと紹介されたら、その程度は前提にするのでは。
Re:ダメなものを批判していい気持ち (スコア:2)
なにせ試験問題に命令表が付属してくる。
解答付きの問題なんてそうそうあるもんじゃない。面白かった。
Re:ダメなものを批判していい気持ち (スコア:1)
言語はあんまり関係ないと思うなあ。
ifのような条件文がある言語なら、巨大なswitch文と同等なことを書けるので、手続き型言語ならほとんど同じことでは。Lispでも書きにくいけど書ける。
でも、学習・教育の問題とは思う。多くの場合、教育の段階で文法を教えるだけだから、課題を分析することなく、そのまま手続きにしてしまい、巨大なswitchのようなものができてしまう。
課題を分析するためには、既存のコンピュータの基本的な設計(CPUやメモリ、アドレスなど)と、それから導き出される効率的な各種アルゴリズム、たとえば配列の使い方（バイナリサーチやクイックサーチ、ハッシュなど)を教える必要がある。
けれども、それらがバラバラに教えられることがほとんどでしょう。コンピュータ系の学科でも、プログラミングの授業とアルゴリズムの授業が別々だったりする。それでは、フツーの学生や生徒には身につかない。
そうするとオンジョブトレーニングか、自己努力に依存するから、プログラマのレベルがバラバラで、製品の品質や生産性が上がらない。
Re:ダメなものを批判していい気持ち (スコア:2)
わたしの文章が悪かったのなら謝罪するが、Cが教育用として最適だなんて書いた覚えはない。ただ、手続き型言語なんか、所詮は同じ穴の狢で、本質的には大差ないという趣旨。
bool型の代わりにint型を使っても、何か大きな問題があるとは思えないし、文字列も最初は大きめの配列で扱えば良い。いちいちmalloc()とかする必要はない。
文字列処理が重要なら、何なら、BASIC風文字列関数をライブラリとして用意してやれば良いし、この際、PerlかRubに乗り換えても良い。
型があることがプログラミングを楽にするとの考えもあるが、schemeなどのように事実上、型をなくした言語もある。たとえば変数に関数を代入すれば、その変数が関数になる。Cで常にキャストを意識するとか、ポインタのポインタを扱うとか、そんなことを考えると、型はない方が楽。
Re:ダメなものを批判していい気持ち (スコア:1)
一種の方言？わわって
Copyright (c) 2001-2014 Parsley, All rights reserved.
Re:ダメなものを批判していい気持ち (スコア:1)
うちの方が方言だったんですね。味あう。
Copyright (c) 2001-2014 Parsley, All rights reserved.
これもお勧め (スコア:0)
別に (スコア:0)
関数の最後が『return 0;』でも、正常なら最後まで通るコードなら問題ないと思うけど。
謎の連番で命名されたクラス名/メンバ変数名でも、命名の取り決めがちゃんとあれば問題ないと思うけど。
Re:別に (スコア:2)
＞ 判断条件が128個あるなら128個のcaseが並ぶswitch文は問題ないと思うけど
C/C++だと，分岐が128個もあるような大きなswitch 文は
関数テーブルつかって書きなおす方が保守しやすくなる，
ってよく言われてます．
すくなくとも私は 128個もcaseが並んでいたら，その時点でそのコードを読む気力が無くなります．
これ全パターンデバッグできてるの？break とか抜けたりしてないの？等，いちいちチェックしたくないので．
Re:別に (スコア:2)
> C/C++だと，分岐が128個もあるような大きなswitch 文は
> 関数テーブルつかって書きなおす方が保守しやすくなる，
> ってよく言われてます．
関数テーブルを使うと甚だしい性能劣化を
招くこともある。(勿論、そうでない場合もある)
break の抜けをチェックしてでも性能をあげなきゃ
いけない状況も往々にしてある。
ケースバイケースだよ。 # これを言いたかった。
それから全パターンデバッグについては
関数テーブルを使う場合でも試験するのが当然。
Re: (スコア:0)
イベントループはcaseがたくさん並んでいるもんだよね。
Re:別に (スコア:1, すばらしい洞察)
isalphaの中身がそうならざるおえないコード体系だって有るし。
だから、部分を抜き出して馬鹿とか言うのは文系。
文系って文脈読めないんだよね。
Re:別に (スコア:1, すばらしい洞察)
そうならざるおえない
文系を馬鹿にする前に、もうちょっと文系の勉強をした方がいいかもね。
Re:別に(物の見事に捕まえてくれて有難う) (スコア:1)
いいえ、これは再帰です。
Re:別に(物の見事に捕まえてくれて有難う) (スコア:1)
return 0;
Re: (スコア:0)
#2211895に同意なんだけど、あっちで良い悪いを議論するのにtwitterのアカウントがないと駄目とかｗ
他人を揶揄したいだけ揶揄して自己満足したいだけのサイトに見えちゃうのがもにょりだねぇ
Re:自己言及 (スコア:2)
IF B = C THEN
A = TRUE
ELSE
A = FALSE
END IF
↑
こういうコードを書くやつって
実際の業務のコードを書いた時にIF文の羅列が続いて
こんなコードも中に混ざっていて紛らわしいクソコード書くんだよね。
↓
IF E F THEN
D = TRUE
ELSE
D = FALSE
END IF
IF H = I THEN
G = FALSE
ELSE
G = TRUE
END IF
どちらにしてもVB自体糞仕様。
Re:自己言及 (スコア:2)
A=B=C
最初の=は代入で、2番目のは比較演算子。
かっこ付けた方が分かりやすいかなぁ
A=(B=C)
Re:自己言及 (スコア:2)
> VBは比較の結果を代入できたり
VBに限らず。他の多くの言語でできます
> 最初の=は代入で、2番目のは比較演算子。
大丈夫。わかってるよ＾＾;
Re:自己言及 (スコア:2)
Cだと単なる代入になっちゃいますから一応説明しといたよ。
Re:自己言及 (スコア:2)
#2211997のスレッドが既にあるし説明不要。
ってか俺の元コメ(#2212267)が言いたいことと全然関係ないし。
さてはキミは(#2212267)で書いたクソコード書くタイプ？（と勘ぐってしまうゾ）
Re:自己言及 (スコア:1)
一番左の=が特別なだけでCライクなら A = ( B == C ) ですよ。
更に言えば、変数にNullを代入可能な場合が有り、BかCがどちらか一つがNullならAはNullです。
その為、親コメントの判定条件ではAがNullとなるべきケースが漏れた適切でないコードですのでご注意を。
Re:表に出せるから笑えるんだよ (スコア:3)
人生は七転び八起き、一日は早寝早起き
Re:えー今まさに (スコア:1)
なるほど。Strutsをdisってるんですね。
Re:うは (スコア:1)
run
10 Syntax error
OK
Re:バグなのになぜか動く (スコア:2)
Re:コレジャナイ感 (スコア:2)
同感です。
他人の失敗を他山の石として、自分を省みる材料とするよりも
初心者やセンスの無い人を、あざ笑うことを目的としているようで
見ていて気分の悪いサイトだと思いました。
そもそも、ウンコマークは品が無さ過ぎる。小学生かとｗ
同感 (スコア:1)
単に残念なコードもあれば、頭が柔らかすぎる常識外れなコードや、鼻から悪魔が出るコードもあったりで、
こういうのを一緒くたに「ウンコ」評価しかできないのが残念すぎる。
どれだけウンコなのかじゃなくどうウンコなのかを評価すれば、ウンコからも新たな知見が得られるはずなのに…