makeplexによる
2009年11月05日 17時04分の掲載
逆に“キレイなコード”といったら何だろう部門より。
逆に“キレイなコード”といったら何だろう部門より。
あるAnonymous Coward 曰く、
yebo blog経由で知ったのだが、オープンソース開発者のMarco Peereboom氏が、「OpenSSL is written by monkeys!」(OpenSSLはサルによって書かれている)とOpenSSLのソースコードの汚さを批判している。
ここでは実際にOpenSSL内で使われている「酷いコードの例」を挙げつつ、「コードの汚さにキレる」Peereboom氏の姿が書かれている。そしてPeereboom氏は最終的にAgglomerated SSL(ASSL)という代替APIを作成するまでに至ったとのこと。
開発者なら一度は「他人の書いた汚いコード」にキレた経験はあると思うのだが、それを燃料に代替コードを書いてしまうとはさすがである。
# ということで、コメントでは/.J読者の方々が読んだことのある「他人の書いた汚いコード」をぜひお披露目下さいwww
関連ストーリー
あなたの「コード読解力」はどれくらい? 71 コメント
頓挫したプロジェクトのコードはどこにいく? 43 コメント
Firehose:OpenSSLのコードの汚さに「サルが書いたコードだ」との批判 by Anonymous Coward
コメントはソースコードを表す? 161 コメント
行数とか見た目の問題ならまだマシ (スコア: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:行数とか見た目の問題ならまだマシ (スコア:2)
>> #define ZERO 1
>すごいな…どうしてそうなったのか、それとも罠なのか。
構造体のことをわかっていない奴が
struct hoge { int n_valid_size; int data[10];}
みたいなことをしたいのに
int data[11]
という風に書いて、data の実体を参照するのに
data[ZERO + int_valiable]
なぞとしたんではないかと思われ
コメントを書く
親コメント
Re:行数とか見た目の問題ならまだマシ (スコア:2)
Perlで大規模でキレイなコードを書くのが間違ってると思う。そういう言語として設計されていないから。
つまり、Perlは4.*までは短く仕事を終わらす目的だったけど、5.*以降の拡張は設計思想が変わってしまって、矛盾をはらんでいる。
myは5.*からでしょ。4.*にはなかったと思う。localはあったけど。
コメントを書く
親コメント
残念ながら (スコア:3, おもしろおかしい)
コメントを書く
ソース見てないけど (スコア: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]という意味もありますね。
「一見すると一つの塊に見えるけど、中身は細かいバラバラの破片が火山灰や溶岩(グルーコード?)で
繋がってるだけで、少し力を加えただけで元のバラバラの状態に砕けてしまうほど脆い物だ。」
とか言いたかったのかも。
コメントを書く
親コメント
むしろ (スコア:2, すばらしい洞察)
昨晩自分が書いたコードにキレることも
スパゲティな上にコメントも無いコードを見て誰だよコレと思ったら昨日の自分だったとか···
コメントを書く
きれいなコードは3倍大変 (スコア:2, すばらしい洞察)
- 再利用可能なソフトウェアを開発するには、3回は作り直す必要がある
- 再利用の恩恵を与えるには、少なくとも3回は再利用する必要がある
成果物をパパッと作っちゃう人は再利用のことなんか考えません。
後で作り直せば良いだけなんだから。
それでサルが書いたみたいに汚いコードだとか愚痴ってる奴が3倍の労力をかけてきれいなコードに書き直せば良いだけのことですよ。
コメントを書く
「後は野となれ山となれ」メソッド (スコア:5, すばらしい洞察)
まず第一に、綺麗なコードと再利用できるコードを混同している。
再利用できるコードを作るのは再利用できないコードの3倍苦労するけど、
汚いコードを再利用するのは30倍以上苦労します。
>成果物をパパッと作っちゃう人は再利用のことなんか考えません。
>後で作り直せば良いだけなんだから。
いやいや。そういうことを言い訳にして汚いコードを書く人は、あとの事なんて
考えてない。自分で書き直せない奴ほど、そういうことを言い訳に使うんですよね。
#綺麗なコードを書く時間 ー 汚いコードを書く時間 << 汚いコードを解読して綺麗なコードに書き直す時間
どうせ書き直す必要が出る頃までその会社にいるかどうか分からないんだし、そも
そも次の仕事を同じ会社が受ける保証もなければ、その会社が次の仕事を受ける時
まで存続している保証もない。万が一書き直す必要が発生しても、汚いコードを
書く人はさっさと逃げ出しちゃえばいいんですよね。
それにしても再利用可能なコードを創るのが大変なのは事実だけど、「自分の書いた
コードを書き直すのは嫌いだ」とか言って保守不可能なコードを書いて技術的負債を
増やし続けるような奴を雇っちゃいけないな。
コメントを書く
親コメント
Re:きれいなコードは3倍大変 (スコア:3, すばらしい洞察)
なるほど。
3つの法則といいながら、2つしかないとは素晴らしい。
コメントを書く
親コメント
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回は再利用する必要がある」というものだ。」
となっています。
なお「人月の神話」にも作り直しに関する記述があって、「一つ目は捨て石にしなければならない」
「二番目のシステムは危険だ」みたいな話が書かれています。
コメントを書く
親コメント
こうですね、わかります。 (スコア:2)
猿コードは追わず、ただ作り直すのみ。
コメントを書く
進化に取り残された人が書いたコード (スコア:2, 興味深い)
当初開発を行った担当者が残した仕様書に目を通したところ、HTTP送受信、複数のタスクの協調動作、状態遷移等全てのものがタイミングチャートで書かれていました。
またソースコードには0or1の値しか代入されないフラグが数十個定義され、これで状態遷移が全て管理されていました。
新しい機能に対応するため、コードを書き足してフラグの値を変更すると予想もしない動作ばかり...
恐らく開発した人はクロックとフラグで全て解決できる環境でこれまで仕事されてきたのでしょうね。
この時ばかりは「老害」という言葉の必要性を痛感しました。
結局その後、仕様書とソース両方全部作り直して納品しましたとさ。
コメントを書く
ひねりなし (スコア:1)
main()が8000行
switch文が6階層...
コメントを書く
全てのPerlのコード (スコア:1, すばらしい洞察)
T/O
# 夜道で撃たれたくないので、AC
コメントを書く
Re:全てのPerlのコード (スコア:2, おもしろおかしい)
Perlは難解ですね。
昔、メールで送ってもらったソースを解読してたんですが、やっと解読できたと思ったら文字化けしたメールだったよ。
なんで本文に貼り付けて送ってくるのだろうと不思議だったんですが、道理で...
コメントを書く
親コメント
Web開発でも最長不倒が (スコア:1)
strutsのlogicタグ使いすぎによる最長不倒関数 [kojima-cci.or.jp]を見たことがあります。
簡略化して書くと
という具合に、logicタグを大量に使ってifとループが延々と続くようなものでした。
5層くらいのifが入り乱れてるところにループがちりばめられているのです。
C/Javaのエディターだとifやループの括弧に対する対応位置を自動的に検知してくれたりするので
ある程度長くても調べやすかったけれど、JSPにはまだそういうのが無くて
このファイルの修正作業にはブチ切れそうになりました。
昔、Cで最長不倒関数作ってたような人が、今はWeb開発に回されてるんでしょうねえ..。
コメントを書く
他人が書いたもの限定かぁ (スコア:1)
C++ で見たものといえばこんな辺りでしょうか。
……なんてのは、見たことがありますね。switch にできる単一変数評価で。
switch でもブチキレそうですが。
後はこんなのとかも。
いずれも自称 C++ マスターさんの書かれたコードでしたが、何をどんな風にマスターしたのやら……。
コメントを書く
頼むからgoto使ってくれ (スコア:1)
if (p1 == NULL) {
return;
}
p2 = malloc();
if (p2 == NULL) {
free(p1);
return;
}
p3 = malloc();
if (p3 == NULL) {
free(p1);
free(p2);
return;
}
//以下、同じ感じで続いていく。
コメントを書く
なんとなく解ったw (スコア:1)
なんでワシみたいな運用と人付き合いしかできない人間の仕事が無くならないかが解ったw
プログラムは全然門外漢なんだが後始末はしょっちゅうさせられる。
お願いだからソースにコメントくらいは残してくだたたい。゚(゚´Д`゚)゚。
コメントを書く
キレイなコードを書くと (スコア:0)
キレイな結晶ができるんですね。
コメントを書く
Re:キレイなコードを書くと (スコア:5, おもしろおかしい)
コメントを書く
親コメント
Re:キレイなコードを書くと (スコア:3, おもしろおかしい)
あぁ、もっとキツくコードレビューしてっっ!! というやつですね。
コメントを書く
親コメント
難読化ですね (スコア:0)
コメントを書く
「サルでもできる○○本」 (スコア:0)
コメントを書く
Re:「サルでもできる○○本」 (スコア:2)
「猫でもわかるC言語プログラミング」 [amazon.co.jp]ではなくて?
つまり「猫の手も借りたい」と言いたいのだろうか。
しかし現実には猫以下の人の方が多い気がする。
猿プログラマは足をひっぱってくれるけど、猫は何もしない代わりに心を癒してくれる。
コメントを書く
親コメント
関数を知らなかったのか (スコア:0)
main()千行程度でwhileとgo toでプログラム作ってたのなら。
ここまでくるとむしろ若干感動した。
コメントを書く
きれいなジャイアン (スコア:0)
………いや、言ってみただけ。
汚い可読性の悪いけどバグなしのコードと可読性は高いけどバグありのコードのどちらがいいコードなんだ?
スパゲッティ大好きなのでAC
コメントを書く
ビット演算を大小比較で (スコア:0)
自分が書き直したら、数十行が1行(70文字程度だったかな)に。
おまえら、学校で何習ってきたんだとコ一時間w
#ビット演算子(の存在)を忘れていた(知らなかった)らしい
コメントを書く
Re:ビット演算を大小比較で (スコア:2, 参考になる)
いや、このコメントを投稿するときに HTML OK にしていたので < が抜けてしまっただけなんだと思う。
> if( 0 <= bit && bit <= 15 || 32 <= bit && bit <= 48 || ... )
ということですよね。
コメントを書く
親コメント
本物のプログラマはあらいぐまラスカルを見ない (スコア:0)
そういう世界で出てくる本物のプログラマだとその程度の事でどうこう言わないような気もするんですが、本物のプログラマのみなさんはどうなんでしょうか?
# ラスカルの最終回は泣けるので AC
コメントを書く
Re:本物のプログラマはあらいぐまラスカルを見ない (スコア:3, 参考になる)
ラスカルを返した森には最初から野生のアライグマが生息しているので、日本と
一緒にするのはどうかと。
あと、最終回でスターリングがラスカルを森に返すのは、父親の元を離れて遠くの
学校に行く事を決断したからであり、また成長したラスカルは森に返した方が良いと
考えたからです。
いたずらに手を焼いて森に返そうとするのは序盤のエピソードです。
コメントを書く
親コメント
インデントぐちゃぐちゃの術 (スコア:0)
タブでインデントするのやめろよ!
どうせコード階層以外のとこでタブ使ってめちゃくちゃになるんだ!
コメントを書く
VBだけど (スコア:0)
一度しか通らない道だから実行結果に問題はないんだけど、
コードの途中に突然変数の宣言が現れてその変数を一時的に使ってたりとかなら・・・。
あとプロシージャの中でGotoとGosubとか日常的に使いまくりだったりとか・・・。
でもちゃんと動くからいいじゃない。
人に見せるわけでもないしいいよね。
どうせ見るのは自分だし・・・。
的な思いからそのままになってます。
コメントを書く
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 である必要があることに気づくので、
変数の型が妥当かに気づく機会も与えています。
・・・オレは釣られたのか?
コメントを書く
親コメント
おお、そうか! (スコア:0)
# ↑あまり事情がわかってない半可通。
コメントを書く
GOTO禁止 (スコア:0)
だからといって、do - whileで囲んで、
breakでループ外に飛ばすような小技を使わなくても…。
#最初1分ぐらい、何がしたいのかわからなかった
コメントを書く
運用でカバーした形跡 (スコア:0)
きっと暫定的な対応だったような気配はしますが、何年放置するんだろう。
コメントを書く
半年バイトしてきた中で最悪のコード (スコア:0)
Javaの携帯アプリなんですが、
・クラスがエントリポイントを含むクラスとMainCanvasクラスのみ
・MainCanvasクラス一つのコードで一万三千行
・一つのメソッドで二千行
・フィールドの数は500個以上
・enum型代わりにstatic finalが宣言されているにもかかわらず数字直書き
・ほぼ同じコードが100回コピペされて並んでる
・フィールド/メソッド名が頭文字で短縮されており何の略なのかさっぱり
・数回の改造を経ているらしく命名法が三種類
・フィールドの使い方を途中から変えたらしく、命名法の役割とかけ離れている
・コメントはほぼ皆無。たまにあるコメントは日本語/英語/中国語の三種類で書かれる
・Javaなのに外部ツールで#define, #ifdefなどを使用している
などです。正直書き始めたらきりがありません。
# なにより怖いのは、これが目下移植中のコードだということ・・・
コメントを書く
猿が無限じゃなかったのが問題 (スコア:0)
工期の問題と猿不足で、現在のコードになっております。
ちなみに現在のコードは猿(ID:ba6d843eb4251a4526ce65d1807a9309)の生成したものとなっております。
コメントを書く
プログラマーは下級な職業 (スコア:0)
曰く「プログラムなんて俺でも書ける」
曰く「プログラムなんて誰が書いても一緒」
曰く「プログラムの技術を勉強するのはオナニー」
ソースコードなんてきれいに書くだけ無駄ですよ。
期日までにそれなりに動けばそれでOK。それが現実です。
コメントを書く
無修正なソースコード満載! (スコア:5, おもしろおかしい)
> 曰く「プログラムの技術を勉強するのはオナニー」
それで技術書読むのがこんなに楽しかった訳か。納得いきました。
コメントを書く
親コメント
Re:世の中には命知らずが多すぎるよ (スコア:2)
> ブレーキの付いてない自転車で、ずっと続く長い坂道を降りていくような感じかな。
競輪のゴール前バンクの下りですね。
コメントを書く
親コメント
引き継いだコード (スコア:0)
-関数の中でしか使わないのに外でmalloc
-7個使ってるのに6個しか確保してなくてメモリオーバーフロー
そんなの満載のコード半年デバッグ保守やらされて死にたくなった。
コメントを書く
空白は変だけど、変じゃない部分も (スコア:0)
偏執的に一行ごとにエラーチェックと例外脱出が必要なケースで
#define ERROR_OUT(e, g) do { push_error(__FILE__, __FUNCTION__, __LINE__, e); goto g; } while(0)
とかするのは別におかしくないと思うんだけどな。
自分だったら関数そのものをラップする形にして
#define TRY(expr, tag) do { int rc; if ((rc = (expr)) != OK) { push_error(..., rc); goto tag; } while (0)
として
TRY((do_something()), fatal);
TRY((do_something_else()), fatal);
return OK;
fatal:
task_abort();
とかまとめてしまうかも。
コメントを書く
MISRA-C (スコア:0)
コメントを書く
サルを馬鹿にするな (スコア:0)
サルを馬鹿にしすぎです。
某都知事の四男で、余人をもってかえがたいと評価される天才画家並みの
絵をサル(チンパンジー)は描きますよ。
コメントを書く
変更履歴 (スコア:0)
// 2009.11.1 modify start
#if 0
int a;
a = 0;
#endif
int a = 0;
// 2009.11.6 modify start
//int a = 1;
long a = 1;
// 2009.11.6 modify end
// 2009.11.1 modify end
みたいな変更履歴が7割を占めるコードがありました。
こんなのがコーディング基準で決まってるんですよね。
結構あちこちで採用されてたみたいなんですけど、はっきり言って読めたもんじゃない。
全文コメントアウトして、下に履歴削除したコードを書き直したのでAC :-P
コメントを書く
一方おれは (スコア:0)
コメントを書く
いつものことですが (スコア:0)
客先に常駐すると・・・
main()
{
funcA();
funcB();
funcC();
}
int funcA()
{
/* TBD */
}
int funcB()
{
/* TBD */
}
int funcC()
{
/* TBD */
}
しかも戻り無し。
コメントを書く
変だな (スコア:0)
絶対「OpenSSLが書けるサルなら我が社は大歓迎だ!そのサルを連れてきてくれ!」があると思ったのに。
コメントを書く