Entry

よりそいプログラミングのすすめ(追記)

2008年12月24日

ずいぶん前に「qune: よりそいプログラミングのすすめ」というエントリを書いたんですけれど,はてなの方々の反響が予想以上に大きくてびっくり。こゆエントリの需要あるのだろうか。

で,興味深いコメントをいただいたので,少し反応させてもらいます。

lucky_pool lucky_pool program よりそいプログラミング。上手い人の隣でみると、コーディングよりもエディタの使い方(vimとかemacsのショートカットキー)がどうなってるのか気になって仕方がないときがある。 2008/12/24 CommentsAdd Starsilverwire

room661 room661 program ベテランさんのプログラミングを見ると、エディタの機能をグチャグチャ駆使するのについて行けず、「車酔い」する。 2008/12/23

はてなブックマーク - qune: よりそいプログラミングのすすめ

これはたしかにあるんですよね。傍からただ見てるだけといっても,ベテランさんの道具の使い方についていくのがそもそも難しかったりする。もともと自分以外の人がプログラミングしてるわけだから,黙々とやられるとベテランさんじゃなくても,ついていくのはつらいです。分かんなそうな顔をしていると,優しいベテランさんは,解説を加えてくれるんですけどね。

この点,プログラミングする方は,ときどき見てる方に確認するといい感じだったりします。例えば,意図してであれせずであれ,コンパイルエラーが出たときに「どこが間違ってる?」と聞いて,一緒にコンパイルが通らない原因を探すってのも,見る側をポツーンな状態にさせないテクニック。「こう書けばいい?」と聞くだけでも,注意を向けることができます。あたしが見てたときの話ですけどね。どんなもんでしょ。

kogawam テストファーストの考え方とか、リファクタリングのカタログなんてのは少しそれに似てるかもしれない。にしても、がーっと作るときの手順はまた別だしなあ。 2008/12/23

はてなブックマーク - qune: よりそいプログラミングのすすめ

鉄火場のどうしようもないときや,本文のような簡単な例では,上からがーっと書いた方が速かったりするんですよね。たしかに。

平均的に見ると,本文のようにお行儀よく書いた方が,テストや修正の工数を少なく収めることができるって実感もあるんですけど,ここら辺は経験次第ってとこでしょうか。

ksh0ji ドキュメントどころかコメントすら無いコードで「出来上がり」とか言われてもなぁ。 2008/12/24

はてなブックマーク - qune: よりそいプログラミングのすすめ

ここは実装技術の話なので,ドキュメントの作り方やコメントの付け方にまで寄り添われちゃうのは,困ったちゃんなんですけれど,たしかに関数の説明もないのに,これで出来上がりってのはアレですね。少し話が逸れるけれども,補足しておきます。

まず,ドキュメントについてなんですけれど,「ここではもうできてる」ってことにしてください。どこにでも当てはまるもんじゃないから,エントリにしたところで,あまり意味もないですし。

一応,一般的なウォーターフォールの建前から言うと,プログラム設計書や処理手順仕様書といったドキュメントは,製造に入る前に揃えてあることになっています。つまり,実装した後でドキュメントを作るってのは,建前からするとおかしな話なんですね。現場で後追いのドキュメントが多いのは事実だけれども。一方,OSS 界隈では,実装した後にドキュメントを作ることもあると思うんですけど,そこら辺はまぁゴニョゴニョってことで。

次にコメントなんですけど,関数の内部でコメントをつけるほど難しいことはやっていないので,つける必要はないんじゃないかと思います。むしろ,邪魔なのでつけちゃいけない。ただ,関数の説明くらいは欲しいところです。

関数の説明をどこに入れるかってのは,現場によって決まりが違うんですけれど,C/C++ の場合,個人的にはヘッダファイル(.h とか .hpp とかのファイル)のプロトタイプ宣言で書くのがいいと思っています。というのも,C/C++ の場合,ヘッダを読んでモジュールの内容をつかむことが多いからです。実装ファイル(.c とか .cpp とかのファイル)にコメントがあると,ヘッダと実装ファイルを行き来しないと読めないので不便。

つことで,ここではヘッダファイルを作ってないので,何とも言えない。けど,あえて書くとしたら,こんなヘッダを作ることになります。

#ifndef __SAMPLE_H__INCLUDED__
#define __SAMPLE_H__INCLUDED__

// Returns the number of comma contained in the input string.
// When input string is NULL or empty, it returns 0.
int count_comma(const char* str);

#endif // __SAMPLE_H__INCLUDED__

言うまでもないですけれど,このヘッダは実装ファイルで include しておきます。

最後に,これは自分で読み返してみてマズったと思ったんですけれど,普通,関数「だけ」を実装するときに,単体テストの main 関数をむき出しにしたまま,「できた」ということはありえません。他のモジュールとくっつけたときに,リンクできないから。

んなもんで,こういうときには,テストの部分(main 関数)だけ,別のプロジェクトやソースにするのが普通です。いまどき流行りの xUnit を使うのもこの方法です。もっとも,今回の関数は,超生っちょろいので,もっと簡単にやっても十分です。より簡単にやる場合,コンパイルスイッチを使って,テスト用のビルドオプションを付加する方法があります。

#ifdef __TEST_20081224__
int
main(int argc, char* argv[]) {
    ....
}
#endif // __TEST_20081224__

こうやっておけば,

$ gcc -D__TEST_20081224__ sample.cpp

こういう風にコンパイルしたときだけ,実行モジュール(テストモジュール)としてビルドされます。当たり前ですけど,オプションを付けないときは,エントリポイント(main 関数)がなくなってしまうので,-c オプションをつけて,あるいは,エントリポイントがある他のソースと一緒にビルドするようにします。

なんだかその手の向きには常識的な話で,本文と関係なくなっちゃったけれども,補足としてはこんなところ。

Trackback
Trackback URL:
Ads
About
Search This Site
Ads
Categories
Recent Entries
Log Archive
Syndicate This Site
Info.
クリエイティブ・コモンズ・ライセンス
Movable Type 3.36
Valid XHTML 1.1!
Valid CSS!
ブログタイムズ

© 2003-2012 AIAN