ブラウザのブックマーク (といっても、Internet Explorer だと Favorites だけれど) に入れておくほどではないのだが、ちょっと置いておきたいウェブページをみつけたときには、そのリンクを、とりあえずデスクトップに drag 'n drop しておいて、あとから時間ができたときにゆっくり読むことにしている。
さらに、ある程度、恒久的に残しておきたいのだけれども、ブックマークするほど巡回的には見ないという場合には、こういうページに残してしておくと、ブックマークが爆発的破綻をしなくて済む。ついでに、メモもつけられるというメリットがある。
でもって、デスクトップには「ごみ箱」しか存在しないという美しい状態が理想なのだ。
さて、このデスクトップに1個のリンクが置いてある。作成日時を見ると、4月5日。どうかと思うので、このページに移しておく。
Let's use doxygen!
doxygen は、ソースコードに記述されたコメントから、 自動的にドキュメントを生成するツールである。
プロジェクト内でチームを移ってから、メインは Java で、いまや C++ は使わなくなったのだが…、と言いたいところなのだが、先週の半分は C++ を使っていたりする。しかも、ときに C++ の質問も受けていたりする。やはり、プログラミングをはじめてから、いちばん長くつきあっているのは C だし、これに慣れていれば、C++ だろうが Java だろうが、怖くはないのであった。
でも、このページでなにが素敵かといって、以下の記述。ってこれは、Ruby の作者、まつもとゆきひろ氏の言葉なのだが。
- ドキュメント
- まつもとの苦手なもの。彼は普段から「ソースがドキュメントだ。 バグも完全に記述されている」と主張しているが、誰も受け入れない。 当り前だ。
そんなわけで、僕は、読んで解らないソースコードなんて、読めないというわがままな人間なのであった。
過去にもこんな記録をしていたりする
(つづく…)
オトナ語の謎。
「第1回」があるってからには、しばらく続くんだろうなー。ちょっとチェック。
っていうか、ほとんど理解可能、半分くらい日常語化している。
つづく、と述べていながら、いつのまにか放置されてしまうことがままあるので、週末おわりにもかかわらず、ちょっと無理して、1週間前のつづきを書いてみる。
「読んで解らないソースコードなんて」と言ってしまうような人間なので、ソースコードを読むための努力というのは重要である。過去にも「ソースコードを読むための技術」なんてものをブックマークしていたようだ。
さて、オブジェクト指向な時代なので、ソースコードでもクラスが基本である。C などのオーソドックスなプログラミング言語でも「モジュール」というか、意味的な単位でソースコードを分割するというのが基本であるが、Java などでは、「1クラス = 1ソースファイル」というのが、言語的なルールとなっている。
C++ で書くとしてもこれにならって、「1クラス = 1ソースファイル」としておくと、全体的なソースの理解に有効である。ただし、C++ の場合は、ソースファイル (→ コンパイルでオブジェクトファイル .o となる) にクラスの宣言が必要であり、よって、include されるヘッダファイルで宣言を行うことになるため、「1 クラス = 1 ヘッダファイル + 1 ソースファイル」となる。
面倒なのは、クラスにメンバ関数を追加したり、メンバ関数の引数を変更したり、といった場合には、実装であるソースファイル (.cpp) と、宣言であるヘッダファイル (.h) のどちらもを更新しなければならない (はじめからきちんと実装設計をすればよいといっても、メソッドや引数の追加はままあるのだ) ことである。当然といえば当然なのだが、この、一致させなくてはならない、というのが、面倒なのであった。そして当然ながら、ヘッダを変更すれば、それを include しているソースコードは再コンパイルすることになる。
このあたり、統合開発環境を用いていると、宣言の更新や、必要最小限の再コンパイルなんていうことは自動的にできるのかも、と思いつつ、オーソドックスに Term から編集して make しているプロジェクトだと、そうもいかないのだった。仕方がないので、「あるヘッダを include しているソースコードの一覧を表示するスクリプト」を作って、私用していたりした。もちろん、そのヘッダを (include しているヘッダを){1,} include しているソースも表示する。
以上のような複数箇所の変更というのが C++ で実装しているチームにいた際には面倒であった。Java ならば、宣言と実装がひとつのソースファイルの中にあって、1箇所だけ変えればよいし、楽だなあ、と思っていたのである。だがしかし、そこにも落とし穴があったのだった。
C++ のように、宣言だけがまとまっているヘッダがあれば、それを見渡すだけで、そのクラスのメンバがわかる。しかし、Java では、宣言 + その実装コード、宣言 + その実装コード、という繰り返しで、クラス全体を見渡すことが出来ない。これでは、ソースコードを読んでも一瞬では理解できないということになる。その点では、C++ の「ヘッダで宣言」方式も、読む上では優れている方法だと言えなくもない。
むろん、そのために、Java ではさらに優れた方式を用いることができるのは、周知の事実である。javadoc を用いれば、クラスの解説を生成することが出来るからである。しかし、開発中のリソースを追っていて、「今すぐに知りたいんじゃ！」という場合に、javadoc を走らせるのか、あるいは javadoc の長々し詳細な解説が必要なのか、と言われると、少なくとも私の場合、No! なのであった。
(つづく…)
CONFIG::Hash - Class to read 2-column files into a hash
Perl でスクリプトを書くことが多く、しかも、少し機能がアップすると汎用化してしまいがちで、設定をつけたくなる。基本的には、Getopt::Long を使ってコマンドラインオプションにしたり、スクリプトのアタマに設定用変数をくっつけたりするのだが、できればロジック実装と設定は分割したいという欲求が沸いてくる。外部モジュールにして require で読みこむというのもよいが、設定ファイルに Perl のコードが混ざるのが美しくない。
というわけで、設定ファイル用のモジュールでてきとーなのを探す。とりあえず、これ。
ふたつのカラムを持つテキストファイルをハッシュにしてくれる。しかも、# などのコメントを無視してくれるようだ。\ で改行をエスケープできるし、UNIX にありがちな設定ファイルの形式を踏襲している。
もしかしたら、Windows の INI ファイルの形式も悪くないかもしれない。これならば、[section] にわけることができるから。この用途ならば、たぶん Config::IniFiles だろう。
まあ、とりあえずは、CONFIG::Hash。けっこう便利だ。