おすすめのソースは? 122
ストーリー by GetSet
ブルドックのトンカツ用(マテ 部門より
ブルドックのトンカツ用(マテ 部門より
crypt曰く、"勉強、あるいは趣味として他人のソースコードを読む、ということで盛り上がりたいとおもいます。皆さんおすすめのソースコードを教えてください。わかりやすい良いコード、わかりにくいけど良いコード、こういうコード書いちゃいけませんみたいなコード、など。
楽しみ?な例としては難解Cプログラミングコンテストのこんなコードとか。(古い言語仕様なのでgccの場合は
みたいにコンパイルしてください)"gcc -E -traditional westley.c > westley2.c
gcc westley2.c
昔の自分のソースコード (スコア:5, すばらしい洞察)
人によっては一ヶ月ぐらい前でもいけるかも。
昔書いたソースコードは、今のあなたにとっては既に他人のソースコードです。
素晴らしい反面教師になってくれることでしょう。
Re:昔の自分のソースコード (スコア:5, おもしろおかしい)
「すげえ。俺ってこんな高度なコード書けてたんだ・・・・・・・・・orz」
と衝撃を受け自信を無くす展開に。
Re:昔の自分のソースコード (スコア:2, おもしろおかしい)
ダジャレのつもりだったら山田君に座布団全部取り上げてもらうからな。
Re:昔の自分のソースコード (スコア:1)
過去の自分の地道なコーディングに、
「面倒くさくて、読めねぇ」と思ってしまうことが
しばしば、有ったり、無かったり。
Re:昔の自分のソースコード (スコア:1)
>と衝撃を受け自信を無くす展開に。
(゚Д゚)∩同じ感想です!
自信無くすとともに、
「俺にはこんな力が眠っているんだ」
と前向きに捉えてみます orz
# こんな力は永眠されました
Re:昔の自分のソースコード (スコア:5, おもしろおかしい)
「お、いいコードだ。書いたやつは賢いな。」等とのたまっていたら、
cvsのコミット履歴から自分の名前が出てきて、
部下に白い目で見られてしまいました。
# もう書けないよ(ノД`)。:*
Re:昔の自分のソースコード (スコア:2, 興味深い)
ワタクシ、半年前どころか、3年前とか10年前に書いた
コード(C89のC)でも、解読に困ったことがありません。
自分の昔のソースは判らん、とはよく聞く話なんですが、
皆さん本当にそういう経験が多々あるのでしょうか?
Re:昔の自分のソースコード (スコア:2, 興味深い)
>皆さん本当にそういう経験が多々あるのでしょうか?
一番最初のコメントにありますが
「反面教師」として、ではないでしょうか。
逆に昔のソースと同じレベルだと自分の進化がないわけで。
自分が一番参考にするのはライブラリソースかな。
STLとかboostとか見ていると目から鱗です。
つーか、よく考えてあるなーと。
kusanagi shin
Re:昔の自分のソースコード (スコア:1)
> 自分の昔のソースは判らん
状態でした。
# というかコーディングからしばらく離れていた療養中のID
... from rakehelly programmer.
Re:昔の自分のソースコード (スコア:1, 興味深い)
ハンガリアン記法なものだったり、constractor() って関数が出てきたり ...
今は郷に入りては で、Linux 風な感じかな。
若い頃は、どこか自己主張臭のあるスタイルだったが、今は誰が書いたかわからんような感じになったなぁ。
Re:昔の自分のソースコード (スコア:2, 興味深い)
わたしですか?個性バリバリです。すいません。
-- Takehiro TOMINAGA // may the source be with you!
Re:昔の自分のソースコード (スコア:1)
PC9801が修理不能になったということで、一昨年、20年前にTurbo Pascalで書いたコードを、VBに移植する羽目になりましたが、コードの動作が読み切れず、大半は、そのまま移さずに、procedureの動作を記したコメントをもとに新たにコードを起こしました。ところが、それでうまくいかずに、コメントを無視してコードの方をまるうつししたら動きました。そういえば、現地でいわれて仕様を変えたようなかえなかったような・・・
Re:昔の自分のソースコード (スコア:1)
//DEL YYYY/MM/DD XXXX START
/*
~
*/
//DEL YYYY/MM/DD XXXX END
で囲まれてて、スイミングアイ・・・
---- I don't Know What You Say !!
(意味わかんねぇ!!)
当然今は反省 (スコア:2, おもしろおかしい)
が抜けてます。
おすすめコード (スコア:5, 参考になる)
#あと、技術的にというかマニアックに「凄っ!」と思ったのは「Perl 2行でRSA暗号 [std.com]」あたり。
Re:おすすめコード (スコア:1, おもしろおかしい)
2chですが (スコア:4, 参考になる)
今までに見たソースコードで一番感動したのは [2ch.net]
みたいなのがあります。
1を聞いて0を知れ!
お約束 (スコア:3, おもしろおかしい)
Re:お約束 (スコア:5, おもしろおかしい)
Re:お約束 (スコア:3, おもしろおかしい)
S&BのOPEN SOURCE [archive.org]
# どこにでもあるだろうと思っていたが、探すのが大変だった
Re:お約束 (スコア:3, すばらしい洞察)
Re:お約束 (スコア:2, 興味深い)
#Sudden Death SauceにハマっているのでID
Re:お約束 (スコア:2, すばらしい洞察)
#意図する所は違うけども、ハングリー精神って大切よね
Deepsea the Evoker St:10 Dx:13 Co:14 In:18 Wi:9 Ch:9 Neutral
Dlvl:1 $:0 HP:12(12) Pw:8(8) AC:9 Xp:1
興味のあるソースを読め (スコア:3, すばらしい洞察)
Re:興味のあるソースを読め (スコア:3, 興味深い)
PHPerですが開発する時にUnitTestをしようとしてassertが良くわからなかったので、ソースを見て覚えました。
クラス分割と継承が良くできていて読みやすかったのを覚えてます。
Re:興味のあるソースを読め (スコア:2, 参考になる)
なでしこ [nadesi.com]
「○○を作りたい」でなく「ソースを読みたい」のなら、
この辺から覗いてみると面白いかも。
匠気だけでは商機なく、正気なだけでは勝機なし。
Re:興味のあるソースを読め (スコア:1, おもしろおかしい)
そしてバグ見をつけて、blogに書いてニヤニヤする。
何かあったときは、あの辺があやしいですよ~とか言ってみる。
上司の評価が上がること間違いなし。
読んではいけない本 (スコア:3, 参考になる)
「こういうコードを書いちゃいけません」ってのを習えるのはリファクタリング* [amazon.co.jp]の第三章「コードの不吉な匂い」を読むのが早いと思います。(Amazonで目次が読めます)
全てのプログラマが読むべき本だけど、ほとんどの人は読んでないと思うので、読んでしまった人は他人のコードの汚さに耐えながら生きていかなければいけない十字架を背負う事になります。
「わかりにくいけど良いコード」を書けたり分かったりするのに役立つかもしれないのはデザインパターン入門 [amazon.co.jp]やHead Firstデザインパターン* [amazon.co.jp]です。読むとパターンを使って自称エレガントなコードを書きたくなってしまいます。自分だけのためのコードならそれで結構。だけどカプセル化って言葉は聞いたことがあっても体得してない他人と共有してるコードの場合は「わかりにくいけど」ってのが仇となって意味不明なコードを書いてると嫌がられてしまいます。
*) 原書しか読んでないので訳の出来は知りません
ソースよりデータ読め (スコア:3, すばらしい洞察)
データをどう構成するかはその重要度にくらべて低く見積もられすぎてる
ような気がします。
世の中のプログラムのかなりを占めているのが情報を再利用可能な形で
保存して、あとからそれを効率よく読み出すたぐいのもの。それらを
どう実現するのが効率よくメンテしやすいかを学ぶのはプログラミング
技術向上のかなりの早道ではないかと思うのです。
さまざまなファイルフォーマットに着目して、どうしてそのフォーマットが
採用されるに至ったかを考え、それをどう扱うのがロジックとして適切かを
いろいろ考えてみるのは楽しくもあり、勉強にもなります。
データ構造として人間が読んで理解できることが目的のものならたとえば
HTML。パーザやレンダラを読み合わせれば、機械が処理しやすいことと
人間が読みやすいことにどう折り合いをつけるかという妥協点の選択が
過去どのように行われてきたかを読み取れそうです。計算機言語のパーザ
なども表現能力と処理効率のせめぎあいを見てとれて楽しめますね。
読み書き両方の自由度と性能を考えるなら、おすすめなのはデータベース。
検索と更新の性能バランスをどうとるかで設計が大幅に違ってきますし、
ワーストケースを救済したいのか平均処理速度を上げたいのかでもまた
違ってくるわけです。そのバランスをとるために読み書きを行うコードの
どの部分に負担がかかっているのかをソースコードを見て調べると、自分が
その手の(もっと単純なものであっても)プログラムを書くときの道しるべに
なります。
広い意味では、というかここでの観点からは、たとえばファイルシステムや
日本語入力プログラムの辞書や学習ファイルなどもデータベースの一種です。
辞書ソフトの辞書データなどはリードオンリーのデータベースであり、作成の
コストを度外視して検索とスペース効率を上げることが設計目標となります。
その意味ではデータ圧縮も重要なファクターのひとつ。
このようなデータをソースコードなしに解析し、それを処理するコードを
自分で再構成してみるというのも、パズルのようなもので、プログラミングの
技量向上というかタフさを身につけるうえで非常に役立ちます。
codezine (スコア:2, 参考になる)
2chも参加できる? (スコア:2, 興味深い)
# ある意味芸術性があるかも…
まぁトンカツソース程度の用途しかないわけですが
Cプログラミング診断室 (スコア:2, 参考になる)
良いプログラミングのために、悪い例を読んで損はないかと。
Re:Cプログラミング診断室 (スコア:2, 参考になる)
# アンチパターンは大切だよね。
マラソンで二位を抜いたら何位?
FindBugs (スコア:2, 興味深い)
-- gonta --
"May Macintosh be with you"
どうでもいいけど一番見難いコードは (スコア:2, 参考になる)
知らない人は、こちら [wikipedia.org]まで。こっちから見ると面白さが半減します。
どんなソースでもいいよ (スコア:2, 参考になる)
そんな仕事を15年以上やってたから、どんなソースでも読める。
ただこれにはトリックがあって、以下の2点の作業を行う必要がある。
1.コメント文の削除
2.インデントツールでK&Rスタイルに整形
1は、ダメプログラムのコメント文は、往々にして「邪魔なだけ」だから削る。
2は、自分のコーディングスタイルに近いから読みやすくなるというだけの理由。
そんな仕事の最盛期は、ソース見ただけでコード書いた人の性格とか判るという特殊能力が身についていた。
(この「性格判断」が、バグ特定にも役に立っていた)
最近はC言語だけでなく、VB6やWebアプリ(ASP)でも同じような仕事が来るようになってしまった。
変数名のコーディング規則 (スコア:2, おもしろおかしい)
変数名がすべて女性名
だったのに泣けたorz
読みにくさ満点だったのですが。
keiko = kyouko + seiko;
JDKのソースコード (スコア:2, 興味深い)
swingとかawtとかはComposerやDecoratorパターン、java.beansはリフレクションやEventパターン、rmiはfactoryとかbuilderパターンの、それぞれ教科書的かつ実際に役立っている好例だと思います。
ちゃんとコーディング標準にも則っているし、自分が使う部分の公開ソースはまず読んでみると良いのでは。
25年くらいの「ASCII」が (スコア:2, 興味深い)
ゲームから円周率計算まで、とにかくBASICの一行(255文字)に収まるプログラムで、トリッキーなことこの上なくて、読んで楽しめました。「一行の中にニーモニックを埋め込んで、それを実行する」なんてのもアリだったような。
プログラミングでメシを食う人にとっては、
「あんまりお手本にしないほうがいいソースコードの展覧会」
であったかもしれませんけどね。
ズバリ Code Reading (スコア:1)
ソースを読むための方法 (スコア:1, 参考になる)
効率良くソースを読む、効率良く勉強する方法というのは、どこかで研究などされていないのですかね。
言語習得は、プロのプログラマでない僕にとって、あまりに非効率で、学習コストがかかりすぎるもので。
とりあえず、知っているもので、
ひらメソッド [hira.main.jp]
Re:ソースを読むための方法 (スコア:1, おもしろおかしい)
Apacheとか普段使うものがいいですよ (スコア:1)
なんでもそうなんですが、ポイントつかむとサクッと読めますよ。
Re:タレコミが大雑把過ぎ (スコア:1, すばらしい洞察)
それらを絞ってしまうと「俺には関係ない」的な発言ばかりになるので、なんでもokな状態にしておいたほうがいいでしょうね。
Re:目的に合わせて (スコア:2, すばらしい洞察)
目的は何、というのがありますね、まず。
単にコードを書けば良いが目的なら、それ以下の記述は首肯出来るでしょう。やっつけ仕事で手早くお金を稼いで、後は野となれ山となれ、の場合も同様。
将来に渡って維持しなければならないコードであるとすれば、たとえ相当に出来る人であってもこういう事を言い出す人は排除して行く方が後々のためになる場合が多くあります。
お客がお金を呉れれば問題無いですけど、瑕疵対応とかサービスとかでお金が貰えないとすれば、運悪くやっつけのコードだった場合は、持ち出しとして百万円単位、千万円単位でお金が飛んで行きますからね。
「急がば回れ」(Re:目的に合わせて) (スコア:2, すばらしい洞察)
設計段階で要求される動作やグローバルな構成を考えるのに若干の労力と頭脳を振り分けるだけで、後工程の苦労が全く違いますので…特にバグが出たときや仕様変更が顧客から出たときに「ここだ!」と言う変更を要する場所の特定や確認を行う事を考えると構造設計を練ることとモジュール化による機能分類を徹底する事は重要だと思いますよ。
Re:Linux カーネルのソースコード (スコア:2, 参考になる)
コーディング規約は一応あって見栄えは統一されてるんだけど、肝心の中身の記述構造が不統一な感じがするんですよね(;´Д`)
Video 4 Linux [linuxtv.org]のコードなんかをいじっていても、モジュールごとに記述構造が違っていて、統一されているのはモジュールAPI(IOCTL含む)の部分とかチューナを登録するときの記述子位では無いですかね…
しかも、ロジック検討し直せば簡単に入らなくなるようなgotoを乱用していて読みにくいコードをわざと使っていたりするモジュール(MSP34xx系のドライバとか)あるし、初心者が参考にするには余りお薦めできないですね
…「とにかく動く、重なるロジックをまとめる程度の整理はした」と言う力業の部分が大きくて「コードとしての読みやすさや美しさ」と言うものとは縁遠いコードが(知る限りでは)多いですからね…
Re:Linux カーネルのソースコード (スコア:1)
OSでなければPearPCのソースはかなり良いと思う。C++だけど。
Re:Linux カーネルのソースコード (スコア:3, 興味深い)
片手にソースコードを渡り歩くのもいい勉強になります。
会話調の語り口で話が続くので、物語としてもなかなか
楽しめて飽きません。また、この本はデーモン君を
通して、ソースコードの読み方についても学べる本だと
思います。
この本(の連載)で育った世代だからか、
*BSDのコマンドやライブラリーのソースコードを読んで
勉強してます。逆に、カーネルは膨大でどこから読めば
良いかも難しく、それを知らずに読めば全然楽しくない
ただの修行になります。さらに悪いことに、カーネルは
カーネルでしか使わない関数や書き方が出てくるので
あまりプログラミングの勉強の教材にならないと
思うのですよね。
勿論、OSカーネルの勉強をする教材にはなりますが。
Re:マジレス (スコア:2, すばらしい洞察)