OpenSSLのコードの汚さに「サルが書いたコードだ」との批判 185
ストーリー by makeplex
逆に“キレイなコード”といったら何だろう 部門より
逆に“キレイなコード”といったら何だろう 部門より
あるAnonymous Coward 曰く、
yebo blog経由で知ったのだが、オープンソース開発者のMarco Peereboom氏が、「OpenSSL is written by monkeys!」(OpenSSLはサルによって書かれている)とOpenSSLのソースコードの汚さを批判している。
ここでは実際にOpenSSL内で使われている「酷いコードの例」を挙げつつ、「コードの汚さにキレる」Peereboom氏の姿が書かれている。そしてPeereboom氏は最終的にAgglomerated SSL(ASSL)という代替APIを作成するまでに至ったとのこと。
開発者なら一度は「他人の書いた汚いコード」にキレた経験はあると思うのだが、それを燃料に代替コードを書いてしまうとはさすがである。
# ということで、コメントでは/.J読者の方々が読んだことのある「他人の書いた汚いコード」をぜひお披露目下さいwww
行数とか見た目の問題ならまだマシ (スコア:5, おもしろおかしい)
#define ZERO 1
一発の破壊力でこれに勝るコードを見たことが無い。
Re:行数とか見た目の問題ならまだマシ (スコア:4, おもしろおかしい)
昔、マジックナンバー埋め込むなって言ったら
#define ICHI 1
#define NI 2
#define SAN 3
:
:
for (i = 0; i SAN; i++) {
}
って書いた奴が居た。
その後、変更入って
//#define SAN 3
#define SAN 4
になったんだが同じ人?
Re:行数とか見た目の問題ならまだマシ (スコア:2, おもしろおかしい)
いえ、次の人です。前任者はSAN 0 となり発狂しました。
Re:行数とか見た目の問題ならまだマシ (スコア:2, 参考になる)
GNU libintlライブラリのgettextP.h [google.co.jp]にあるね、"#define ZERO 1"。
Re:行数とか見た目の問題ならまだマシ (スコア:1, おもしろおかしい)
を見た事がある。(きちんと意味のある数値に使っていた。)
サルが書いたコードと報告したら、
先輩に "サルが聞いたら気を悪くするな。" と言われ、納得した。
Re:行数とか見た目の問題ならまだマシ (スコア:2)
>> #define ZERO 1
>すごいな…どうしてそうなったのか、それとも罠なのか。
構造体のことをわかっていない奴が
struct hoge { int n_valid_size; int data[10];}
みたいなことをしたいのに
int data[11]
という風に書いて、data の実体を参照するのに
data[ZERO + int_valiable]
なぞとしたんではないかと思われ
Re:行数とか見た目の問題ならまだマシ (スコア:1)
>> #define ZERO 1
> すごいな…どうしてそうなったのか、それとも罠なのか。
ZERO-ONEファンの仕業だと推測。
Re:行数とか見た目の問題ならまだマシ (スコア:1)
「じゃあ local って書けよ」って返してあげればいいかと。
# my 付けなくても問題ないコードなら local でも大丈夫じゃないの? :)
Re:行数とか見た目の問題ならまだマシ (スコア:2)
Perlで大規模でキレイなコードを書くのが間違ってると思う。そういう言語として設計されていないから。
つまり、Perlは4.*までは短く仕事を終わらす目的だったけど、5.*以降の拡張は設計思想が変わってしまって、矛盾をはらんでいる。
myは5.*からでしょ。4.*にはなかったと思う。localはあったけど。
Re:行数とか見た目の問題ならまだマシ (スコア:1)
> #こういう書き方できたっけ??? breakの所はreturnでもいいかも。
break のとこ return にしたら動作がまったく変わっちゃわない?
continue にするなら大丈夫そうだけど。
残念ながら (スコア:3, おもしろおかしい)
Re:残念ながら (スコア:1)
ソース見てないけど (スコア:2, 参考になる)
ag·glom·er·ate [əglάmərèit]
-n. [-rət, -rèit] 塊り, 《まとまりのない》 集団, 群
(研究社リーダーズプラス)
…きれいなコードになってるのかな?
Re:ソース見てないけど (スコア:2, 参考になる)
>ag·glom·er·ate [əglάmərèit]
「集塊岩」(しゅうかいがん) [hirahaku.jp]という意味もありますね。
「一見すると一つの塊に見えるけど、中身は細かいバラバラの破片が火山灰や溶岩(グルーコード?)で
繋がってるだけで、少し力を加えただけで元のバラバラの状態に砕けてしまうほど脆い物だ。」
とか言いたかったのかも。
あんまり自信ないけど (スコア:1)
ともかく、"a"で始まる皮肉を感じさせる言葉だったら、
何でも良かったんじゃないかな?
むしろ (スコア:2, すばらしい洞察)
昨晩自分が書いたコードにキレることも
スパゲティな上にコメントも無いコードを見て誰だよコレと思ったら昨日の自分だったとか···
きれいなコードは3倍大変 (スコア:2, すばらしい洞察)
- 再利用可能なソフトウェアを開発するには、3回は作り直す必要がある
- 再利用の恩恵を与えるには、少なくとも3回は再利用する必要がある
成果物をパパッと作っちゃう人は再利用のことなんか考えません。
後で作り直せば良いだけなんだから。
それでサルが書いたみたいに汚いコードだとか愚痴ってる奴が3倍の労力をかけてきれいなコードに書き直せば良いだけのことですよ。
「後は野となれ山となれ」メソッド (スコア:5, すばらしい洞察)
まず第一に、綺麗なコードと再利用できるコードを混同している。
再利用できるコードを作るのは再利用できないコードの3倍苦労するけど、
汚いコードを再利用するのは30倍以上苦労します。
>成果物をパパッと作っちゃう人は再利用のことなんか考えません。
>後で作り直せば良いだけなんだから。
いやいや。そういうことを言い訳にして汚いコードを書く人は、あとの事なんて
考えてない。自分で書き直せない奴ほど、そういうことを言い訳に使うんですよね。
#綺麗なコードを書く時間 ー 汚いコードを書く時間 << 汚いコードを解読して綺麗なコードに書き直す時間
どうせ書き直す必要が出る頃までその会社にいるかどうか分からないんだし、そも
そも次の仕事を同じ会社が受ける保証もなければ、その会社が次の仕事を受ける時
まで存続している保証もない。万が一書き直す必要が発生しても、汚いコードを
書く人はさっさと逃げ出しちゃえばいいんですよね。
それにしても再利用可能なコードを創るのが大変なのは事実だけど、「自分の書いた
コードを書き直すのは嫌いだ」とか言って保守不可能なコードを書いて技術的負債を
増やし続けるような奴を雇っちゃいけないな。
Re:きれいなコードは3倍大変 (スコア:3, すばらしい洞察)
なるほど。
3つの法則といいながら、2つしかないとは素晴らしい。
Re:きれいなコードは3倍大変 (スコア:1)
世の中には3種類の人間が居る。
数を数えられる人間と、数えられない人間だ。
Re:きれいなコードは3倍大変 (スコア:4, 参考になる)
「ソフトウエア開発 55の真実と10のウソ」 [amazon.co.jp]では以下のように書かれています。
「真実18
再利用には二つの「3の法則」がある。
(a) 再利用可能なコンポーネントを作るのは、単一のプログラムで使うモジュールを開発する場合に比べ3倍難しい。
(b)再利用可能なコンポーネントは、ライブラリに取り込む前に、三つの異なるプログラムでテストする必要がある。」
「「3の法則」は「ビガスタフの3の法則」として知られている」
と書いているので、この二つの「3の法則」がビガスタフの法則であるのは間違いないようです。ただし
検索を駆使しても原著論文は見つからなかったとも書いています。また3はあくまで目安でしかない
ことにも触れられています。ならば、下手糞なプログラマでは10回作り直したところで、再利用可能な
コードに到達することなど叶わないでしょう。
また、ぐぐってみると、
http://itpro.nikkeibp.co.jp/free/ITPro/OPINION/20030918/1/ [nikkeibp.co.jp] では
「「ソフトウェア再利用の神話」(ウィル・トレイツ著,ピアソン・エデュケーション)
という本に,再利用に関する「3」の法則が出てくる。すなわち,「再利用可能なソフトを
開発するには,3回は作り直す必要がある」,「再利用の恩恵にあずかるには,少なくとも
3回は再利用する必要がある」というものだ。」
となっています。
なお「人月の神話」にも作り直しに関する記述があって、「一つ目は捨て石にしなければならない」
「二番目のシステムは危険だ」みたいな話が書かれています。
Re:きれいなコードは3倍大変 (スコア:1)
きれいなコードは時間がかかるというけど本当なの?
大昔ならいざしらず、現在は綺麗な設計/コードを作るためのノウハウがたくさん発表されていますよ。
頭をひねって時間をかけて考え出す必要はもうほとんどないです。要はテクニックです。
それらのノウハウを知っていて適切に適用できれば今までと同じ時間で今までより綺麗なコードが書けますよ。
こうですね、わかります。 (スコア:2)
猿コードは追わず、ただ作り直すのみ。
Re:こうですね、わかります。 (スコア:1)
「既に『完成した』(=辛うじて動くだけ)コードが存在するのだから、可能な限りそれを再利用しろ。」
と命令してくれる猿上司がいると、それは不可能になります。
進化に取り残された人が書いたコード (スコア:2, 興味深い)
当初開発を行った担当者が残した仕様書に目を通したところ、HTTP送受信、複数のタスクの協調動作、状態遷移等全てのものがタイミングチャートで書かれていました。
またソースコードには0or1の値しか代入されないフラグが数十個定義され、これで状態遷移が全て管理されていました。
新しい機能に対応するため、コードを書き足してフラグの値を変更すると予想もしない動作ばかり...
恐らく開発した人はクロックとフラグで全て解決できる環境でこれまで仕事されてきたのでしょうね。
この時ばかりは「老害」という言葉の必要性を痛感しました。
結局その後、仕様書とソース両方全部作り直して納品しましたとさ。
ひねりなし (スコア:1)
main()が8000行
switch文が6階層...
全てのPerlのコード (スコア:1, すばらしい洞察)
T/O
# 夜道で撃たれたくないので、AC
Re:全てのPerlのコード (スコア:2, おもしろおかしい)
Perlは難解ですね。
昔、メールで送ってもらったソースを解読してたんですが、やっと解読できたと思ったら文字化けしたメールだったよ。
なんで本文に貼り付けて送ってくるのだろうと不思議だったんですが、道理で...
Re:全てのPerlのコード (スコア:1)
Web開発でも最長不倒が (スコア:1)
strutsのlogicタグ使いすぎによる最長不倒関数 [kojima-cci.or.jp]を見たことがあります。
簡略化して書くと
という具合に、logicタグを大量に使ってifとループが延々と続くようなものでした。
5層くらいのifが入り乱れてるところにループがちりばめられているのです。
C/Javaのエディターだとifやループの括弧に対する対応位置を自動的に検知してくれたりするので
ある程度長くても調べやすかったけれど、JSPにはまだそういうのが無くて
このファイルの修正作業にはブチ切れそうになりました。
昔、Cで最長不倒関数作ってたような人が、今はWeb開発に回されてるんでしょうねえ..。
他人が書いたもの限定かぁ (スコア:1)
C++ で見たものといえばこんな辺りでしょうか。
……なんてのは、見たことがありますね。switch にできる単一変数評価で。
switch でもブチキレそうですが。
後はこんなのとかも。
いずれも自称 C++ マスターさんの書かれたコードでしたが、何をどんな風にマスターしたのやら……。
Re:キレイなコードを書くと (スコア:5, おもしろおかしい)
Re:キレイなコードを書くと (スコア:3, おもしろおかしい)
あぁ、もっとキツくコードレビューしてっっ!! というやつですね。
Re:キレイなコードを書くと (スコア:1, おもしろおかしい)
女プログラマがっRe:きれいなジャイアン (スコア:1, すばらしい洞察)
そんなものは存在しないか、「汚い可読性の悪くてバグはあるけどまだ見つかってないだけのコード」を誤認してるだけなので、どう考えても後者を選んどいた方がいい。
Re:きれいなジャイアン (スコア:1)
二度と触らないのであれば前者、そうでないなら後者。
Re:VBだけど (スコア:1)
コードの途中に突然変数の宣言が現れてその変数を一時的に使ってたりとかなら・・・。
え、これってダメなの?
使う場所の近くで宣言する方がいいって思ってるんですが。
Re:VBだけど (スコア:2, すばらしい洞察)
言語にもよるけど変数のスコープは小さければ小さいほどいい。javaで言えば
for(int i=1 ; i < MAX ; i++ ){
// ナニかの処理
}
みたいなのは推奨されてる。(この場合のループカウンタはfor文の中だけで有効)
ただ、たかだが50行~100行程度のメソッドで、スコープが得に小さくなるわけでも
ないのに宣言だけあちこちに乱立するくらいなら、メソッドの先頭にまとめちゃう
のも一つの手だとは思う。
これが50~100行程度のメソッドで、他の変数が全部先頭にまとめられているのに、
あとで書き足した初心者プログラマーが変数宣言を途中に追加したら、他の理由がない
限り先頭に入れるように書き直せと指示すると思う。
Re:VBだけど (スコア:2)
> for(int i=1 ; i < MAX ; i++ ){
これって
か
ではないですか?
変数のスコープをなるべく小さくするのは、初期化忘れの防止が1つの動機ですが
不適当な値での初期化に気づかせる効果もあります。
あと
であったら、i は int ではなく long である必要があることに気づくので、
変数の型が妥当かに気づく機会も与えています。
・・・オレは釣られたのか?
Re:VBだけど (スコア:1)
VB使いのレベルのひどさが垣間見られるね。
ちょっと待て、COBOLerなんだが...
と言うのは置いといて、Cなどでは普通だと思うけどVBだと問題なのかな?
Re:VBだけど (スコア:1)
JavaScriptは、暗黙の参照渡しなど、Cに慣れた人には罠が多いですよね。
Re:「サルでもできる○○本」 (スコア:2)
「猫でもわかるC言語プログラミング」 [amazon.co.jp]ではなくて?
つまり「猫の手も借りたい」と言いたいのだろうか。
しかし現実には猫以下の人の方が多い気がする。
猿プログラマは足をひっぱってくれるけど、猫は何もしない代わりに心を癒してくれる。
Re:本物のプログラマはあらいぐまラスカルを見ない (スコア:3, 参考になる)
ラスカルを返した森には最初から野生のアライグマが生息しているので、日本と
一緒にするのはどうかと。
あと、最終回でスターリングがラスカルを森に返すのは、父親の元を離れて遠くの
学校に行く事を決断したからであり、また成長したラスカルは森に返した方が良いと
考えたからです。
いたずらに手を焼いて森に返そうとするのは序盤のエピソードです。
Re:本物のプログラマはあらいぐまラスカルを見ない (スコア:1)
アライグマはそもそもどう猛な肉食動物なので、それを家で飼おうと考えること自体が無茶らしいぞ。
http://www.chikawatanabe.com/blog/2006/06/post_12.html [chikawatanabe.com]
身勝手は身勝手なんだが、それはライオンやニシキヘビの子供を可愛いと思って
飼い始めるようなものだと思う。自分の器を自覚して、その器を超える動物を飼い
慣らせるなんて思わないことですね。
Re:半年バイトしてきた中で最悪のコード (スコア:1, 参考になる)
まさに当初はそうだったと思う。10KBの壁は有名だったよね。
少しでもコンパクトにするために、
○変数名1文字、メソッド名1文字。しかも同じ名前を使うこと
○クラスもメソッドも一つのみ
○try-catchは一つ。もちろん catch( Exception e) 。
○switch-caseよりif文。
○定数は可能な限り小さい数値で。(iconst_1などの即値が使える。)
などなどの、涙ぐましい努力をしてコードを10kbに詰め込んでました。
読みにくくなったのは妥協の結果なのです。
時は流れ、コードサイズも100KBになり1MBになり、少しずつ大きくなっていきました。
当初10kbで作られたコードにも新しい機能が次々と足されていきました。
しかし元が10KBに詰め込まれたコードなので、追加されればされるほど可読性が低く、
追加機能は読みにくく、修整し難いものとなっていきましたとさ。
めでたしめでたし。
>・MainCanvasクラス一つのコードで一万三千行
>・一つのメソッドで二千行
この辺りは携帯Javaだとよく見られる光景ですね。
>・enum型代わりにstatic finalが宣言されているにもかかわらず数字直書き
>・ほぼ同じコードが100回コピペされて並んでる
この辺りは追加していく過程でツギハギが酷くなっていったのかな?
>・Javaなのに外部ツールで#define, #ifdefなどを使用している
「2キャリア対応機能を追加しろ。一つのコードを再利用した方が楽だろ?」
という上司でもいたのかなあ。マクロの乱用は恐いよ~~。
#下手すると2つのコードをメンテする方が楽だったりして………。
それにマクロを使うと、Eclipseのリファクタリング機能が使えなくなるんじゃね?
無修正なソースコード満載! (スコア:5, おもしろおかしい)
> 曰く「プログラムの技術を勉強するのはオナニー」
それで技術書読むのがこんなに楽しかった訳か。納得いきました。
Re:世の中には命知らずが多すぎるよ (スコア:2)
> ブレーキの付いてない自転車で、ずっと続く長い坂道を降りていくような感じかな。
競輪のゴール前バンクの下りですね。
Re:ビット演算を大小比較で (スコア:1)
それを commit したら、「わかりにくい」って怒られました。
if( !(bit & 0x00f0) ) と
if( 0 = bit && bit = 15 || 32 = bit && bit = 48 || ... ) って、どっちがわかりにくいかなぁ。
Re:ビット演算を大小比較で (スコア:1)
>> if( 0 = bit && bit = 15 || 32 = bit && bit = 48 || ... )
0 = bit とか 32 = bit とかってってコンパイルできないような気が…
それと, && と || をカッコ無しで並べて書くのは,たしかに「わかりにくい」と思います.
Re:ビット演算を大小比較で (スコア:2, 参考になる)
いや、このコメントを投稿するときに HTML OK にしていたので < が抜けてしまっただけなんだと思う。
> if( 0 <= bit && bit <= 15 || 32 <= bit && bit <= 48 || ... )
ということですよね。