Scribble at 2022-06-15 11:55:23 Last modified: 2022-06-15 16:19:06

先日から話題にしている、ハーベイ・ダイテルとポール・ダイテルの親子が書いた C の教科書だ。原著は何回か改訂を経て、今年（2022年）に第９版が出ているほど長年に渡ってよく売れている定番らしい。残念ながら日本では上記に紹介している第２版（しかも前半部の抜粋）の翻訳だけが出て、アマゾンのレビューでもわかるように読み物としては評価されていても、当時の学生や新人技術者に広く読まれたという印象がない。実際、C で仕事をしている技術者なら読めばすぐに分かると思うが、テキストとしての出来栄えは未成熟なところが多々あって、疑問の余地が多い記述も散見される。たとえば、インデントをスペース文字３個にしろとか、こんなのはいちいち書くことではない。敢えて書くなら、C で実装している業界の慣行や会社の指示に従うのが妥当だろう。

ここで余談としてインデントについて書いておくと、僕はコラボレーションがほとんどないため、当社の情報システムとシステム開発の統括部署を預かる者として、自分で決めたコーディング・スタイルを採用している（自分だけが実行して問題なければいいからだ）。インデントについては、僕はバイナリ・データとしてのサイズを考慮してタブ文字でインデントするスタイルを採用している。これはプログラマでも正確に理解していない人も多い点だが、ソース・コードを記述しているテキスト・ファイルというのは、簡単に言えば特殊なバイナリ・ファイルである。しばしばテキスト・ファイルとバイナリ・ファイルをストレージ上の異なる実体であるかのように錯覚している人もいるが、テキストだろうとコンパイルしたプログラムや動画ファイルだろうと、結局はファイル・システムというデータベース上で「ファイル」という機能をもつデータのまとまりである。テキスト・ファイルは、異なる OS でも共通に開いて扱える特別なビット列をもつバイナリ・ファイルのことであって、その特殊性を無視すればバイナリ・ファイルだ。"You are a deadhead!" という文字列（あるいはそれらの ASCII コード）がそのままファイルとして格納されているわけではない。そんなものはコンピュータに理解できない。ということで、そもそもインデントというのはヒトがソース・コードをエディタやターミナル・ソフトウェアなどで眺めるときに「読みやすい」かどうかという観点で採用していることであり、本来はプログラムの（パースのタイミングではなく）実行時の挙動と何の関係もない。よって、コンパイル時に削除される言語であればともかくとして、僕らが普段から扱っているインタープリタ型の言語では、処理系に送るソース・コードに無駄な文字が含まれていると、それだけ処理に時間を要する（「この文字を無視する」という処理だけでも一つの処理である）。無駄な文字（列）は少ないに越したことはない。すると、制御記号一つで一定の幅をインデントしてくれるタブ文字を使うことが望ましいというのが僕の意見だ。これをスペース文字として２文字だろうと４文字だろうと、タブ文字１つよりも多くなるのは確実であるから、無駄が多い。そして、その割に多くのテキスト・エディタではタブ文字によるインデントを実質的にスペース文字２個分とか４個分などとして扱って見せてくれるため、エディタの設定次第ではスペース文字が何個分であろうと、それに合わせた見栄えに後からでも調整できるという利点もある（その逆、つまりスペース文字２個分でタブ文字１個のように見せるなんて無理だし、そんな処理に意味はない。そもそも、そのタブ文字１個ぶんがどれほどの幅なのかを同時に定義しなくてはならず、その定義にスペース文字で何個分だと設定するなら、そういう変換にいったい何の意味があるのか）。

余談はともかく、ダイテル親子の本に戻ると、2016年に出た第８版を眺めたことがあり、そのときは上記の翻訳を読んだ時に感じたいくつかの疑問が殆ど解消されていて、なるほど長く読まれて改訂を続けてきているだけのことはあると感心したものだった。先日も書いたような、プロプロセッサ命令を省略した「動かないコード例」はなくなっているし、コードを先頭から順序を追って解説しているし（翻訳された第２版では main 文よりも後に include を解説している）、ただし第８版でもインデントはスペース文字３個を奨励しているが。

それから、テキストというものは読み始めが辛いと致命的であるから冒頭部だけを指摘しておくが、翻訳書の30ページでは幾つもの「よくあるプログラミングエラー」が列挙されてから、いきなり「多くのシステムでは、この種の実行時エラーを『セグメンテーション違反』あるいは『不正アクセス』と呼んでいます」と書いているのだが、「この種の実行時エラー」とは何のことだろうか。上に列挙されているエラーの一覧は、いわば注釈とか挿入されているコメントみたいなものなので、ここを本文でいきなり受けて文章を書くというのは不自然である（他の教科書でも、コラムのような別枠で囲まれている文章を読んだという前提で本文を繋げるような文章は構成としておかしい）。かといって、直前に書かれている内容（前のページの文章）は、「右大カッコ（｝）は関数mainの終わりを示します」という、エラーと関係のない記述だ。そして、2016年の原著と比べてみると、実は翻訳書では注釈扱いになっている参照にかかわるエラーの注釈が本文になっていた。原著だと一つの枠にすべて書いてあるから誤解はないが、翻訳書だと注釈について本文が注釈しているような奇妙なレイアウトになっているのだ。

事例としてはいくつも挙げる必要はないと思うが、このように原著では問題のない記述が翻訳書では（第２版の原著からしておかしかった可能性はあるが）非常に読み辛い。アマゾンのレビューにもあるとおり、ホビー的な雰囲気があって好ましい本ではあるけれど、教科書としては高く評価できない（最新の第８版を見ても、既に述べた通り疑問が残る）。