K & R の第 1 版て、は , return ( 式 ) ; default : break ; case constant—expression . switch (expression) { ・ switch 文の書き方 C{ ドの位置に注意 ) } while (expression) ・ do { •do wh ⅱ e 文の書き方 ( 、、 { ドの位置に注意 ) while (expression) れを同じ行に書かずに , 必ず次の行に書き が複文て、ない場合 , および空文のとき , そ for 文と同様 , 次のように , while 文の本体 while (expression) { ■ wh ⅱ e 文の書き方 ( 、、 { ドの位置に注意 ) 書いてはいけません。混乱の元になります。 に , 空文を意味するセミコロンを同じ行に に書かずに , 必ず次の行に書きます。とく い場合 , および空文のとき , それを同じ行 List 19 のように , for 文の本体が複文て、な ません。これは慣用句のようなものて、す。 にかぎり , 空白なして、詰めて書いてかまい は , 空白を開けますが , 無限ループの場合 for の中の式を区切るセミコロンの後に 注意 ) ー for 文の書き方 (List 18 , ドの位置に と , return の後のカッコはなくなってしまい しかし , 第 2 版になる 思うのてすが・・・ せん。かえってわかりにくくなるだけだと がわかりやすいのか , まったく理解てきま りますが , 私にはなぜカッコがあったほう ほうがわかりやすいから , というものがあ く耳にする理由としては , カッコがあった がついていたのか , よくわかりません。よ のように表記されていました。なぜカッコ break プログラミング言語 C 第 2 版 } else { } else if { Fig. 1 K & R 第 2 版 けて , 区別されているため , 簡単に識別て、 効範囲の内部は , 一段深くインデントをつ 囲になっている , という点にあります。有 、、ドまて、が , そのキーワードに対する有効範 ぐ下に向かって眺めたとき , 最初に現れた do, switch, (f) の先頭の文字から , まっす 書き方の基本は , キーワード (for, while, すて、に述べたように , これらのカッコの if (expression) { ■ if 文の書き方 (• { ドの位置に注意 ) て、しよう。 て , 目立つようにすると覚えておけばよい 書くときには , インデントをひとつ解除し は switch と case は同じ高さて、す。ラベルを h より少し後に書く人もいますが , K&R て、 これ以外の書き方としては ,case を switc す。 じ位置に揃えて書きます。 default も同様て、 す。 switch 文に対して , case ラベルを , 同 これが結構異論のあるところだと思いま ANSI 規格準拠 W 功—. ニハン / 0 リッチ - 著 物第第第幸物意 み参物 。 ~ 立出版株式会社、 ン第を 実際は , 左に空白を置きません。もっと も左から書き始めます。 関数の定義の場合 , 始まりのカッコ、、ドを 関数名の定義行に書かないのは , すて、に述 べたように , 関数の始まりを検索しやすく する効果を持っています。 また , 関数の型は , 関数名と同じ行に書 きます。こうしておくと , grep のようなツ ールて、関数名て、行単位の検索を実行したと き , 型がついたまま表示されて便利て、す。 ・変数定義部分と , それ以後の部分は , 空 白行によって分離する ( 2 ) 。 unsigned int f00 (int count) きます。 ・関数の定義の例 C{ ドの位置に注意 ) unsigned int f00 ( ) int total count > > = 1 ・ tot 引十十 ; while ((count & 1 ) return totaF char* Str , いけません。 上のように書きます。次のように書いては TAB て、揃えたりはしません。ポインタは , 型名の後に , 単に空白をひとっ空けます。 Char *str , FILE *fp ; ■変数の宣言の仕方の例。 〇 char keyword[10]; >< char keyword[10] ■式文を表す、、 ; ″の直前には空白を空けな 〇 arrayC10] X arrayu [ 10 ] ・配列の、、 [ ] 〃の前後には空白を空けない。

さらに悪いことには , これは私だけの意 見かもしれませんが , 入門をうたっている ものほど , いいかげんな内容が多いようて、 す。たとえば式と文の説明が混乱している 本があります。何も知らない人が , これを 読んて、 , 式とは何か理解しろというのは無 理な相談て、す。 そういう本に当たってしまった人は , 単 に運が悪かったのて、すから , よい本を読み 直せば C 使いになれる可能性は残っていま す。本当にくだらない理由て、はありますが , よい教科書 , 悪い教科書というのは , 実に 重要なポイントだといえるてしよう。 さて , 幸運にも内容がしつかりした入門 書や解説書に出会うことがて、きたならば , それて℃使いになれるかといいうと , そう甘 くはありません。先ほども述べたように これらの書籍には , 真の「わからない」人に は , わからないことがいくつも前提にされ ています。これを身につけているかどうか が , 勝敗の分れ目となります。 その「前提」を一言て、表現すると , 「よいプ ログラムを書きなさい」ということて、す。よ い文章と悪い文章があるように , よいプロ グラムと悪いプログラムがあるのてす。ま うまい絵と下手な絵があるように フ まいプログラムと下手なプログラムがある のてす。誰ても , 悪いプログラムよりは , よいプログラムを書こうと思うのが当たり 前てす。わざわざ悪いプログラムを書こう と努力する人はいません。 ところが , 各論として「こう書いたほうが いい」程度のことは , どの本にも多少は書い てあるのて、すが , 総合的に考えて , いった いどのようなプログラムがよいプログラム なのかを説明した本はあまりありません。 総合的な評価のためには , 非常に多くの 内容を検討する必要があります。個別に考 えれば , たとえば「変数名は内容のわかるよ うにつけよう」だとか , 「不必要なコメント は省きましよう」程度のことは , ほとんどの 本に書かれています。これは , 部分的に「よ いプログラム」を作るための条件としては , もっともなことて、す。 44 C MAGAZINE 1 2 4 しかし , 場合によっては , ある条件を満 たそうとすると , ほかの条件が成り立たな こともあります。となると , 部分的な考 い 慮だけて、はだめて , トータルバランスとい う新たな要素も検討しなければ , よいプロ グラムは書けないわけて、す。このバランス 感覚というものが , 実は非常に重要なポイ ントなのて、す。しかし , どうすればバラン スがよくなるのかは , ちょっと簡単にわか る間題て、はありません。 そして , 私がいちばん主張しておきたい のが「よいプログラムを書くためにはセンス が必要だ」ということて、す。これをよく考え てみてください 「よいプログラム」を書くためには , 今述 べたようなトータルバランスを判断する能 力が必要て、す。それは , ある意味て、は感性 の世界てす。感性というのは , 熟練によっ ても身につくことがあるて、しよう。しかし , 素質というか , あるいはセンスが大きく影 響することも認めざるを得ないて、しよう。 すなわち , 「よいプログラム」を書くには , その人とプログラミング , またはプログラ ミング言語との相性がよいことが , 必要不 可欠だということて、す。これは事実として 訒めるべきてす。 本稿をお読みになっている皆さんの中に は , おそらく , C 言語とはどのようなもの か , だいたいの知識をお持ちて、 , これから C 言語を学んて、マスターしようと意気込んて、 いる人や , あるいは今まて℃言語の入門書を 何冊か読んて、 , C コンパイラも買った。入門 書などを読んて、 , サンプルプログラムを真 似して , 感 HeIIoWorId ! 〃くらいは画面に表 示した経験がある人も数多くいらっしやる ことて、しよう。また , まだ何にも知らない 文字どおりビギナーもいらっしやるて、しよ フ。 とくに , 今まて、何となく C のプログラムら しきものは書けるようになったが , なかな か上達せずに , 行き詰まってしまった人。 その理由はわからないが , 今度こそはわか るかもしれないと思って期待している人も いらしやることて、しよう。 そこて , 今度こそうまくいくかもしれな いと思った皆さんには酷かもしれませんが , こて、とどめの一撃を受けてもよい時期に さしかかったのだと思ってください。人生 は短いものてす。ムダな時間を費やすこと のほうが , ずっとむごいことかもしれませ ん。そこて、 , ひとつ考え直してほしいのて す。もしかして , あなたはプログラム作成 には向いていないのて、はないて、しようか。 あるいは , C 言語には向いていないのて、はな いてしようか。今まて、頑張った成果がいま ひとっと実感している方は , 今それを疑っ てみるべきて、す。くどいようて、すが , あま りに誰も書かなかったが , ごく当たり前の 法則を書いておきましよう。 相性の悪い人がいくら頑張ってもよい C のプログラムを書くことは難しい もしかすると , 世間には「誰て、も C プログ ラムが書ける」という迷信が広まっているか もしれません。プログラムの入門書を買っ て読めば , 誰にて、もプログラムは書けるも のて、しようか。ある意味て、は書けるといえ るし , ある意味て、は書けないといえます。 たとえば , 誰かにペンを持たせて絵を描 いてみなさいといったとき , まったく何も 描けない人はほとんどいないはずて、す。と にかく絵を描くというのは , 誰にて、もて、き ることて、す。しかし , 同じ人に , 本の挿絵 に使いたいからイラストを描いてくれと頼 むと , ちょっと待ってくれといわれるかも しれない。「いや , 私は絵は駄目なものて、・・・・・・」 というわけて、す。絵が描けるというのと , 「うまい絵が描ける」というのは別の問題な のて、す。 同じように , 歌のうまい人と下手な人が いるし , ピアノがうまい人も下手な人もい ます。ヒ。アノといえば , 「猫ふんじゃっただ けは弾けるぞ」という人がたまにいるようて、 す。そういう人にピアノを弾いてくれと頼 むと , いや , 実は弾けないのだと断わられ るて、しよう。 、、 He Ⅱ oWorId ! クを画面に表示するという のは , ヒ。アノて、いえば猫ふんじゃったを弾

監 富 一口田 COMPUTER LANGAUGE Oct. 1991 ド血禮町咄 『 TechnicaI writing 』 うて、なければ雇わなかった ) 。規則的なレポ ための考察などて、ある。書くことは経験を 文章記述について ート提出や , ちょっと変わった文書を書く 積むことにより上達するが , 必ずしも楽に ことを強制すると , 彼らのほとんどが着実 はならない。努力なして、書けるようになる 私は物事を説明をするのが好きだ。これ にうまくなった。高校や大学て、もう数百時 人はほとんどいない 間作文の時間が多ければずいぶん違ってい については今て、はすっかり明白なことだろ 今の私の関心はもっと狭い範囲 , つまり う。過去 5 年間に本を 2 冊 , 業界誌にェッセ ただろうに ( 訳注 : これ以降て、指摘されて 技術文書のビジネスについてて、ある。これ イを 100 以上書いてきた。また奇妙なセミナ いる「教育」や「学校て教えられること」 は技術教育を受けた人間なら , 誰ても十分 ーを行うことて、も有名になった。 は , すべて米国内て、のものて、ある。またこ に実現て、きるはずの様式化された分野てあ 幸運なことに , 数年前から私が技術的に のコラム自体が英語て、文章を書くことにつ る。あるいは少なくともそうあるべきだ。 情熱を持つ対象に人気が集まってきた。私 いてのものて、ある。そのため日本あるいは , こて、はヒ。ュリツアー賞の資質を論じよう 日本語の事情には必ずしも当てはまらない としているのて、はない。技術的な話題を単 の好きなトヒ。ックについて話をする機会が 与えられるだけて、なく , 結構な支払いも受 ところもあることに , 注意してほしい ) 。 純明快に表現するのに必要な , 簡潔な記述 けている。その結果さらに書いたり , 発言 書くのが簡単だというつもりはない。私 について話をしようとしているのだ。 することが増える。同じことの繰り返しを の場合 , 、、書き上げたクという感触が好きな このような形式て、の読み書き能力の向上 避けるために , ときどき新たな事実を取り に対して , 実は個人的な利害からの興味が のて、ライターになったのだ。学校を出てか あげてポイントを稼ぐこともある。 ら数百万語も記述してきたが , それて、もと あることも告白しておこう。つまり私がい ろいろな雑誌て、年間 100 本以上の記事を編集 必ずしもすべての技術者が説明好きなわ きどき書くのがつらいこともある。ときに けて、はない と私は考えている。私が知っ はトピックに、、はまった〃 こともある。数 していることに関連しているのだ。これら 時間をかけて数千語を書いた後てランチを ているプログラマの中には , 朝の 3 時に 250 の記事を書いている技術者が同じようなミ 食べ忘れたのに気づいた。いって、もこんな K バイトのコアイメージに果敢に挑戦する連 スを繰り返さないて、くれれば助かるのだ」 に情熱的てあればすばらしいが , 滅多にあ 中や , 間欠的に発生するバグて、もへキサ電 同僚の編集者や私にとっては , 破格な語や 卓 ( 訳注 : 16 進数を計算するための電卓 ) ることてはない。書くことは , 少なくとも 構文が使用される頻度が減少するだけて、も 私にとっては , 石炭掘りよりも楽だが , 朝 と一杯のコーヒーだけて、 , ひるまずに追跡 うれしいことだ。 する連中もいる。そんなプログラマても , 飯前て、はない また私も皆さんと同様にソフトウェアや モジュールの動作を説明するパラグラフを この工ッセイは米国の教育の現状に対す テキストを購入し , それらの不明瞭な部分 を明確にするため , 分詞のかかり方を変え ふたっ書けといわれたとたん青ざめる。 る不満になってしまうかもしれない。この これは実践の問題て、もある。これまて長 現状は改善可能だし , そうすべきだと信じ ' とに私がとく てみたりする。 フいった , るのに十分な理由もある。しかし誰もが楽 に優れているわけては , 決してない 年にわたり私が雇ったことのある技術者や に文章を書ける訓練がてきるとは思えない にマシンのパワーオフ前の 3 時間分もの仕 非技術者の多くが文と文をうまく連結てき 教育てきることは , 文法 , 規則そして批判の なかった。ても彼らは優秀な人間だった ( そ 事をセープする方法を見つけようとすると Programmi ng on Purpose 17

ile のカッコの中は , 次のように読めるて、し 「まず , c に getchar でもらった値を代入し てだな , それが EOF でなければループの中 の処理をする」 秀逸なのは , 「それが」のところて、す。 C 言 語においては式も値を持っていることを利 用した芸当て、す。て、すから , 厳密には , c と EOF を比較しているというのは正しくない のて、すが , あえてそのように思い込んて、い るとしても , この例て、はあまり差し支えは ないて、しよう。 て、は , これをカッコを外して書くには , どうすればいいて、しようか。 getchar( ) ! = EOF) { while (c これは無茶て、す。代入演算子の優先順位 より , 比較の演算子のほうが高いのて、 , ge tchar の値は先に EOF との比較に使われてし まい , 比較して同じだったかどうかという 結果の値 , すなわち 0 か 1 が c に代入されてし まいます。 while (c = getchar( ) , c ! = EOF) { 処理としては間違ってはいません。しか し , 問題はふたつあります。まず , while を 見てから , その条件の判断部分に到達する まてに , c getchar ( ) という余計な処理 がひとつ入ったことて、す。 while からこれが 遠くなればなるほど , いま何の条件を考え ていたのか忘れてしまうてしよう。もっと おもしろくないのは , せつかく c getch ar( ) という式が値を持っているのに , それ をまったく利用していないことて、す。 て、は , while のループの中に , 処理を入れ てしまうというのはどうてしようか ? break ; EOF) C getchar( ) ; while ( 1 ) { 今度は , 確かにカッコの数は減りました。 しかし , これて、は単なる無限ループを作っ て , 中から強制的に飛び出すことになって しまいますから , 今度は while を使う必然性 が弱まってしまいます。 結局 , この場合においては , 最初の書き 方に比べてあまりうまい方法はなさそうて、 す。というより , 最初の書き方がうますぎ る , といってもよいてしよう。実際 , この 書き方は , C 使いになるには , 必ずマスター しておかねばならない表現のひとつだとい っていいてしよう。 そうすると , 今度は , List 4 のような書き 方に対して , むしろ違和感がなくなり , 理 解しやすいといった現象も現れるのて、はな いて、しようか。 getchar の記法は , まさに w hile の書き方と同種だからてす。 思の順序を妨げない、 さて , あなたがもし相当腕利きの C 使いな ら , 何を当たり前のことをいうのだと思っ ているかもしれません。まだまだ甘いな , と思っている人もいるかもしれません。ま た , 初心者の方なら , いったいどう書けば 奥義をこっそり書いておきま 思います。そこて , どっちがいいんだ , と と多少イライラしてきた頃だと 特集 C プログラミンの秘 みれば , 思考が妨げられないという意味が , なんとなくわかるのて、はないて、しようか。 fopen (filename, "r") ・ ! = NULL) { if の判断の中に fopen を入れるよりは , 思 考の順序の点て、は明らかに勝っています。 if (fp なせ左辺に 定数を書がないが ~ = よく迷う , ある判断に決着をつけることが 前述の奧義を指針とすれば , もうひとつ て、きます。 while (EOF ! = = getchar( ) ) ) { いいのだ , 迷った方へ す。 この奥義を基本に , 先ほどの例を考えて もちろんそちらを優先すべきてしよう。 俺のほうがいいぞという自信があるなら , もし , 自分なりの意見をすてに持っていて , とはいえ , あくまてこれは流儀てすから , ことになるのてす。 かを , 体験的に身につけて , 初めて理解し せん。どう書けば思考の順序を妨げないの わかったつもりてもまったく意味がありま のようなものてすから , 読んて、頭て考えて たったこれだけのことてす。これは秘伝 ムを書こう 思考の順序を妨げないようにプログラ このような書き方を見た経験のある方は 多いと思います ofopen の例だと List 5 のよ の左側に持ってくることて、す。 特徴は , 定数を二項演算子 , ここては当 = ク うになります。 なぜこのよ うにするかというと , 次の例を見てくださ if (i if (i もしれません。 し , うつかりして , 次のように間違えるか 実行するというごく単純なものてす。しか この処理は , i が一 1 の場合にカッコの中を 特集 C プログラミングの秘訣 49 あります。この種のバグは , 気がつかない というあたりて初めてバグに気づくことも とてす。実行してみて , 何か動作が変だ , ため , コンパイルが正常終了してしまうこ もかかわらず , いずれも文法的には正しい の特徴は , 処理の内容はまったく異なるに いをした経験があるはずてす。この間違い い」というャッて , 誰ても必ずこの種の間違 これが C 言語て有名な , 「 = = と = の間違

ベストと考えて実行していることて、す。取 り敢えず , フィンローダ流とて、もいってお きます。すて、に述べたように , プログラム を総合的に評価するには感性に大きく依存 するというのが私の主張てす。したがって , フィンローダ流という流儀は , 私の感性に 依存し冫 : 評価て、あって , 別の人からみれば , 全然よ、ないと感じるようなことが含まれ ている力もしれません。 そこて、 , これはあくまて、ひとつの流儀て、 あって , 決して唯一正しい解釈て、あるとい うことてはないことを前提にしてください ほかの解釈のほうが合理的て、あると考える 人は大勢いるはずて、す。 もうひとつは , 私自身 , 今後ずっと本稿 が正しいと考えるかどうかは , 保証しかね るということて、す。プログラミングにおい て , これが最善と断言するのは , なかなか 難しいものて、す。たかがひとりがプログラ ムを書いて身につけたことを述べるのて、す から , これからさらに経験を積むことによ ほかの方法がよいと思い直したり , 考 え方が変わることは十分考えられます。 日々是修行て、す。私が保証て、きるのは , Part2 以降は , 現時点て、私が最善だと思い込 んて、いるにすぎないという点て、す したがって , これから述べることに対し て , 何か反論のある方もいると思いますが , 反論のほうに分があると思えば , 私はころ ころと自説を変えると思います。私の持っ P A R 9 ている一貫性は , そのとき正しいと思った 判断に従うということて、す。一度いったら あくまて、覆してはならない , といった考え は , まるて、持っていません。結構無責任と いえば無責任な話て、すが・・・ そこて、 , 次のことを強くおすすめします。 これから書くことは , あくまてあなたがど うすればよいか , あなた自身て考えるため の参考にとどめてください。書いてあるこ とを鵜呑みにしないて、 , 自分自身て、考えて , それに従って判断してください。既存の流 儀を越えた , 自己流をあみ出す意気込みが あれば完璧て、す。考えるということは重要 て、す。考える習慣をつけることが , よいプ ログラムを作る近道て、もあります。 明解プログラミンクのすすめ ムと , 一見して判読しやすいプログラムとでは大き 保守管理には , 動作さえすれはいい難解なプログラ も明解なプログラムを生む秘訣ではないでしようか。 思考の流れを妨げないプログラミング。これか誰に な差がつくものです。 なせ 3 わかりやすく 書くべきなのか 46 C MAGAZINE 1992 4 どうせ自分は趣味のプログラマだから , ほ りやすく書こう」といわれます。なかには , 一般論としても , よく「プログラムはわか が多いようて、す。 まず不可能に近いような神業に感じること ログラムをわかりやすく書くということは , し , 実際に書いてみればわかりますが , プ をわかりやすく書く , これだけて、す。しか は , ただ一点に集約て、きます。プログラム フィンローダ流のプログラム書法の核心 かの人が読みやすいように努力してもしょ うがない , と勝手に思い込んて、いる人もい るようて、すが , とんて、もない話て、す。わか りやすく書こうというのは , もちろん , 自 分にわかりやすくするために書くのて、す。 ある程度の規模のプログラムを作ったこ とのある人なら誰て、も , 次のことを経験し ているて、しよう。 「プログラミングに集中しているときは一 時的に脳の力が高まり , 普段以上の精神 活動を行うことができる」 しかし , 恐るべきことに この能力は時 間が経過すると通常の状態に戻っていきま す。その速度は , 脳の力が高まる度合に比 例します ( 1 ) 。その結果として , 自分が書い たものなのに , 見たこともない文字の羅列 となり , 解釈すらて、きないことがよくある のてす。したがって , わかりやすくプログ ラムを書く心構えは , まず他人たる自分の ためにそうする必然性があることを , 十分 理解しなければなりません。 しかし , はっきりいって , わかりやすい か , わかりにくいかは , 主観に大きく依存 する問題て、す。これが絶対真理だ , という 法則はなかなか見つかりません。 しかし , 大雑把な範囲て、 , 「こうすればわ かりやすいと感じる人が多いのて、はないか」 という程度の判断は , 多くの人が感覚的に

特集 C プログラミ これは 2 行に分ける必要がある の秘 GNU 流を 自己流の参考にする 最近は , パソコン通信に参加したり , 雑 誌の付録ディスクを手に入れることによっ て , C て、書かれた多くのフリーソフトウェア のソースが簡単に入手て、きるようになりま これらの多くは , 前述の規則とはまった く異なった , 独自の表現によって書かれて います。 このようなソースを単に読むのは退屈な 作業かもしれませんが , インデントなどを 自分のスタイルに直しながら読むと , 理解 が容易になります。 このような手作業を行うには , ソースプ ログラムをくまなく読まなければならない からて、す。 GNU 版の indent というツールを持ってい れば , -kr というオプションを指定すること により , 一気に K&R 風のインデントにする ことがてきます。 しかし , 大急ぎて、読む必要がある場合て、 なければ , 手作業て、インデントをつけ換え たほうが , 本当にプログラムを読むことに なり , プログラム理解の度合を高めるには 効果的て、す。 C に慣れた人ほど , 自己流の書き方が身に ついていて , また , 自己流のスタイルにそ れなりの理由を持っていることが多いよう て、す。 初心者の皆さんは , このような熟練者か こはこのように書いたほうがよい」 といわれることがあるかもしれません。 の場合 , 「て、も , K & R もこのスタイルて、書い てありますから」といえば , ほとんどの人は それ以上議論するのは分が悪くなりそうだ と判断し , 諦めてくれるようて、す。 もっとも , 相手カ℃の熟練者て、はなく , 何々 入門といった本しか読んだことがなく , K& R が何なのか理解していない場合には , この かぎりてはありませんが・・・ ist 20 if ((fp = fopen(filename, GNLJ コーデイングスタイル 場合は , それが複数行にまたがってはい ・ひとつの宣言文で複数の変数を宣言する タイプするのが普通です。 の終わりのピリオドの後はスペース 2 個を を入れます。なお , 英文タイプでは , 文 ・コメント文の終わりには , ふたつの空白 にカッコを書きます。 すなわち , 外側の処理と内側の処理の間 ・カッコ感 { ドの位置は , スタイル②です。 行の先頭に演算子が現れるようにします。 の直前で区切ります。すなわち , 新しい ・式を複数行に分けて書く場合は , 演算子 も , 空白を置きます。 ・関数名の後に現れる開きカッコヾ ( ″の前 紹介します。 箇所や , 特徴的な箇所のみをかいつまんて、 ーディングスタイルととくに異なっている , こて、は , 今回述べたフィンローダ流コ ュメントを参考にしてください 参考文献 , または GNU が配布しているドキ GNU のコーディングスタイルについては イルが考えられていることて、す。 ムを作成する場合に便利となるようにスタ ル , とくに GNU Emacs を使ってプログラ GNU のスタイルの特色は , GNU のツー ません。 これを指針にするのも悪い選択て、はあり います。 GNU として推奨するスタイルが公開されて さすがに問題があると考えたのて、しようか , のソースがてんてばらばらの書き方だと , 大成として発展しつつありますが , これら GNU は大勢の人によるソフトウェアの集 GNU のスタイルというものがあります。 もうひとつのメジャーな書き方として , けません。 int f00 , bar 特集 C プログラミングの秘訣 63 に空白行があります。 0 ; の行の次 ( 2 ) この例ては , int total すべきことかもしれない 理由だと思われる。本当は端末側て処理 目に会うことがあるというのがひとつの 文字列が入った発言に出くわしてひどい たとえば , 希とはいえ , 変なエスケープ コントロール文字を無視する理由は , やってられない しいという意味。 CR や LF が無視されたら ちろん , タブも CR や LF と同様に扱ってほ すがにこの提案のほうが無視された。も 視すべきだと提案したことがあるが , さ ル文字として無視するのなら CR も LF も無 (I) かなり昔の話だが , タブをコントロー [ 注 ] ません。 の頭を大文字にする方法は使ってはいけ ″を使う方法が採用されています。単語 ・また , 名前のつけ方は , アンダースコア に分ける必要があります。 き方は , もはや好みの問題ではなく , 2 行 ません。したがって , List 20 のような書 ・ if 文の条件式の中に代入文を入れてはいけ 「山田太郎」と書くようなものです ) 。 名です。たとえば葉書の宛名書きの例に ば説明のために使われる意味のない変数 ソートしておきます ( f00 , bar は , しばし 変数の宣言部分は , アルファベット順に と書きます。なお , フィンローダ流では , int bar ; int f00 収めるか , 上記のように書いてはいけません。 1 行に

特集℃プログラ 1 クの秘 フィンローダ流の根拠て、す。 思考に無理があると , その部分の理解だ けて、はなく , ムダなエネルギーを使うこと になり , 全体の理解の妨げにもなります。 その結果 , バグを誘発するという結果は , 十分考えられることて、す。小手先の技に溺 れて , 全体をわかりにくくしては , あまり にムダだということて、す。 しかし , 左辺に定数を書いたら , 先ほど 指摘したような = = を = と書いてしまう間 違いは防げるのて、はないかという , この点 にあくまて、固執する流儀もあります。 あくまて、その間違いが怖いと思うなら , 何も私の意見に従う必要はありません。自 分の判断を尊重してください。早い話が , この程度のことは , どっちかにしないとプ ログラムに無茶苦茶差がて、る , といったも のて、はありません。 ただ , 私自身は両者比較した上て、 , 定数 は左辺に書かないと決めたのて、す。また , それて、大丈夫というのは , 実は頭て、想像し ただけて、はなく , 経験的に時間をかけてそ う判断したのて、す。て、すから , 左辺に書か ないて、も大丈夫という理由も一応書いてお きましよう。 まず , 私が普段使っている C コンパイラは BORLAND C 十十て、す。このコンパイラ は , 条件判断に代入式が現れたときは , 警 告を表示してくれます。したがって , その 特集 c プログラミングの秘訣 51 気がないのに , うつかり , と書くつもりのところを , lint という武器もあります ( 7 ) 。 して , 万一その機能がない場合てあっても , ンパイラがこの警告を出してくれます。そ ションを指定したりすれば , ほとんどのコ は結構気を遣ってくれているようて , オプ あるかもしれませんが , 最近のコンパイラ このような警告を出さないコンパイラも て、きます。 してしまったことは明確に判断することが そ正常に終了しますが , そのような記述を と書いてしまったとしても , コンパイルこ ほかにも理由はあります。実は , このよ うな間違いは , C プログラムに慣れればほと んどしなくなります。慣れないうちは , 確 かに「 = 」と「 = = 」とをうつかり間違えるこ とがままあります。 しかし , これにはすぐに慣れ , 慣れるに したがい , それよりもほかのバグのほうが 圧倒的に多くなってきます。ならば , ほか のバグの原因となる , 思考の妨害因子を少 して、も減らしたほうが能率的だと判断する のが理にかなっています。 今書いたように この間違いは慣れれば ほとんどしなくなりますが , それて、もまっ たくしなくなる , というわけて、はありませ ん。私が最後にこの間違いをしたのは , 確 か数年も前のことて、 , なんとこのバグを取 るのにほとんど 1 日かかってしまいました。 それみろ , いわんこっちゃない , 定数を左 に書いておけば 1 日もムダに過ごさずにすん だのて、はないか ? 残念ながら , それはふたつの意味て、外れ て、す。まず , 仮に定数を左に書く癖をつけ ておけばその 1 日を失わずにすんだかもしれ ませんが , 読みにくくなったリストが影響 して , 別の作業に時間を取られたて、しよう。 どちらがリスクが大きいのか , 想像に頼る しか判断しようがないのて、すが , 私の想像 としては , 左辺に定数を書いて気味悪く感 じていたほうが , 結果はよくなかったよう な気がします。 そして , もうひとつの外れは何かという と , 私が比較と代入を間違えたこのときは , 左辺も右辺も , 両方ともに変数だったのて、 す。つまり , 左右ともに変数の場合には , どう書いてもコンパイルは正常に終了して しまうのて、す。左辺に定数を書く流儀の皆 さんは , くれぐれもその保険を過信しない ことて、す。 わかりやすいプログラムに必要な条件を 大雑把にふたつに分類すると , 次の 2 点に集 わかりやすい プログラムの牛 約されます。 ・構造がきれいなこと ・書き方がきれいなこと 文章を書くことにたとえると , 前者は読 みやすい文章に相当し , 後者はきれいな字 に相当すると思えばよいて、しよう。内容と 字面との差て、す。ただし , このふたつは完 全に独立しているわけて、もなく , 書き方が きれいだと , 構造をきれいにするのも容易 だし , 逆に構造がきたなかったりすると , どうしても書き方もきれいにならない と いった相関があるようて、す。 プログラムの構造というのは , 処理の流 れ , アルゴリズムなどをどのように扱うか がポイントとなります。したがって , きれ いな構造を達成するには , まずアルゴリズ ムから勉強すればよろしい。そのための本 こて、はとくに はたくさんありますから , 触れませんが , プログラムを書く前提とし て , きれいなアルゴリズムを扱える能力が 非常に重要て、あることは頭に入れておいて ください 書き方というのは , 大雑把にいうならイ ンデントがきれいにて、きるかとか , 合理的 な変数名がついているか , というような点 が問題となります。これらは , 後て、少し詳 ファイ丿分割 関数作りのコツ しく紹介します。 を修正したとき , 該当するファイルだけを ることにもなっています。つまり , 一部分 これは , 分割コンパイルの可能性を高め うがいいとされています。 よりは , いくっかのファイルに分割したほ なひとつのファイルに全関数を押し込める 度以上の長さになってくると , 非常に大き C 言語て、は , ソースプログラムが , ある程 て済むのてす。 再コンパイルすればよいのて、 , 労力が軽く

2 実例に学ぶインテントと空白 書式は本当に自由なのか SECTION だといえるわけて、す。しかし , コンパイラ トのスタイルによって実行結果が異なると いうことは , C 言語にはない」と考えてかま はそのような認識能力を持っていません。 単に文字の出現した順序だけを見て解釈し いません。つまり , 自分の好みによって , ます。その結果 , 期待した動作と現実が食 いいと思うように勝手にやっていいと ( 、フ い違うことになります。 ことてす。 C のプログラムを書くとき , まずとまどう よくある誤りのひとつは , 以下のリスト ところが , パソコン通信て、たまに見かけ のは , どのような書式て、書いてよいかわか のようなものて、す。 るのて、すが , あまり C に馴れていないと思わ らないということて、しよう。 ; ) 」など 0 ; i く 10 : i 十十 ) ; れる人が , 「動かないのて、すが ( ; C 言語においては , 特別な場合を除いて , for (i printf ("%d*n", i) ・ 文法という観点からは , あまりこだわらず と泣きついてきて , 最後の手段 , 恥をしの おそらく , この処理を書いた人は , 0 から んて、ソースリストをそのまま掲示してしま に自由な書き方がて、きます。たとえば 1 行に 9 まて、の数字を表示したかったのて、すが , 余 う , というのがあります。世間には信じら いくつも文を書いてもかまわないし , ひと 計な所にセミコロンがあるために , コンノヾ れないかもしれませんが , パソコン通信を つの文を 2 行に分けて書いてもかまいませ イラは次のように解釈します。 している人の中には , 結構親切な人もいて , ん。 0 ; i く 10 ; i 十十 ) for (i また , 世話をやきたくてしようがない人が しかし , 実際に C のプログラムを見ると , いるものなのて、 , しかもその人たちが相当 ほとんどのものがインデントを行っている ことに気づきます。インデントというのは , プログラムの知識があったりして , 添削を printf ("%d*n", i) ・ この場合 , for によって繰り返し処理され してくれることもあります。パソコン通信 プログラムの内容を書くときに , 左に空白 るのは , ; という空文て、あって , printf て、は には , そういった使い方があることを覚え を置いて見やすくする , アレのことて、す。 ありません。したがって , 結果は 10 という ておいても損はしません。 昔なっかしの BASIC のプログラムなどは , 値を一度だけ表示しておしまい , という多 それはいいのて、すが , このとき「ひどいイ いちばん左には行番号があり , それにつづ 分予期したものとは異なる結果になってし ンデントて、すね , これて、は動かないのも当 けてすべての行がおおむね同じ位置から始 たり前だ」といわれてしまうことがありま まいます。 まっていました。別に空白を置いてはいけ と説明して , なるほど , そうて、あったか , ないというわけてはなかったのて、すが , 当 す。 と理解したのなら , 多分あなたが人間て、あ 単純に考えると , インデントがどうなっ 時は , メモリが足りなくなるだとか , したほうが実行速度が速いだとか , 結構空 ていようが動くプログラムは動くはずなの る証拠て、す。もしあなたがコンパイラだっ たら , 最初のリストも次のリストも , なん て、すが , それは理屈の上だけの話て、す。経 しい理由て , 実に見にくいマルチステート 験的には , インデントをちゃんと書ける人 にも違わないじゃないか , と首をかしげる メント形式の記述が行われていました。同 はずて、すから。 と , C が使いこなせる人との間には相関関係 じような非本質的な理由て、 , わざわざ 1 文字 空白の使い方ひとって、 , プログラムのわ があるようてす。というよりは , きちんと の変数名を使ったりもしました。 かりやすさに極端な差が出るのて、すが , イ した構造を持ったプログラムを構成する能 最近は , BASIC といっても , コンパイラ ンデントについて , あまり重視する人がい になっていたり , 構造化て、きたりし , メモ 力のある人なら , 自ずからインデントもき ないのは不思議なことて、す。うまくインデ ちんとて、きる , というのが本当のところて、 リはどっさりあることだし , 当時の名残り ントをつけるということは , 実は極めて重 もないかもしれません。最近の BASIC を使 しよう。 要な技術て、あることを認識してください ったことがないのて、 , 詳しくは知りません 実際 , あまりひどいインデントのプログ ラムは , 階層化された構造を見誤る原因に なるのて、 , 結局 , バグの原因にもなるのて、 ということて、 , インデントのスタイルに す。人間がプログラムを読むときには , 空 ついては , 取り敢えず見よう見まねて、始め る人が多いようて、す。私もそうてした。ま 間的な位置関係から意味を解釈しようとし ず , それて、一向にかまわないことを頭に入 ます。これは視覚的なパターン認識能力の おかげて、 , これを活用したのがインデント れておいてください。基本的に , 「インデン 56 C MAGAZINE 1 2 4 力、コ位置 は処 みて 深っ 理 の うつ を 段 ンき

特集℃プログラライ ? の秘 もしくは , 後て、見てすぐにわからなくて アスタリスクを書いておけば , 検索した 必要なメントを も , 多少読めばわかるだろうと安易に考え とき , 表示された行がコメントなのかどう なせ書けないのカ、 てしまうこともあります。コメントを書く 一目て、わかります。 手間よりも , 読む手間のほうが多少少ない プログラムの先頭に書くコメントには , 必要なコメントだとわかっていたら , い と判断するのて、す。これは正解て、あること 自分の名前や日付は入れておいたほうがい われるまて、もなく , コメントに書くのては もありますが , 大失敗することもあります。 いて、しよう。 PDS にするつもりがないな ないて、しようか。にもかかわらず , ほかにも理由はありそうて、すが , このふ ら , Copyright の表示も書いておいたほうが コメン トに書かないというのはなぜて、しょ - たつが非常にありがちだと思います。コメ いいて、しよう。 フ。 ントを書くのがめんどうというのは認識を ファイルそのものが作成・変更時刻を持 ①コメントを書くのかめんどうだから 新たにしてもらう , としかいいようがあり っているからいらないように思うかもしれ 場合によっては , コメントを書くのに本 ません。これに対し , 必要なコメントて、あ ませんが , ファイルの時刻というのは , う 当にめんどうな環境もあります。たとえば , るかどうかわからない っかり編集してしまうこともあり , 結構あ というのは初心者 コンパイルしようとしたら , メモリが足り の場合どうしようもないのて、 , 先ほど書い てにならないものて、す。 ませんと表示されて , コンパイルて、きなか たように , どんどんコメントにしてしまう switch 文において , ある case が何か処理 った。仕方ないのて、コンパイルするために というのもひとつの方法て、すが , ある程度 を行った上て、プレークしないて、 , 次の case 仮名漢字変換のプログラムを追い出してメ はパターンというものもあるのて、 , それを の処理に合流させたい場合には , 必ず意図 モリを空けた。コンパイルはて、きるように 目安にしてコメントする習慣を身につける 的にそうしたのて、あることをコメントに残 なったが , 今度はプログラムの中に日本語 という手もあります。 しておくべきて、す。この場合 , て、コメントが書けなくなってしまった , ・関数を定義する場合には , それが何をす と / * 次の case へつづく * / いう経験があります。もちろん , 真面目に る関数で , どのような場合にどんな値を または英語て、 , 環境を整備したら , もう少しマシになるの 戻すのかを書く。 / * fall intO next case * / て、しようが。そして , このような場合て、も , ・変数に対するコメントは , その値がどの のように書くのが慣例て、す。つづく処理が 破綻した英語て、もローマ字て、もいいから , ような場合に , どういう意味を持ってい case て、はなく default の場合には , 本当に必要なコメントなら書いておくべき るのかを書く。 / * fallinto default * / て、す。あとて、 , ローマ字て、書いてあるコメ ・繰り返し処理 ( for , wh ⅱ e など ) に対して と書きます。 ントを普通の日本語の文章に置き換えるの は , どのような条件で繰り返すか , また switch (c) { と , 何も書いてないプログラムに , 何をコ は繰り返しを終了するのかを書く。 case y' ・条件判断 ( if , switch など ) に対しては , ど メントしたかったのか , あとて、思い出しな case ' Y' がら書くのと , どっちが楽かいうまて、もな のような条件のとき処理が実行されるか いことて、す。思い出す手間をかけてコメン を書く。 トを書くのは , 書かないほうがマシと感じ るほどめんどうなものて、す。 コメントスタイル余話 のように , case の処理がなく , かっ連続し ②必要なコメントであることかわからない ている場合には , このようなコメントは必 実はこれが問題なのて、す。いい換えれば , 関数の前に書くような , 比較的大きなコ 要ありません。 メントは , 各種の流儀があるようて、す。コ そこにコメントしておく必要があるという ・コメントの / * と * / は , 対応するように 判断がてきないのて、す。または必要と思わ メントのスタイルも , 千差万別といえます。 書き , ネストしないようにするのがよい なかった , したがって , コメントにしなか 私の場合は , 次のようなスタイルて、すが , でしよう。つまり , 次のように書かない ということて、す。そのとき頭に入っ これは結構よく見かけるものて、す。 った , ほうがよいでしよう。 このように , 1 行目から平気で ているが , 後て、わからなくなるかもしれな * 文章を書き始め , 必ず左側に ことがあれば , コメントに書くのが望ま * アスタリスク ( * ) が現れる しいことてす。しかし , 「これは将来忘れる かもしれない」ということは , それを覚え * ようにします。 ・コメントを書き始める位置は , インデン ている間は , なかなか気づきません。 トにあわせるのがよいでしよう。 特集 C プログラミングの秘訣 55 printf("Yes*N") ; break ,

epointer だから , fp て、す。ただし , しばし ばファイルを扱うプログラムを書く場合に は , ふたつ以上のファイルを扱いたくなり ますから , fp だけを使っていては混乱するか もしれません。 fp in, fp out のような書き 方はよく見かけます。 int fd ; ファイルディスクリプタの意味て、しよう。 int * p , 使い捨てのポインタとして pointer を連想 させる p を使います。これがたとえば long へ のポインタだと , lp となることが多いようて す。 Size t Size , 文字どおりサイズて、す。何のサイズかと いうと , おもに malloc のようにメモリを獲 得する関数への引数として使われますが , それ以外の用途にもよく使われるようてす。 int status , ステータス , すなわち状態て、すが , 何の 状態かというと , しばしば関数の戻す値 , もしくは exit の引数として使われます。 int temp , 次に問題になるのは , て、は , 自分が勝手 述べました。 のように使うのがよい」という方針に関して 自分勝手に使わないほうがよい」 , または「こ というわけて , 今まて、 , 「こういう名前は 印象的に登場するこど あるのて , 参考にするとよいと思います。 と , 引数の説明として使われている名前が このほかに , C の関数マニュアルを見る て , しばしば用いられます。 ムの中て、はなく , 説明のための関数名とし これらの名前は , 実際のソースプログラ intfoo(), bar() ; これは明らかに一時変数て、しよう。 66 C MAGAZINE 1992 4 単て、すが , 「 ~ するのがよい」というのは説 一般に「 ~ してはいけない」というのは簡 るのか , ということて、す。 に定義したい名前について , 何か指針があ 明困難になりがちて、す。あえて , どのよう な名前をつけるべきかという指針について 考えてみたいと思います。 言て、説明すれば , 「わかりやすい名前を つける」が大原則て、す。これだけて、も本質的 に理解していれば , あとは感性に正直に名 前をつけても , 相当変な人て、ないかぎり , 何も問題になりません。ただ , 驚いた に , わかりやすい名前にしようとさえ夢に も思わない人が結構いるように思えるのて、 すが。もうひとつは驚くには値しません。 どうすればわかりやすい名前になるのか , 理解て、きない場合て、す。 て、は , いったいどのような名前をつける とわかりやすいのて、しようか ? これは , 経験を積むに従って , 自然に身についてく るものだと思います。 まず考えておきたいのは , その名前を見 ただけて、 , 働きが一目瞭然て、あることて、す。 xc という名前が何を意味するのか , わかる 人はほとんどいないて、しよう。これが , tra nsfer count という名前だったら , 「何か転送 するとき回数が入っているのだな」程度は想 像て、きるのて、す。よくいわれることて、すが , こて、重要なのは , その意味を的確に表現 する名前を用いるということて、す。これは もっともなことてあり , 探せば多くの本に 書いてあるはずて、す。 フィンローダ流に関しては , もうひとつ 重要なことて、 , かっ , ほかの本にはあまり 書かれていないことがあります。それは , 「印象的な名前をつける」ということて、す。 ばっと一目て、気に入ってしまうような名前 がついたら成功て、す。なぜそれが本に書か れていないかというと , じゃあどうすれば 印象的な名前がつけられるんだ , といわれ たとき , そんなことは言葉て、説明がて、きな いからて、す。 名前き方 現状て、は , 日本語の名前が使える C コンパ イラは , あまり見かけないし , ANSI の規格 どおりなら , 当然日本語の変数名など考慮 されているわけがないから , いわゆるメジ ャーなコンパイラについては , 英数のみ使 えると考えておきます。 まず , 英単語を名前に使うとして , 省略 するか , 省略しないかという選択がありま す。例を見るのが手つ取り早いて、しよう。 char * file name ; / * 省略しない * / char *fn / * 省略する * / 省略しないメリットは , 意味を誤解する 確率が小さくなることて、す。 fn と書くと関数 名のことかと誤解するかもしれませんが , file name を見て関数名かと思う人はまずい ませんし , これを見た人は必ずファイル名 て、あることを理解て、きます。 て、は , 省略するメリットは何て、しようか。 ひとつは , あまりにもしばしば使われる変 数に長い名前をつけてしまうと , 入力する のがたいへんだということて、す。 ある程度長い名前になると , 開発環境に よっては cut&paste のような方法て、 , 文字列 コヒ。ーがて、きるのて、 , そのほうが間違いが 少なくなります。長い名前はタイプ時に間 違いがちなのて、嫌だという人がいますが , これはある意味て、危険て、す。タイプ時に間 違う確率は , 何文字あたり 1 回というものて、 あって , 短い変数て、も間違えるときは間違 えるものて、す。間違えたとき , どの程度の 影響があるかということも検討しておくべ きて、す。短い変数をいくつも使っていると , タイプし間違えたとき , 偶然別の変数にな ってしまうことがあります。この原因によ るバグは , 一度コンパイルに通ってしまう となかなか発見て、きません。長い名前の場 合 , 間違えてタイプしたら , そんな変数は ないとコンパイル時にはじかれる確率が高 くなり , その意味て、は安全かもしれません。 しかし , 長い名前にもデメリットがあり ます。あまり長い名前だと , 肝心の処理の 流れを理解するための思考を妨げる危険も あります。名前を追いかけて最後まて、読ん て、 , ああこれはあの変数だな , と思ったと きは , 今 while のループ条件を調べていたの か , if の判断の途中だったのか忘れてしまう かもしれません。という例はさすがに大袈