PROGRAMMER'S FAQ  to index

はじめに

 2001年1月1日の日記を書くにあたり、新年だし新世紀だし何かやるかと思い、とりあえず手近にあったC言語のFAQが目に入ったので、これのプログラマ版を一日一個書いてみようと始めたのですが、気がつけば一月経っていて、2月はどうしようもうでもネタ無いよでもこのまま終わるのもなんだし、という事でまとめる形を取って別コーナーにしてみました。新年とも新世紀とも関係ありませんが、2001年でプログラマとして仕事を始めて10周年を迎えるので、まあその記念みたいなものです。

 ここにある質問と解答は全て自分が書いたものです。つまり自作自演です。ですが、プログラマをやってればある程度思い当たる問題、人から聞く話、これから起こるであろう話など、一応考えて書いています。

 これを読んだプログラマの皆様に、なんらかしらの参考になれば幸いです。あと、プログラマでは無いけどプログラマと一緒に働く人(SEとかデザイナーとか企画とか顧客とか)の皆さんにとっても、話の内容は解らないでしょうけど、プログラマとはこういう問題に直面しているのだという事を感じて頂ければ幸いです。



Q.どうしても取れない致命的なバグがある。考えられる手を尽くしたつもりだが、何かアドバイスはないか?
A.プログラムを組んでいて、特にマスターアップ直前になってこういう状況に陥ると、自分が思っている以上になかなか冷静になれないものである。これから示す例はあくまで参考であり、特に目新しい事でもないのでその辺はご容赦願いたい。まず手始めにそのバグを「簡単に再現できる手順」はあるだろうか?ないのならそれをまず用意すること。簡単に再現できるのならバグの原因を見つけられる可能性は非常に高まる。デバッガなりデバッグ出力なりを使って、おかしくなり始めるポイントを探せば、時間は掛かるかもしれないがバグの原因を突き止められる。事がそう単純ではないのだとしたら、例えば「簡単に発生しない」「発生条件が一定してない」というその事自体が、ある意味有益な情報である。それはつまり「ある時点から正常でないデータが(や書き込まれてはいけない位置にデータが)書き込まれている」「実行するたびに一定しないデータをプログラムが何らかの形で利用している」事であると考えて差し支えないだろう。また、プログラムを他人に説明する、見てもらうということも、意外な解決の助けになる事がある。デバッグ作業に行き詰まったら、試してみるのも悪くはないだろう。そのバグが、ある時から突然発生したようなのであれば、間違いなく直前の状態から変化した部分に問題があるか、変化した部分のせいで問題が表面化した可能性がある。何が変わったのかを思い出して、できればその部分を排除して再度試してみること。最後に、時間的に調べる時間も駆除してチェックする時間も無いと思われる場合、可能なのであればバグを含む仕様部分を排除することも考えてもいいかもしれない。排除してもまだ問題が起こるとしても、それ自体が更なる情報になる(間違っていると思われる部分が違うと言うことを示している)。あと、これはあくまで最終手段であり、容易にこの決断を下してはならない事を忘れずに。

(2003/1/12)


Q.古いソフトを移植する仕事をすることになったのだが、そのソフトに関しての「資料がない」と言われた。どうすればいいのか?
A.これは難しい。古さと規模にも寄るのだが、動かす環境が実在し規模が小さいソフトなのであれば、自分自身で仕様を調べれば済む場合もある。仕様も規模も未知数なのであれば、ある程度調べて移植してみた上で、実際に発注元に使ってもらって仕様を確認してもらう意外道が無いのかもしれない。最悪なのが、「移植元」であるソフトを動かす環境がない場合で、さらには手元にある資料が「操作マニュアル」だけとかいった場合、もはや移植が不可能と思われる事態すらある。とにかくこういった仕事を受ける羽目に陥った場合の解決策はただ一つ。「できる限りの資料を数多く集める」こと。その上で、発注元との「仕様上の詰め」を行い、できることなら妥協点を見出すこと。

(2002/10/20)


Q.たった一つのことを実現するだけなのに、今の環境でどうして良いのかわからなくなった。こういう見えないトンネルを抜ける良い手段はないか?
A.この手の漠然とした質問が来ると「どう言う環境で?」とか「どういうことをするための?」とか、具体的なことを聞きたくなるものだ。しかしこういったことは様々な状況、環境で起こることである。それぞれの状況でそれぞれの環境に置き換えて読んで欲しいのだが、まず、自分が開発している環境で、自分が実現している状況を再現しているサンプルを探すこと。そのサンプルを自分の環境にできるだけ「ほぼそのままの形で」移植してみて、その実行状況を見てみる。そこから、徐々に自分の環境に都合の良いように移植していく。それが間違いのない、ほぼ最短のルートであるはずです。問題がそんなに単純な話ではない、もしくはろくなサンプルが手に入らない状況であれば、開発環境に添付されているマニュアルやライブラリのヘッダファイルなどを見て、片っ端から試していくしか手はない。少しでも実行状況が変わったのであれば、それが例え自分が望む状況で無いにせよ「どう変わったか」をメモしておくこと。とにかく「調べて、試す。」という二点は忘れないように。情報を集めて、その情報がどうしても見つからなければ「誰も試してない」訳だし、「誰も試してない」以上自分自身が試すしかないのだ。

(2002/10/15)


Q.プログラムしててよくポカミスをやることが多いのですが、何か未然に防ぐコツとかありますか?
A.確かにありますね、ポカミス。バグが起こってソース見てミスを発見して「なんでこんなことやってるんだ?」ということ、確かにあります。でもそれって「一気にプログラムして実行してみた結果起こった」って傾向、無いですか?別の言い方をすると「機能を二つ以上一気にプログラム組んでそれから実行」してませんか?それって、結構バグを産みやすいんですよね。ではどうするかと言うと、「一つ一つ機能を作る度にテストする」ことです。例えば、「ファイルを開く、データを読む、読んだデータを加工する、これをデータを読み終わるまで繰り返して、ファイルを閉じる」と言う一連の動作でも、最低で3つの段階があるのですが、その一つ一つのプログラムをするたびにテストを実行するのが理想です。まあ、実際はそこまで細かくできるかというとそれは難しいと思いますが、少なくとも「細かく、段階的に、組んだプログラムをテストする。」ということは、間違いを減らすことに繋がります。その段階の細かさは経験で培っていく物なので、ここでは詳しくは論じませんが、こういう痛い目にあっていくうちに身についていくものだと思います。もし身につかない、ポカミスの回数が減らないんだとしたら、一つ一つの仕事、作業に気を配って学習するように勤めてください。

(2002/10/11)


Q.何から何まで自分が組んだシステムでないと気がすまない奴がいる。そういう奴がプロジェクトに入ったららどうすべきか?
A.プログラマと言う人種は意外とワガママな人間が多いので、この手の人はぼちぼち見かける。それが今後の仕事に対して良い影響を与えるようなワガママならいいのだが、たいていは、今までの質問に出てきたような「このエディタは使いたくない」とか「このコーディングスタイルは気に食わない」とか、そういった些細な点が気に食わない人が多い。さて、今度の場合はそれよりも過激で「こんなシステムでは組みたくない」という事であるが、それは、正直そのプロジェクトから去ってもらうしかないだろう。一から全てシステムを組むというなら許されると思われるのかもしれないが、実際はそんな状況であっても許されるものではない。それが許されるのは「同人で一人で作っている状況下」のみである。仕事でやっている以上、例えそのプロジェクトが1人で作られるものであったとしても、後々他の人に引き継がれたりするものである。他人が関わっていたとしたらなおさらで、そういうシステムは、なにか問題が起こった時にたいてどうにもならなくなるパターンが非常に多い。その人が「なんの間違いも問題も無く全ての部分において完璧にシステムを構築できた」という方ならともかく、まあ、想像できるとおりそこまで完璧に事を成し遂げることのできるプログラマはまずいないので、そういうプログラマに出くわした場合、上司に訴えて何とかしてもらうか、自分達で何とか追い出すしかないであろう。性質が悪いのは、こういう状況になった場合、往々にして後味が悪い結果になることなんだけどね。我慢するか追い出すか、どちらが都合が良いかはあなたが判断するしかないですね。

(2002/10/11)


Q.テストプレイヤーのレポートの書き方に腹が立つ。もっと他に書き方はあると思うのだが、何故ああも嫌味な書き方をするのか?
A.指摘のとおり読んで嫌な思いをするレポートも確かにあるが、一つ忘れてはならないのが「バグや仕様ミスや間違いは直さなければならない」ということである。下請けなどでの仕事で依頼主からの設計ミスや仕様ミスによる手直しもあることはあるが、どう言う状況にせよ最終的には直さないとマスターアップにならないのであれば、悲しいかな直すしか道はない。こればかりは、どんなレポートを見ようが読もうが「ああそうかじゃあ直すか」くらいの気構えがないと、ストレスで自分自身のプログラマ人生を終えかねない。相手はこちらの心情や状況や都合を考えてレポートなんて書きやしない。そんな相手が書いた文体にいちいちつきあっていたらこちらの身が持たないので、そういうレポートに出くわしたときは「あ、そう。わかった。」くらいの気持ちでいる方が懸命だ。もちろん、レポートの内容の意味することが解らなければ、理解するまで質問することを忘れずに。

(2002/10/11)


Q.以前「良い教本は無いか?」という質問に「答えるのは不可能」と言っていたが、初心者にはあの膨大な本の中から選ぶのも不可能だ。
A.確かに言いたいことはもっともだし、その気持ちもよく解る。世に出回っている各種言語の教本は膨大であり、それをいちいち吟味して買うのは、言語によっては可能かもしれないが、現在主流となっている言語ではそれも不可能である。さてどうすればいいか?ここで一つ言っておきたいのは、これは何も自分の経験だけではなく、数は少ないが私と交流しているプログラマの意見でもあるのだが、「大体において欲しい情報は一冊の本では済まされない」ということである。最初は一冊の教本でもいいかもしれないが、次第に情報は不足してくる。特に、プラットフォームに依存したプログラムを組もうとしている場合、まず間違いなく別の本を参照しないと解らないことがある。私が前の質問で「答えるのは不可能」と答えたのは、理由はこれだけではないがこういう意味も含んでいる。結局は、自分で本屋まで足を運び、本屋で一冊一冊吟味しないといけないのかと言うと、決してそういう訳ではない。本には大体「目次」や「索引」が付いている。それらを見れば、自分が欲しい情報や項目が見つかるはずである。結局は一冊一冊見なければならないことには変わりは無いが、内容を確認する手間は省けるはずである。それにこの「目次」や「索引」の出来は、その本の出来に比例する。これらが出来の悪い本は、内容の出来も解るというものである。と、ここまで言っておいて悪いのだが、本との巡り会いは結局のところ「縁」である。回答にはなってないが、結局は自分自身にもっとも合う本を探すしかないであろう。その指針として、今回挙げた話を参考にしていただきたい。

(2001/7/6)


Q.将来ゲームプログラマになりたいのですが、どうすればなれますか?
A.ここで通常のFAQなら「どんな知識でも蓄えること」とか「なりたいという気持ちを忘れずにプログラムの勉強をすること」と書くところであろうが、生憎ここは普通のFAQではないつもりなので、自分の経験などをもとに自己流で書く。それと、以後プログラムに関しては何らかの言語を理解しているという前提で書く。確かに、先ほど書いた通常のFAQの解答のようなことはやっておいた方が良いに決まっているが、問題は「どうすればなれますか?」と言うことなので、そこを中心に話をしてみよう。自分の場合、これもまた簡単の解答で申し訳ないが「とにかく自分で何でも良いからゲームを一本作ってみた」結果ゲームプログラマになれたというわけだ。ただし、いきなり「ゲームを作れ」と言われてもそもそもどういう原理でゲームが動いているか解らないだろう。作ったことの無い人間が、「ゲームを作ろう」という事態になった時に特に多い傾向なのだが、不思議と彼らは「自分ができる以上のことをいきなりやろうとする」ことである。そして、いざ作ろうとしてどう作って良いか解らず、頭の中の企画だけで終わってしまうことが多い。それはそうである。よほど気長に作ろうと思わない限り、通常のプロだって何ヶ月、下手したら年単位で、しかも数十人数百人レベルに「近い」物を作ろうとしているのだから(まさか?と思う諸氏は自分が作ろうとしているゲームを思い返してみてください)。ではどうすれば良いか?答えはそんなに難しくない。まず「自分一人で作れるようなゲーム」を考えること。そしてそのゲームの規模は「最小限に抑える」こと。これさえ守れば、最低限、自分にしか楽しめないかもしれないが、「自分が作った」と感じられる一本が作れるはずである。後は、その規模、システムを徐々に拡張していったり、新たに作るときに、前に作った以上のものを作ってみたりできるはずだ。重要なのは、まず「自分に組めるプログラムで最低限一本作ってみる」ことである。アドベンチャーでも良い。ノベルでも良い。ドラクエ型のRPGでも良い。なんと自分は、高校時代から実際にプロになるまで、BASICという簡易言語でRPGを数本作っている。ドラクエ型のRPGというのは非リアルタイムゲーム(アクションゲームみたいに複数のキャラを同時に動かす必要が無いゲーム)であり、しかもパラメータ管理とか敵とのバランス調整など、システムが単純なわりにゲーム性に関わる部分が多いので、勉強にはかなり良い素材である。結論から言えば「ゲームプログラマになりたいならまずゲームを作ってみる」。これに尽きるであろう。

(2001/5/15)


Q.仕事でプログラムをやっている。最近自宅でもフリーソフト開発を始めたが上手く進まない。何か良い手はないか?
A.自宅で一人でやっていて、一番問題になるのはなんと言っても「スケジュール」である。最初からどういうものを作ろうと思って、それが自分の力量を考えてどれくらいの期間で作ろうと具体的に計画を練られる人間は稀である。人間は欲深いもので、さらに考え直すもので作っていくうちに「ここはこうしよう」「こうすればもっと良くなる」と欲が出てくるものである。よくソフト開発に関して「期間がいくらあっても駄目なものは駄目だ」という事を言われる。これはある側面では正しいが、別の側面では正しいとは言い難い。プログラムというものは、時間をかけて考え直し、練り直していけばおのずと良くなっていくものだが、多人数が関わると収拾がつかなくなる。また、プログラムの多くは「目に見えない」部分でバージョンアップされるものであり、例え中身が良くなっていたとしても、見る人が見ても何ら変わる事は無い。話を戻して、まず最初に考える事は、具体的な形を如何に短期間で持っていくか、と言うことである。それには、才能よりもむしろ勢いが必要である。最初の形にまで一気に持ち込めれば、後の機能追加、修正などはそれほど苦にならない筈だ。具体的なスケジュールを立てる必要は無いが、そこに持って行くための最低期限(1ヶ月とか2週間とか)を、自分の中で設けるべきであろう。世は〆切りである。〆切りが無ければ何もしないが、〆切りがあればどうにか動くものである。

(2001/3/21)


Q.コンピュータに関する専門用語には解らない事が多すぎるし、毎年増えていく。何か手っ取り早く理解する方法はないか?
A.知るは一時の恥、知らずは一生の恥とよく言われる。知らない事は悪い事ではないが、中には「こんな事も知らないのか?」という、そう思う方がよっぽど恥知らずな連中がいるのも、確かである。さて質問に関してだが、残念ながら手っ取り早い方法はない。解らない言葉がでてきたら、恥と思われる事を恐れずに率直にその場で聞くか、自分に関わりそうな言葉を予め予習するしか無い。コンピュータ用語には、主に「略語」が出てくる場合が多い。最近では「IT」だの「ADSL」だのと言う言葉がよく出てくる。ただ、そういう略語が出てきた場合、その言葉が、どう言う言葉の略語かまで知る必要は無い。その略語の意味するところはどういう事なのか。それを知るだけで充分である。「IT」なら「情報を活用して商売に生かそう」で充分だし、「ADSL」は「インターネットが速く快適に使えるようになる」という程度の認識で通常は充分である。もし、仕事上それよりも深い部分の認識が必要なのであれば、それは世に多く出回っている本や、インターネット上のコンテンツを随時チェックするしかないであろう。どんな事にも「勉強する」ということに終わりは無いのである。

(2001/3/11)


Q.コンパイラの実行効率をどこまで信頼すれば良いのか?このFAQを見ていて解らなくなってきた。
A.このFAQを見ている人間に、コンパイラの実行効率、その他信頼性に関して疑問を持たせたのだとしたら、コンパイラの設計者、見ている人間双方に対し素直に謝罪する。自分が言いたかった事は、「並のコンパイラでも、並みのプログラマがそのプラットフォームでアセンブラで組むよりもメモリ、実行効率双方に関して良い結果をもたらす」という事である。これが10年以上前のハード、つまりハード構成、命令系統が単純な(8086やX68やZ80)ものであれば、Cで組むより直にアセンブラで組んだ方が、果たして良いコードが生成されることが多いと自分でも思う。今ここで議論している事は、少なくともそういったプラットフォーム以上の複雑極まりない、またはハード構成が予測できない、もしくは複雑な昨今のプラットフォームを対象としてきた。少なくとも今後、新しく生まれるプラットフォームの多くは今より単純になる事は無いという事を前提としてきたのだ。勿論、今でも単純な昔ながらのプラットフォームで開発しているプロジェクトもあるだろう。勘違いして欲しくないのは、自分はそれを否定している訳では無い。どういうプラットフォームであろうと、仕事であればそのプラットフォームで開発するのがプログラマの仕事である。確かにCは移植が容易に行える言語であるかもしれないが、それは「どのプラットフォームでも満足な開発ができる言語」では無い。Cに任せられない、自分でやった方が良い部分があるのであれば、それを止める事はしないし、自分にはその権利も無い。

(2001/3/7)


Q.ビットフィールドを使う事にためらいがある。資源(メモリ)の無駄であり遅いと思うのだが?
A.「ビットフィールド」とは、ビット(0か1のみを表現するもの)を操作するためのものである。さて、君が勘違いしている点を一つだけ指摘させて頂くと、遅いとか速いとかそういった事は、主にアルゴリズムに左右されるものであり、その先はコンパイラ(の設計者の思想)に左右されるものである、と言う点である。君がどの程度そのハード(プラットフォーム)に詳しいかは解らないが、余程の事がない限り、コンパイラ設計者は君よりハードのことについて詳しい。そうでないとしても、ビットフィールドごときの動作に関して言えば、普通にビット操作をするのと同等以上のパフォーマンスを出すコードを生成する筈だ。それでも疑うというなら、自分が組んだ時のアセンブルコードとビットフィールドを使った時のアセンブルコードを比較して見れば良いだろう。メモリの無駄に関してだが、ビットフィールドを使うのにためらいがあるようなプラットフォームなのであれば、無理をしてまで使う必要はない。実行頻度と効率を考えた上で、どちらを使うか決めれば良いだろう。そうでないのであれば、それは「使い慣れているかどうか」の差でしかなく、使う事に何らためらいを持つ事はない。勘違いして欲しくないのは「絶対に使うべし」と言っている訳では無い。使うべき局面と使わなくても良い局面は、何もこれに限った事では無く存在する。頭ごなしに「実行効率が悪い」とか「メモリ効率が悪い」というその姿勢に問題があると言っているのだ。並のコンパイラは、並みのプログラマ以上にその2点を考えてコンパイルしているということを忘れずに。

(2001/3/5)


Q.引き継いだソースを見ていて、実際には使って無い関数が沢山あった。消してしまっても良いものか?
A.幾度かのバージョンアップを経てきたり、開発中にテストで作って残った関数(サブルーチン)など、仕事で運用されているソースの中には意外と未使用な関数が残っているものだ。そういった関数を全て消してソースをスッキリさせたいという誘惑に駆られてしまうかもしれないが、それは思い留まった方が良い。実際に行動に移す前に、その関数の仕様を調べたり、製作者に聞けるのであれば聞いてみるべきであろう。意図が全く掴めなかったり、製作者の返答が曖昧だったりした場合、その関数は削除しても問題無いだろう。まあ、調べてみて使えそうだと思う関数を消してしまうような事は無いだろうが、使えなさそうな関数であっても、実際はなんらかしらの意図があって作成されている(その意図に意味があるかどうかは解らないが)。そもそも、使わない関数をいつまでも残しているのがいけないという意見が出てくるだろうが、そういった関数を作った意図、状況、時期などによって、やはりどうしても残ってしまう関数は出てくるものだ。理想を言えば、マスター前に全体のソースのシェイプアップを図る意味も含め、ソースの総メンテナンスを行うべきなのだが、想像できるようにマスター前にそんなことができる訳も無く、結果使われない関数が残る事になる。もしメンテナンスをするとしたら、次にそのソースを使う時(バージョンアップとか続編とか)の最初の頃だろう。その時に、もしその中で残す関数があるとしたら、その関数にコメント(動作意図や残している理由など)を付けること。

(2001/2/21)


Q.移植をする為にある会社からソースを引き継いで、足りないファイルがあったから問合せたら「渡せない」と言われた。どうすれば良いか?
A.そういう場合の大体の理由は、その会社特有の技術なり何かを使っていて、それが会社の資産であるという事が多い。つまり外部に漏らしたくは無い訳だ。ただ、移植という作業は、元のプログラムがどういう動作をするのか知る必要がある。最低限、そのプログラムの仕様なりを伝える義務はある筈だ。どういう契約なり関係でその移植作業が発生したかにもよるが、まずはその「渡せない」なり「公開できない」なりの理由をはっきりさせるべきであろう。はっきりしない場合は、その会社そのものを信用しない方が良い。そもそも移植を引き継がせておいてソース(または仕様)公開をしないということ自体、仕事をする上でのルールから外れている。それが当り前だという業界の流れ、取引先との関係が築かれているのとしたら、それは経営者レベル対応者レベルの話ではあるが、早急に改めさせるべきだろう。そうしないと、いつも泣きを見るのはプログラマである自分自身である。もしどうしようもない場合の助言はただ一つ。そのプログラムの動作(仕様)が予測できるのであれば、それを自分用に作るしかない。元の動作と変わる可能性もあるが、それは仕様公開しない会社が悪い。ただし、もしその仕事が孫受けなり周り回ってなりして来たのであれば、そこまで文句は言われないだろう。どういう状況にせよ、自分の会社の技術に下手に自信を持っている会社は、大企業であろうと中小の会社であろうと、下を見下す傾向がある。もちろん、例外もあるが。

(2001/2/17)


Q.良いデバッグ方法はあるか?
A.デバッグに関して一番重要なのは、如何に再現性を出すかである。再現性さえあれば良いという訳ではないが、まず再現性があればバグの場所を特定することがかなり容易になる場合が多い。特定するには、怪しいと思われるところにデバッグメッセージなどを出力したり、プロファイリングしたりすること助けになる。問題がそんな生易しいものでは無い場合、ある程度予測することが必要になる。予測するには才能や経験が必要になるが(2001/1/31付参照)、とにかく一人で悩まないことだ。自分の身の回りのプログラマの中には、自分の想像をも超えるデバッグ能力を持つ人間が意外といるものだ。自分の能力に限界を感じたのなら、素直に聞いてみるのも手である。ただその際、自分がどういうデバッグを行ったかを的確に相手に伝える必要がある。また、聞いた相手が行ったデバッグ過程を自分の血肉とすることも必要だ。デバッグに必要な過程は、起こったバグによって様々あるように思えるが、実は数パターンに集約される。余談だが、良いデバッグ方法を考えるよりも、デバッグを極力必要としないプログラムを組むことを心掛けよう。出してしまったバグは、いつまでも他人に頼って駆除する訳にはいかない。最終的には自分自身で駆除することになるのだ。

(2001/2/8)


Q.私は記述法にハンガリー記法を使っているのだが周りの人間からやめろと言われる。何故か?
A.「ハンガリー記法」というのは、変数名などの名前の決め方を定めたもので、CharlesSimonyiと言う人が開発した。名前に変数の型情報や使い方を埋め込んだものである。これを嫌うプログラマは、主に反MSを信条としているプログラマに多いと聞く。「CプログラミングFAQ」という本には「主な利点は、データ型や使い方が名前を見ればわかるということである。主な欠点は、データ型は変数の名前に付けてまわるような大事な情報では必ずしもないことである。」と述べられている。やめろと言う人の意図は解らないが、問題があるとすれば、これはプログラミングスタイルにも言える事だが、一つの記述方に慣れてしまえば、他の記述方に移行するのはなかなか大変であるという事である。先にも述べたように、特にハンガリー記法というのは何かと嫌われる事の多い記法だ。そんな事で同じプロジェクトのプログラマの不調和を生むのは馬鹿げている。幾つかの記法を使い分けられる器用さも、こういう場合にはプログラマには必要であろう。ただ、一つの記法を毛嫌いしたり酷評したりするプログラマの姿勢には賛同しかねる。どんな記法、プログラミングスタイルでもそうだが、問題はスタイルそのものでは無く、そのスタイルをソース全体に「首尾一貫して使っている」事が大切である。C言語プログラムで権威高いKernighenとRitchie(俗に言うK&R)も、「括弧の位置はさして重要ではない。ただし人は括弧の位置に強い信念を持っている。<中略>自分に向いている書き方を取り入れて、首尾一貫して使いつづけること。」と述べている。一つのソースに様々な記述法を使っていると、それを読むプログラマも気が散ってしまう。首尾一貫して使うということは、全体のソースを読む時にソース全体の透明性を生み出す。そういう利点を無視してまで自分が使っている記述法以外を認めない姿勢は、かえって自分の首を締め付けることが多いものだ。

(2001/2/7)


Q.プログラムの行数は少ない方が良いと思うのだが、どうか?
A.アセンブラやインタプリタ言語を使っていて、メモリ容量の制限がキツイ環境などであれば、極力プログラム行数を少なく組む事は全く正しいとは言えないまでも間違った考え方では無い。ただ、何から何までややこしいまでに動作を1行に圧縮したり、メモリを節約するために解りにくいプログラムを組むという事は、メンテナンスを困難にするばかりで無くプログラムの実行効率を著しく低下させる恐れすらある。C言語などの最適化付きのコンパイル言語などの場合、実行効率を考えさせつつサイズを抑えるコンパイルオプションを用意しているものも多い。そもそもその環境の限界を超えるようなプログラムを組む必要があるのかどうかと言う事を考えた方が良い。メモリの質問(2001/1/16付)でも述べたが、環境にあった設計をする事が第一であり、環境の限界を考慮しないような設計をするべきでは無い。

(2001/2/5)


Q.あるメーカーから提供を受けたサンプルソースに数メガを超える静的変数があって、気がつかずに流用して酷い目にあった。
A.どういう動作を目的としたサンプルかは解らないが、数メガの領域が必要であるのなら、恐らくストリーミング関係のプログラムなのであろう。プログラムの内容はともかく、サンプルソースとはあくまで「サンプル」であり、多くは「この機能を使うにはこいいうプログラムを組めば良いですよ」という指針、参考でしかない。それをそのまま使うのは勝手だが、使うからにはまずそのソースをよく調べてから使うこと。少なくともサンプルに、実用に耐えうる質を求めないこと。でも、確かにいくらサンプルとは言え、そんな大規模な静的変数を確保するのもどうかと思うが。そのソースを見たプログラマが、そのサンプルを組んだプログラマの質を疑うばかりで無く、そういったソースを提供したベンダーの質をも疑いかねない。

(2001/2/1)


Q.最近のプログラマはデバッガを使う人間が少ない。何か良い指導方法ないか?
A.「デバッグ」という行為は、多くは孤独な作業であり、そして才能と経験が必要である。才能はいかんともしがたいが、経験ならなんとかなる。しかしその経験も、覚えていなければ全く身に付かない。良い指導方法かどうかは解らないが、結局必要なのは「そのバグをその本人が取る」事である。まずバグを取るには見つけなければならない。バグを見つける方法には幾つかあるが、段階を踏まえる事がバグの早期発見に繋がる事が多い。ある程度バグの発生するポイントが予測で切るのであればデバッガをいきなり使わせる事もできるだろうが、再現性が低かったり、そもそも何が原因で起こっているか解らないバグである場合、ソースコードレベルのデバッグだとか、デバッガ上でのデバッグはあまり意味を無さない。デバッガを使わない事を嘆くより、どういう手順でデバッグすれば良いのかを覚えさせる方が良いだろう。

(2001/1/31)


Q.グローバル変数の弊害に悩まされている。何かこの弊害を取り除く良い手段はないか?
A.「グローバル変数の弊害」は、多人数のプログラマが関わるプロジェクトでは特に深刻な事態を引き起こす。この質問だとすでにその「弊害」に悩まされているようなので、考えられる手段は一つ。grep等のツール、もしくはテキストエディタに付属する同等の機能を使って、アクセスしている部分を全て洗い出し、そこを重点に(printf()関数を使うかデバッガでソースブレークポイントかメモリブレークを使って)どういうアクセスをしているかプロファイリングしてみるしかない。もしそれでも捕まえられなかった場合は、最悪の状況として何らかのプログラムが「メモリ破壊(リーク)」を起こしている可能性がある。グローバル変数付近のメモリを絶えずダンプしてみるなどしてみた方が良いだろう。その際は、該当するグローバル変数の位置を「一時的に」ずらしてみるのも手である。それでその変数に影響が出なければ、明らかにリークを起こしている。

(2001/1/30)


Q.VisualBasicのどこがBASICなのか?使ってみたが全然使いやすくない。
A.言語が使いやすいかどうかは、その人がどういう言語を今まで使ってきたか、またはこの場合、どういう環境で開発してきたかに依存するので、一概にどの言語が使いやすくどの言語が使いにくいか論じる事はできない。さてVisualBasicのどの部分がBASICかと言う問いに対する解答だが、BASICの記述体系が受け継がれているという点が第一であろう。確かに「受け継がれている」とは言え、その根底には「MS流オブジェクト志向」が組み込まれているので、旧来のBASICに比べとっつきにくく感じる古参プログラマがいるのもまた、確かである。あなたがWindowsのVisualCからきた人間ならば、VisualBasicを使わなければならない仕事でない限り、素直にVisualCで組む事を薦める。

(2001/1/29)


Q.あるプログラムを引き継いでコンパイルしたら、ワーニングの嵐だった。どういうつもりか?
A.プログラマの中には、ワーニングを「エラー」とは認識せず、言葉通り単なる「警告」として認識し、無視する者がいる。あまりに数が多くなってきて本当のエラー表示を見ることができなくなった時に、しかたなくその警告を「排除」する者もいる。「排除」とは、つまり警告を「でないようにする」だけの処置であり、根本的な解決をしていないため、後になってその生煮えの処置が問題を引き起こしても気がつかず、結局強引に蓋をするという恐ろしい対処で切り抜ける事が多い。「警告」とはコンパイラがプログラマに、何かが間違っている事を伝えているのであり、そのままでも動作はするけど、それが果たしてプログラマの意図通りの動作かを保証するものでは無い。

(2001/1/28)


Q.プログラマ30歳定年説と言うのは?
A.これは、「30歳になったら実力、吸収力などが衰えてしまいがちになるので、この辺りで現役を退いて頂き、後輩の育成に努めていただこう」という会社側の誤った認識の事である。これもまた「2000年プログラマ絶滅説(1/15付参照)」と並ぶ、ある意味迷信と言える話である。この説のおかげで、まだ現役でやっていける筈のプログラマの何人もが現役を退く羽目に陥るケースが後を経たない。個人で「30になったらプログラマを辞めるよ」という分には良いのだが、それを真に受けて他のプログラマに同じように強要する組織は、信じられないかもしれないがいまだに数多く存在する。ただ、確かに「どれだけの実力があれば現役としてやっていけるか」という明確な基準が無いのもまた確かである。考えるべき事は、「指導する」という事と「現役を退く」と言う事は、必ずとも一致しないと言う事である。指導できる人間は、何も現役を退かなくても後輩を指導できるし、逆にできない人間は現役を退いてもできないということである。「指導する」という事と「プログラミングする」ということは、全く一致しないのである。

(2001/1/27)


Q.今使っているシステムのリファレンスマニュアルの出来が悪い。どうすれば良いのか?
A.こういう残念な環境に出会った時の解は二つ。まず、他に使っている人(身近な人間でもネット上でも本でも)を探し出す。自分が初めて、または見つけられないのであれば、自分で一つ一つ調べるしか無い。まだその環境が発表すらされていないのであれば、素直に提供したベンダーに問い合わせた方が良い。逆にベンダーは、そういう情報を欲しがっているかもしれない。一般化されていない環境であれば、自分が調査した結果を率先して公表してみても良いであろう。その環境の先駆けとなるばかりでなく、他に使っているかもしれないユーザーから感謝される。プログラマのコミュニティーというものは、案外そういうところから始まるものだ。

(2001/1/26)


Q.よくメモリの開放ミスで思わぬバグを引き起こす。どういった点に注意すれば良いか?
A.これはCプログラマによく付きまとう悩みの種である。最初は良くても、繰り返し実行しているうちOS自体が不安定になったり、下手をするとシステム自体がハングアップしてしまう事態を引き起こす。一つの解として、デバッグ中はメモリ確保、開放関数に一段別の関数を被せて、確保、開放する度に回数を加算、減算させ、できればその度にプロファイルを出力するようにすることが助けになる。さらに、開放する度にメモリのポインタを保持する変数にNULLを代入し、ポインタを使用する局面では必ずNULLチェックを行うようにすると良い。どんな時も、チェックしてし過ぎると言う事は無い。

(2001/1/25)


Q.コメントはどれくらい書けば良いのか?
A.これは難しい。WindowsNTの開発者であるデビット・カトラーは、コメントに関しての話題で若手プログラマーに「全ての行にコメントをつけるように」義務付けていた。ただ、全ての行にコメントをつけられるとソースコード自体非常に見にくいものとなる。また、一見正常に見えるけど実は無意味であったり、その内容自体が嘘だったりするコメントは有害であるばかりではなく、そのプロジェクトを引き継いだプログラマを混乱させ、またはその内容を信じてそのままプログラムをしてたせいで、プロジェクト自体が破綻しかね無い状況を生み出す。簡単な指針として、変数名や関数名を付ける段階で用途が解るようにしておき、一見して何をやっているか解らない処理部分には、その処理の先頭に「何何の処理」と言う感じでコメントを付け、詳細はその行の横に具体的な処理内容を書く。誰が見ても一見して理解できたり、他に誤解の産みようも無い処理(単純な代入)などにはいちいち付けないようにする。ただ、自分の判断基準よりもさらに一段落として考える事。自分が思っている以上に、自分のソースは他人に理解される訳では無い。

(2001/1/24)


Q.Cのマクロを調べたらとんでもなく複雑怪奇なマクロだった。便利なマクロだから良いんだけど…。
A.そのマクロの機能が明確で、よくC言語で問題となる副作用や、誤解の余地の無い機能や動作を表わしたマクロなら、その内部を意識させないで使わせる事に関しては全く異論が無い。問題となる点があるとすれば、そのマクロがどういう形で公表されているか、であろう。もし、使用する上で厳重な警告や注釈がある場合(同じ変数を二つ以上引数うとして渡してはならないとか、"i++"という自己書き換えを行う引数を渡してはならないとか)、そのマクロを使用する事は控えた方が良さそうだ。むしろそんな複雑怪奇なマクロは、素直に関数に置き換えた方が良いのかもしれない。無論「その関数が呼ばれる回数のオーバーヘッドを考慮した上での設計だ」と反論するマクロ設計者もいるだろうが、他人にとって複雑怪奇なマクロはメンテナンスも困難であり、そのマクロを解析した上でメンテナンスしなければならないという、未来に起こりうる事態がある事も想像しなければならない。ある意味、そういうマクロを組む人間は確信犯的に仕組んでいる場合が多い。

(2001/1/23)


Q.Windowsのプログラムを初めて組む事になったがわからない。何か良い方法は?
A.Windowsのプログラムを組む上でどの部分が解らないかは人によって異なる。しかしどの環境にも言える事だが、その環境特有のクセを見抜くのが一番の早道である場合が多い。WindowsであればC++かCで組むかで道は異なるが、Cで組むのであれば、メッセージループとかウィンドウプロシージャとかWindowsAPIとか各ツールのmakefile(VisulaStudioであればプロジェクトファイル)の書き方設定の方法など、プログラムを組む以前に覚えなければならない事が沢山ある。こういったことは、かえって全くの素人の方が覚えやすい場合があるものだ。ただ一つだけ言える事は、どんな環境にせよライブラリのヘッダファイルを見ることは、その環境がどういう事ができるか、また環境依存の機能をどのように使うべきかを知る助けになる。C++であれば、MFCを勉強する事が良いのかもしれない。但し、移植性を問わないのであれば、だが(どちらにせよ、Windowsで組むという事は、移植性を無視する事にほぼ同義であるのだが)。

(2001/1/22)


Q.Cプログラムを始める事になった。40歳代のオジサンでも解る何か良い教本は無いか?
A.この手の質問に答えるのは、はっきり言わせて頂くと不可能である。いわゆる「プログラム教本」というものは、これはプログラムに限った事ではないのだが、ほとんど全てが「書き手の主観」で書かれている。コンピュータに関するある事を覚えたいのであれば、例えばそれがプログラムであれば、40歳代の方であれば恐らく「FORTRAN」や「COBOL」の経験者であろう、これとCの両方が解る人間から教えを請うのが一番の早道かもしれない。もし、そういった都合の良い人間がいないのであれば、逆にそういった本を探すのが良いのかもしれない。それも見つけられないのであれば、恐らくCを初期の頃学んだ多くの人間が教本として使っていた「プログラミング言語C(俗に言うK&R)」を使って学んだ方が良いだろう。ただし、この本だって良い解答を示している訳では無い事を忘れずに。

(2001/1/21)


Q.動かないと悩んでいた原因がライブラリのバグだった。どうすれば良いのか?
A.素直にライブラリを提供したベンダーに連絡すること。その際は、問題が起こったライブラリのファイル名、どういう問題が起こったかと言う詳細な情報。PCである場合は動作環境の詳細、自分への連絡先、できるのであれば、問題が起こったソースコードなども一緒に送ること。ライブラリと言えど、所詮は人間が作ったものなので全く問題が無いとは言いきれない。逆にそういう問題を報告したことで、以後そのベンダーから優先的に情報を提供されるかもしれない。きちんと体裁に則って丁寧に報告すれば、ベンダーから感謝される事は間違い無い。

(2001/1/20)


Q.新たなる仕様をプログラマに提案したところ「できない」と即答さる事が多い。本当にできないのか?
A.ある意見をプログラマに提案して「できない」と言われた場合、大きく分けて3タイプの理由が当てはまる事が多い。一つは「プログラマの実力のせいでできない」。もう一つは「この環境ではやりたくても物理的に不可能」。最後は「やりたくてもできない」である。最初と最後の理由は似ているようだが違う。最初の理由は完全的に否定的な時に使われるのに対し、最後の理由は、やりたいがマスターアップ直前だったり、それを対処する事により新たなる弊害(必要なデバッグ工程や新たなるバグを生む可能性)がもたらされる恐れがある為である。後者で否定する場合、そういった事情をきちんと説明する事が多いので大体解る。ただ、「そういったことならサポートをするからやってよ」というのは思い留まった方が良い。結局それで問題が発生したとしても、その問題を対処するのは提案者であるあなたではなく、それを実際に組んだプログラマなのだ。それでも、その提案がプログラマが納得するような提案だったら、何も言わに素直にやる場合が多い。言い方一つ変えるだけでも結果が全然違うので、提案する時はその辺りに気をつけた方が良いだろう。

(2001/1/19)


Q.今度の仕事は移植性が求められる。どうすれば良いのか?
A.どういう環境での移植性を求められているのか解らないが、一般的に「機種依存である」部分と「そうでない」部分をソースレベルで分けたり、環境によって変わってくる部分(画面サイズやデータサイズなど)をdefineやtypedefで変更が容易なようにする事が助けになる場合が多い。そもそも移植が不可能に近い環境同士(ウィンドウシステムとコンソール間など)の場合、設計レベルで移植性を高くする必要がある。出力するファイルなどにも互換性を保つ必要がある場合は、バイナリよりもテキストで読み書きした方が良い。双方の環境をよく調べる事。

(2001/1/18)


Q.いまだに「アセンブラで組めない環境は駄目だ」と言う人がいる。時代遅れではないか?
A.何から何までアセンブラで組もうとするプログラマの姿勢も問題があるが、だからと言ってそういう人達を真っ向から否定する姿勢にも問題がある。C言語に代表される高級言語が現状の開発環境の主流だとしても、大体の開発環境にはアセンブラは付属しており、どんな開発環境にしろ、アセンブラで実行効率を図らないといけない局面は、現在では少なくなったが確かに存在する。全てのコンパイラの最適化オプションがプログラマが期待する通りに行われる訳ではなく、また信用に値しないコンパイラすら存在する。ただ、だからと言って全てをアセンブラで組むと言う行為はばかげている。最近の複雑化した(特にRISCチップなどを搭載した)環境のアセンブラは非常に読みづらく、お世辞にも開発効率に貢献しているとは言い難い。実行効率を極限にまで求めるところ(さらに機種依存でも構わないところ)ではアセンブラを使い、それ以外の部分に各種言語を使うのが、正しい使い方であろう。

(2001/1/17)


Q.今度開発するマシンは容量が少ない。どうすれば良いのか?
A.PCなど大容量のマシンから、コンシューマいわゆるゲーム機に移った時に、こういう意見はよく聞く。こういう話が出る度に「いや昔はもっと少なかった」という事を主張するプログラマもよく見かける。しかし、問題の本質はメモりの量云々ではなく、メモリ量を考慮したアプリケーションの設計が重要なのである。ある意味メモリ容量が無尽蔵とも言えるPC環境から来た人間はこの話が意味するところはいまいちピンとこないかもしれないが、ようは「どれだけのメモリを使えるか」ではなく、「どれだけメモリ効率を良い設計をするか」なのである。多ければそれで良いに決まっているし、必要ならば必要なメモリ量を要求する事は全然おかしくは無い。しかし、本当にそのメモリ量がそのアプリケーションに対して最適な量なのかどうか、そこから考えるべきであろう。容量が決まっているのであれば、そしてそれが少ないのであれば、それがそのマシンの限界を示している。マシンに合った、そしてその環境に合ったメモリの使い方を考える方が懸命である場合が多い。

(2001/1/16)


Q.「2000年にはプログラマが必要なくなる」という話を聞いた事がある。これはいったい何か?
A.正確なところは覚えていないが、「アプリケーションを自動的に開発するためのプログラムが開発される云々」とかいう話だったような気がする。今から10年ほど前は、一部の人間の間で本気で議論されており、かの権威高き「日経コンピュータ」でもこれに類する記事が掲載されていたような覚えがある。なんかうろ覚えで申し訳無いが、当時社会人になりたて、と同時にプログラマにもなりたての自分は、「自分も28になる頃にはプログラム以外の仕事をしているかもしれないのか」と、まんまと彼らの妄想に騙されていたもんです。ちょっと冷静に考えれば、自動車を設計図単位部品単位で、しかも全自動で作るようなものであり、実際そういった自動車は今まで見た事も聞いた事も無い事から解るように、今後生まれる可能性も無いに等しいのではないか?(全く無いとは言いきれませんが)

(2001/1/15)


Q.そんな事言っても自分はこのプロジェクトでは発言権は無いし、周りの連中は自分の意見を聞きそうに無い。
A.何故発言権が無く、何故周りが自分の意見を聞きそうに無いのかは知らないが、そういう事であれば、我慢するかプロジェクトを去るしか無いだろうね。しかし事を起こす前に、何故周りが自分に対しそういう態度を取るのかを考えた方が良さそうだ。少なくとも人は、理由も無しにそういう態度は取らない。他人のせいと思う前に、自分に問題が無かったか考えてみるべきだ。少なくとも、この日本で嫌われるような態度をとらなかったか?それを考えるべきであろう。悲しい事に、いくら実力主義を謳っているとは言え、ここは欧米ではなく日本なのだ。

(2001/1/14)


Q.今度一緒に組む事になったプログラマ連中がバカだ。どうすれば良いのか?
A.君がどれほどできるプログラマであるかは知らないし、周りのプログラマがどれほどできない連中かは知らないが、少なくとも君がそうやってまわりを見下している以上、そのプロジェクトは完成には至らないだろうね。君がそれでも良いと思っているのなら、これ以上何もいう事は無い。ただ「どうすれば良いのか?」と思っている以上、どうにかするつもりはあるんだろうね。それなら、周りの連中の水準を上げるか、プログラマを交代してもらうか、自分がプロジェクトを去るしか無いだろう。

(2001/1/13)


Q.今回のプロジェクトはソースのバージョンダウンが多い。何か良い手段はないか?
A.何故そんな事が起こるのか理解に苦しむプログラマもいるかもしれないが、こういった事の多くは「一つのソースを複数の人間が編集する」ような事があるプロジェクトでは、よく起こる事である。「そんな事を何故するのか?」と思うプログラマもいるかもしれないが、全てのソースコードを書きかえる事ができる環境下であれば、わざとではないにしても起こる可能性がある。さてこれを防ぐ手段だが、ソース書き換えの権限を厳重にするか、そもそも書きかえることができなくなるようにする事が一番だが、そういった事ができない環境であれば、取り決めを設けるしかない。それよりも、自分専用のバックアップ環境を構築し、毎日の終わりにバックアップを取るように心掛けた方が良い事が多い。なんにせよ、自衛手段を取る事は得する事は無くても損する事も決して無い。

(2001/1/12)


Q.何故マスターアップ直前になって、今さらのようにバグが発見されるのか?
A.「それはマーフィーの法則である」と一言で片付けられる話ではあるが、幾つかの経験から話をすると、マスター前と直前での、人間の緊張感の度合いからくるものであると考えられる。また、直前になればなるほどチェックする項目が減っていき、ついつい普段はやらない操作などをする機会が多くなるものだ。何気にやった操作なので、プログラマに報告するときもうろ覚えで報告し、それがデバッグの混乱に拍車をかける。そして生煮えの対処が新たなバグを引き起こす事が多いのも、興味深い話である。修正する度に改変履歴などを書いていれば、これらの多くは防げるものなのだが、これもまた、最後の方に対処したバグほど改変履歴に書かれていない事が多い。日頃の注意力を如何に保つかが、これらの混乱を防ぐ鍵であろう。

(2001/1/11)


Q.今の会社は特定のテキストエディタを使用する事を強要される。これに従うべきか?
A.会社(またはプロジェクト)によっては、各プログラマに対し全く同じ開発環境にする事を方針としている所もある。これは、マシンなどになにか問題があった時、すぐに代替のマシン(環境)を用意できるとか、別のプロジェクトに移った時の移行時間の短縮とか、そういったメリットを重要視しているからである。こういう方針に対し、「環境に慣れるまでの時間が無駄だ」という事を声高に主張するプログラマもいる。これには絶対的な解は存在しない。確かに、慣れるまでの時間は無駄なのかもしれないが、一度慣れてしまえば方針が主張するように、かなりの時間ロスを防げるというのもまた事実である。否定する前に、それが果たして有益なのかどうか考えてみるべきであろう。その仕事が一度きりの仕事であれば、確かに無駄な事ではあるのだが。

(2001/1/10)


Q.世にある様々な開発環境の価格は何故こんなに高いのか?
A.昔々、開発環境なんていう言葉すら存在しない時代は、確かに開発環境というものは一部の高級なソフト以外、つまり「PCに付いてくるもの」であり無料だった。ただそういう「金を取る開発環境」体制に反旗を翻し、無償で開発環境を提供している所はいくつもある。有名な所としては、FSFのGNUプロジェクトに代表される「GCC」である。ただ、昔もそうであったように、そういった開発環境で開発するには「自分で探す力」や「自分で追求する能力」が必要な場合が多い。現在インターネットが発達しているとは言え、結局それを使って自分が知りたいと思う情報を探し当てるのも、また自分自身である事を忘れずに。金額とは、結局そういうところに反映されているのだ。

(2001/1/9)


Q.何故こんな無茶なスケジュールで仕事を受けるのか?今度の仕事は、2ヶ月でデータベースを管理するプログラムだ。
A.それはプログラムの仕事の多くが、「この規模ならこれくらい」という判断基準を持っていないか、そもそも予測不可能である部分が多いから、またはクライアントの誰もが、より短くより安く仕事を発注したいからである。この習慣を直すには、業界全体で合意を取るなんらかしらの判断基準が必要であるけど、そもそもそんな基準ができてしまったら、資本が弱い会社が不利になるに決まっているから、恐らく改められる事はないだろうね。

(2001/1/8)


Q.他人が組んだソースコードを引き継いだのだがなんとも読みにくい。どうすれば良いのか?
A.君が引き継いだソースコードがどれくらい、そしてどのように読みにくいのかは解らないが、君の組んだソースコードを他人が読んで同じ事を思われない自信があるか。自分のソースコードは自分が思っている以上に他人にとって常に読みにくいものだ。自分と同じ記述法を使っていたとしても、変数名、関数名、ラベルの付け方一つで読み手側の印象も随分変るものだ。

(2001/1/7)


Q.今度開発を始めた新しいプラットフォームのコンパイラがタコだ。どうすれば良いのか?
A.ついてないね。残念ながら確かにそういうコンパイラも存在する。しかしそういう問題の多くは、コンパイラのせいだけではなくそのプラットフォーム、主にハードウェアの複雑さから引き起こされている事が多い。素直にバージョンアップ(バグフィックス)を待つか、別のコンパイラを探すか、他に選択肢が無ければ諦めて使うしかないだろう。

(2001/1/6)


Q.今のプログラミングスタイルは自分の流派とは合わない。どうすれば良いのか?
A.プログラミングスタイルは対人関係と同じで、全てが必ずとも自分と合うわけではない。だから合わないのなら自分のスタイルに合うよう周囲にそうさせるようにするか、自分自身が合わせるかのどちらかしかない。もし自分の方が合わせたくないのであれば、自分がそういうスタイルを作れるような立場にまで昇りつめるか、そのプロジェクとを去るか、職場を去るしかないだろう。

(2001/1/5)


Q.他人が組んだソースコードにふざけたコメントが書いていた。これはいったいどういうつもりか?
A.それはきっと、そのプロジェクト自体が荒んでいてそういう事でもしないとやってられない状況だったか、そのソースを組んだプログラマ自体が人間的に荒んでいたかのどちらかである。君が、そのソースコードが後々にまで流用されると思う(つまり自分以外の他人が見る可能性がある)のなら、そして君にその余力があるのなら、そのふざけたコメントを正常なコメントに書き換えてあげよう。感謝される事は無いかもしれないが恨まれる事は無い筈だ。

(2001/1/4)


Q.どうしてプログラマの多くがループ変数を"i"とか"j"にするのか?
A.それは、FORTRANという言語の整数表現可能な変数が"i"と"j"と、他に2種類くらいしかなかったからであり、多くのプログラミング教本を書いた人間がその習慣をそのまま使って書いてしまい、それを見たプログラマ見習いがそのままその伝統を受け継いでしまったためと言われている。

(2001/1/3)


Q.どうしてプログラマ関係のニュースグループは冷たい反応が多いのか?
A.まず自分が質問した事がそのニュースグループのFAQリストに載っていなかったかどうか確かめる事。載っていなかったとしたら、自分の送った質問内容の文章をチェックする事。問題がそこまで単純じゃなかったとしたら、プログラマは多かれ少なかれ、自分が直面した問題を自分で解決している事をお忘れなく。プログラマとは案外、自分が苦労して解決した問題を安直に教えないものです。もし「自分だってかなり苦労したし調べもしたさ」と思っているのなら、その態度が文章に出ているのでしょう。そういう態度が文章から読み取る事ができれば、彼らは解答を出したがりません。プログラマと言う人種は、そういう意味ではわりと器の小さい人種です。勿論、例外の人もいますが。

(2001/1/2)


Q.何故プログラマは皆から「ブラインドタッチができる」と思われるのか?
A.それはきっと、それくらいできないとお仕事にならないからと思われているからである。だが実際、ブラインドタッチができなかったといって仕事の効率が落ちるかというと、そういう訳では無いんだけどね。

(2001/1/1)