ソースを読む技術

自分のソース、他人のソース、オープンソース等々のソースを
読む技術、手法などを夜が明けるまで語り明かしましょう

1に経験、2に経験、桂三枝はいらっしゃ〜い

いらっしゃ〜い

突然ですが、今からこのスレはおたふくソースに勝るソースを語るスレとなりました。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 糸冬
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　---------------
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　制作・著作 ＮＨＫ

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 糸冬
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　---------------
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　制作・著作 創価学会

ttp://www.kagome.co.jp/sauce/top/contents.html
ttp://www.otafuku.co.jp/
ttp://www.bulldog.co.jp/syouhin/index.html
ttp://www.gensen.co.jp/sause.htm
ttp://8627.teacup.com/ichizendo/shop/01_01_03/ITH-02/
ttp://www.ikari-s.co.jp/

おたふくいいよおたふく

ctags, grep, globalを使う

>>9
global kwsk

gtags
htags

ソースを飲む技術

暗記力とプログラム構造を頭の中にイメージする力かね。
ツールの使い方みたいな小手先の技術なんてどうでもいいよ。

俺は目玉焼きにソースかけて食べる派

>>14
俺は塩だな。
気分によってはあら引きのコショウを少々。

とりあえず、Code Readingを読めばいいんでないかい？

やっぱり音読が一番でしょ
孔子さまもおっしゃってる通り100回声に出して読みたいプログラム

doxygen使ってます
ただしｿｰｽの量が多くなるとｼﾞｪﾈﾚｰﾄで相当待たされる
CPUの使用率も高く、その間何もできなくなるな

特別な経験や暗記力は不要
構造を図式化するだけ

図式化は面倒ではあるが、完成してしまえば
規模、構成、バグなどを短時間で理解できる

>>19
ただし相手が糞ソースでないことが前提である。

糞ソースでないことはほとんどない

糞コードを図式化する
糞コードだからこそ図式化する
理解するための図式化
糞コードでなければ図式化は不要

そこでdoxygenですよ

コメントを書き込みながら読む

構造化エディタ（古い表現だな)で分岐先へ飛んだり戻ったりしながら流れを追いかけるのが楽だな
あとは読み解いたソースを頭の中でイメージ化できるかと小人さんがどれだけ動いてくれるかに掛かってくる

仕様書が無いと難解。
きれいなソースでも時間がかかる。

デバッガ使ってステップ実行とか、
ログ仕込むとか。

実行してどうする
読めよ

ソースを読む技術よりも

バイナリを読む技術を教えて欲しい

機械の体を手に入れる

>>30
人間だからといって、
DNAが読めるわけでもあるまい。

>>30
９９９に乗れ。

>>29
ttp://delegate.uec.ac.jp:8081/club/koken/~ubora/inst_set.html

>>10
これだろ

GNU GLOBAL
ttp://tamacom.com/global-j.html

とりあえず有名そうなとこ
「ソースを読むための技術」
ttp://i.loveruby.net/ja/misc/readingcode.html
「ひらメソッド」
ttp://hira.main.jp/wiki/pukiwiki.php

ひらメソッドって、頭の使い方を工夫することを放棄してるな。
まあ著者もそのうち成長するのだろうけど。

>>36
kwsk

まず良いソースがどんなものかサンプルがいるな

知っている奴リンク張れや

特に>>1

むしろ下手なソースを挙げて
改善していくことにより
設計のまずさなども
学習できる。
でも俺は挙げん。

下手なソースを改善することも重要だけど、
下手なソースを素材そのままにいかに付き合うか、これも重要。

>>38
つ【http://www.nethack.org/】

どんなに良い食材を使っても
ソース一つで台無しになる場合があるからな。

>>42
ふらんすじんにあやまれ

今このとき――

　　　我々は立ち上がる――

　 　 　 /＼ 　　　 我が名を永遠に刻むため――
　 　 ／∬　＼
　　 / .人 　　＼
　／ （＿_）　　 /＼
　＼（＿＿） ／　　＼ 　 　時は満ちたり！
　　 ＼ 　　/ 　 　 　 ＼ 　　 　　 　　　　 ニュース速報　　いざ出陣！！
　　　　＼／ 　 　　　　　＼
　　　　　　　　　 ∧∧∧∧＼
　　　　　　　　　（　 ´／）　））ヽ∧
　　　　　　　　 ／ 　 ／　　/ ´∀） ∧∧
　　　　　　 ○(　　 イ○　 （　　　,つ, ,゜Д゜)
　　　　　　　／ヽ　 )） ヽ　 )ヽ　)と　　, イ
　　　　　　 （_／（_/(_／（_/ノ（_/⊂ノ> )Ｊ
　　　／￣Y￣｀|/￣＾Y￣ヽ/￣￣Y ｀´￣＼ 　http://live22x.2ch.net/news/

良い小説って
目次や登場人物一覧とかってなくても
章立てや人物の特徴(?)とかが明確になっているから読める

プログラムソースコードもそーゆー事だ

製作者がプライド捨てて簡潔･平易に書いたソースが理想的。
製作者がこれでもかってくらい知識ひけらかして書いたソースって、
ソースのメンテ拒否してるようにしか見えない。
そしてコメント内容が間違ってるなんて論外。

>>46 の意訳: 私はバカです

知識をひけらかして読めないコードってどういうんだよ？

template<char x>int _(int){return x;}int i,L;int main(){L

=++ i;_
<'_'> ('_')
/i | L/ i | L
/ L / L ;;;

}

>>46
プログラマなんて掃いて捨てるほどいるんで、
ソース読めない方はとっとと転職する事を勧める。

>>50
オマエ等ドカチンの根性主義はどうでも良いんだよ
こういう問題意識から新しいパラダイムが生まれるんだ

仕事が遅い奴はソースを読むのが駄目。
そういう奴ほどソースを眺めているだけで読んではいない。
ソースは斜め読みをしてはいけない。

すぱげりーソース読みたくないので職変えるか

>>52
あなたの言う眺めると読むの違いは?

テーマに詳しくて、基本的に計算式とか技法とか原理とか理解してれば
斜め読みでも何をやっているのか、おおよその見当はつく。
逆だといくら努力してもわからない。

建築わからない人が構造計算のプログラム見てもしょうがないとかそういうことだろ。

>>54
眺めるというのはただソースをスクロールさせているだけで
脳が知らず知らずのうちにソースを拒絶している状態。
読むというのは一字一句まで読む位の覚悟と集中力で
８時間くらいぶっ通しでソースを頭に叩き込む作業。

「8時間っすか」

そう、８時間。

時間というより「読んだ〜」という気になるのはスタックが
１０段とか上下しつつデータが分割されたり再構成されるフローの
イメージがぴしっと立ち上がった時。

過程の90%位までは「あれがこうなってそうなるとああなって・・・」の
各々の処理フローが脳内で交差してるだけなのに、臨界点を過ぎると
パズルのピースの様にスパスパはまる。で、そこから設計意図（そもそも
なぜその処理・実装が選択されてるのか）が逆に理解できたら
「ソースが読めた」ということだと思う。「ここはこうなりゃいいのに」と
思った所が次のリリースできっちり直ってきたりすると気持ちいい。

持ちネタないけどage

オフショアであっても、現地語でいいから
コメント入れとけといいたい

カネもらってPG読む仕事なんて
「まだ動かないけど」なんてさわやかな笑顔で
いきなりキングファイル５冊とか渡されるんだぜ？

日本語のコメントが書かれたソースを
英語圏の人に渡したら文字化けしたまま読んでたんだけど
その人は「文字化けしてる」という事実にすら気付いていなかったようだ

あらゆるコメントの90%はクズ

コメントについてのコメントが必要だ。

どうコメントすればいいかわかりません！

>>66
// どうコメントすればいいかわかりません！

こうですか？わかりません！＞＜

#もう〜
#つまんなすぎっ！

必要なコメント：
・思いつきアルゴリズムの処理の前に、軽く流れを説明するコメント。
・関数の前には一行要約。
・定石にそぐわない処理に理由を説明。
　例えばmallocの戻り値をチェックしない等。

不必要なコメント：
・ブロックの最後に、ブロック先頭の文を添える。以下例。
if(C) {
} // if(C)
・式や文単位で処理の内容を説明するコメント。以下例。
if(C) // Cは真か？
　fprintf(fp, "('A`)"); // fpに顔文字"('A`)"を出力。
・自分語り。「ここはこのように書くべきだ！」等。

他人の書いた小汚いソースを読むほど腹の立つことはない

ナナメにさらさら眺めてたら今の自分にとって重要な個所が強調表示されてで見える。

>>69
> 必要なコメント：
> ・関数の前には一行要約。

関数自体や引数にコメントがいらないくらい、
適切な名前が付けられているのがベストだと思う。

確かに。ベストはそうかも知れませんね。
貧相な環境でソース解析する時に、処理内容が想像しやすい関数名にどれだけ助けられたことか。

>>69 ミス訂正。
×定石にそぐわない
○定石から外れた

=begin
いやんのびたさんのエッチ
=end

コメントは処理内容よりもデータの説明と背景説明をしっかり
やってほしい。

おおざっぱな処理目的と図に描ける程度のデータの説明があれば、
後はモジュール冒頭とか中核コード周辺の要所要所に何でそんな処理を
しているのかとか、なんでその方法を選択しているのかとか、
どういう経緯で現在の形に至ったのかとかコードに直接関係しない
背景情報を書いておいてほしい。

そのコードに関する背景なら自分語りでもいいので冗長なまでに
書いた上で、TODO/FIXME/WONTFIX/BUG/INFOとかタグ打ちしておいて
貰えれば意図をつかんだり斜め読みする時助かる。処理内容の
説明は簡単にコードと乖離するけど、背景情報は変わらないから。

なる程。参考になる。

読む話じゃなくて書く話になっとる

うまく読む技術など存在しない
日本の国語教育の弊害だな。
相手の意図を汲み取るより
自分の意図を的確に伝える教育が必要だ。

CODE READINGとか読む技術の本だけど。

ある日曜プログラマの言葉
「この世の中で、最も理解しがたいのは、過去の自分のプログラムである」

「何で俺以外が書いたソースってこんな汚いんだ。」って、みんな思ってる。

読みたくないと思わせるようなソースを書くやつの方が圧倒的に多いけど、読みやすい人も多少はいるお。

プロトタイプだからということで殴り書きで作っていたら、
なぜか途中でリリース版になりました。

後を引き継いだ人、がんばって！

他人に読みやすくなんて書いてやらねーよ
読むんじゃねーよスケベ

入社時にちゃんと事細かい契約書にサインさせているとこならいざしらず、
そうじゃない会社ならソースファイルは個人の創作物だとか言い張って他人に
見せないってことはできなくはないだろうな。裁判では多分確実に負けるだろうけどｗ

>>83
あるあるｗ

>>85
ソースのコメントを全て削除しろｗ
コメント部分はプログラムではない。
自分しかわからない用語を沢山つかえ！

>>84
今日の自分は明日の他人なんだよ
ソースを読みやすく書くのは他人のためじゃなく自分のためだよ
保守も含めてプロジェクトに関わった経験長ければ長いほどそうなる

汚くて言いと云ってる香具師は短期プロジェクトしか知らないか
作りっ放し逃げっ放しだったんだろうな

ネタにマジレスしてまで偉そうなことが書きたいとｗ

2chなんてみんなそうじゃないか
全力で喰いついた方が盛り上がるだろ

盛り上がる？

>>88
ひんと：偽装派遣

読むのが大事とか言うけど
書く経験が相当無いと読めないんと思うんですが間違ってますか？
少なくともAPI関数とかライブラリの機能何て何度か使った経験が無いと
それがどんな挙動するか分からないし…

そんなんどっかに書いてあるやろ

書いてある事の詳細が理解できなく
いったんそれのテストプログラム作って動作確認しちゃうんですが
それじゃまずいって事ですよね？

べつにまずくはないだろうけど、人のコード読む時に全ての詳細を理解しようとしてたらキリがないよね。

ソースを読むコツは、全体把握

効率よく、全体把握するコツを、教えてください。

なんつーか全体を把握するのに必要な情報をつかむ為に細部を調べて悩んでる状態なんだよね俺
一応マクロとか作って手でテストコードを0から書く手間は減らしてるから
そんなに面倒でもないんだけど、理想はそんな事せずにすらすら読んでいきたいもんなんだ
やっぱ慣れていくうちに変わるもんなんだろうか？

ストーリーよりもデータ構造を理解するように努める

>>99
データ構造から攻めるのは非常に有用。
あとは、最初はモジュール構成とかデータ構造とか機械的に目標を決めて着手す
るけど、なるべく早くピンポイントで知りたいことを決める。

今の職場に転職して三ヶ月。
思うことは、「…さすがに限度があんじゃねえの？」
謎の計算式に、意図の取れない条件文。
引数、戻り値、定義値は一切使わず、
ローカル変数は可能な限り使いまわされる。
もう本当勘弁してください。読めません。

…いや、まあ、一緒に働いてる人は
それでちゃんと仕事できてるんだから
俺の力が足りないだけなんだけどさ。

>102
カッコエエ
人が変ったら保守できなくなって
破綻するけどな普通
よほど待遇いいのだろうか?

逆説的だけど、全体を把握するためには、まず細部を見る必要があるんだよな。
解析の入り口さえつかめれば、トップダウン＆ボトムアップの繰り返しで大体理解できる。

最近配属されたところ、ライブラリ名がLIB0010,LIB0020, でその中の関数名がLIB0001() 。
引数はP01,P02... 。こういうプログラムが実在するとはじめて知りましたｗ

おれJavaでそういうの見たことあるｗ

インクルードガードに使う文字に普通に使うもの＋GUID使うのとかもヤバイのかなぁ

目に付くとこにGUIDが書いてあると一気に萎える

>>106
インクルードガードは問題ないだろ。

>>104
それどこの不治？

>>104は実在する




と昔のどっかのスレで見ました

>>104
釣りにしてももうちょっと真実味がある内容のほうがいいんじゃないか？　　　　　　　　　　　　　　　　　・・・ってきっと本当なんだよな（鬱

C++のソース読むのにVisualStudioより便利なのってあります？

ソースは読むものじゃない
かける物だ
　　　　　　　　　　　　　　　　　　by,>>113

・・

そーっすかｗｗｗ

ワロタ

>>113
天才？

>115
こっちのが笑えたけど

ソースよりソープだ

>>119のせいですべてが台無しになった件について

イヤン・ソープ

既にダジャレスレになっている件について

そのうちソープについて語るスレニなる予感

慰安ソープ

>>106
#program onceもしらんとは

>>125
移植性って知ってる？

pragmaやろ

#program once ﾜﾛﾀ

ごめん、本当は、普段はC++なんか使ってないんだ orz

　　　　　,,　- ―-　、
　　,. '" _,,. -…;　　　ヽ
　 (i'"（(´　 __ 〈　　　　}
　　|__　r=_ﾆﾆ`ヽｆﾊ　　}
　　ヾ|! 　 ┴’　　}|ﾄi　 }　　そうかよかった時間があるんだね>>129君
　 　 |! ,,_　　　　　 ｛'　 }　　ではさっそく僕と
　　　「´ｒ__ｧ　　　./　彡ﾊ､　　　いっしょにお風呂にはいろう
　　　 ヽ　‐'　　／　　　"'ヽ
　　　　 ヽ__,.. ' ／　　　　　ヽ
　　　　 ／⌒` ￣ `　　　　ヽ＼_
　　　 /　　　　　　　　　　　i ヽ　＼
　　　,'　　　　　　　 　 　 　 }　 i　　ヽ
　 　 {　　　　　　　　　　 　 ｊ 　 l 　　 }
　　　i　　　ヽ　　　　ｊ　　 ノ　　 | 　 } l
　　　ﾄ､　　　 }　　　/　　/　　　l　　| .|
　　　!　ヽ　　　　　 |　 ノ　　　 j　　'　|
　　　{　|　　　　　}　|　　　　　 l　　　 |
　　　ヽ |　　　　 i　 |　＼　 　 l　 　 /|
　　　　{ |　　 　 l 　 |　　　　　|　　 / |
　　　　l　!　 　 　 　 | 　 　 　 l　　/　|

一回限りのコーディングでバグ知らずはもはや神の領域だよな
#program once

#program onze

#program orz

低脳の溜まり場