アウトローのアウトドア(580)：コンピュータの話#216：プログラミング「技術」の話(23)：猫も杓子も「構造化」（笑）その13

Cで何かのプログラム（システム）を作る時には、設計者が同時に最初のプログラマになることが割とある……と、俺は現役時代に思っていた。
前の記事で、そんな話を書いただろ？（笑）
これはね、C言語でどんなプログラムを作るのかということとも、結構関係しているんだよね。

まず、Cは汎用のプログラミング言語だ。
いろいろなプログラムを作ることができる。
Cの特徴の一つは、OSや制御ソフトのようなハードウェア寄りのシステムを作れる、ある意味アセンブリ言語に近い性格を持っている一方で、
さまざまなアプリケーションの実装にも使えるという点だ。
俺は昔、

くらいに思っていたんだが、実際にはもっと広い。
システムソフトだけではなく、いろいろな用途のプログラムを書ける汎用言語として発展してきたわけだ。

もちろんだが、大規模な業務システムの開発にCが使われてきた時代もある。
ただ、C言語が広がっていった1970～80年代の姿をイメージするなら、

というのは、かなりCらしいプログラムの一つだと思う。

Unixユーザーが、自分たちの仕事に必要なプログラムを自分たちで作る。
シェル上で何かを処理したければCでプログラムを書き、場合によってはシェルスクリプトと組み合わせる。
俺が実際に扱っていたのも、Unix上――場合によってはMS-DOS上――で動く、そういうプログラムだったよ。

シェルのプロンプトから、

$ 何かのコマンド

と叩いて動かす姿をイメージしてプログラムを書くわけだ (^_^)
ところが、それから30～40年ほど経った。
世の中にはたくさんのプログラミング言語が登場したし、オブジェクト指向をはじめとする新しい考え方や開発技術も普及した。
複雑で大規模なシステムを作るための言語やフレームワークも山ほどある。
その結果、現在C言語が特に活躍しているのは、

• 組み込み

• 制御

• リアルタイム処理

• OSやデバイスに近い領域

• 処理速度やメモリ効率が重要な領域

といった、比較的ハードウェアに近いところになってきた。
それがCの強みを活かせる領域であることは間違いない。
でもね。
Cプログラミングそのものを理解するという意味では、俺の現役時代のような、

を考えてみるのは、今でも結構いいんじゃないかと思っている。
……というのが、今回の長い前置きだ（笑）

では、かなり古典的なんだが、
「簡単なテキスト集計コマンド mycount」
を考えてみようか。
やることは、こんな感じだ。

sample.txt（入力テキスト）
        ↓
    ファイルを開く
        ↓
    1行ずつ読む
        ↓
文字・単語・行数などを数える
        ↓
   結果を標準出力へ
        ↓
ファイルの終わりまで繰り返す
        ↓
 ファイルを閉じる　（※お行儀よい・笑）

たったこれだけ（笑）
でも、このシンプルなプログラムの中に、Cプログラミングの特徴が結構詰まっている。
たとえば、

• main(int argc, char *argv[]) → コマンドライン引数

• FILE *fp → ポインタを使ったファイル操作

• fopen / fgets / fclose → ファイル入出力

• char buf[256] → 文字列と配列

• while → 繰り返し

• if → 条件分岐

• count_words() など → 関数への分割（モジュール化）

• &count などを使えば → ポインタを使った引数渡し

• stdin / stdout → 標準入出力

っていう具合になる。
さらに、Unix上のプログラムとして考えるなら、リダイレクションやパイプも使えるようにしたい。
入力ファイルをコマンドライン引数として、

mycount sample.txt

としても動く。
一方で、標準入力から読めるようにしておけば、

cat sample.txt | mycount

なんてこともできる。
あるいは、

mycount < sample.txt

でもいい。

そういうふうにプログラムを書くんだよ。
これがC言語とUnixの結びつきの、面白いところなんだ。(^o^)
それでね、
一つのプログラムで ”すべて” をやるのではなく、

そうして、リダイレクション、パイプを活かす。

俺が昔Cでよく書いていたのも、そういう “小さな道具” だった。
今なら、この程度のプログラムなら Python なんかで書くことが多いかもしれないね（笑）
でもCで書いてみると、

が、割りとよく見えるってことさ（笑）

さて。
この程度の小さなプログラムだと、実はまだ「構造化」のありがたみは、それほど目立たないね。（苦笑）
極端に言えば、

main()
  ↓
ファイルを開く
  ↓
データを読む
  ↓
count_words()
  ↓
結果を出す

くらいで作れてしまうからね（笑）
main() が部品として作った関数を一つ二つ呼ぶ程度なら、

と言われても、
それだけ？
という感じがするよな（苦笑）

ところが、プログラムがもう少し大きくなると話が変わってくる。
「テキストを集計する」という一つの仕事を考えていたはずなのに、
よく見ると、その中には、

入力する（入力先を選択、チェックする）
    ↓
データを解析する（データの適正チェックもする）
    ↓
集計する（集計方法も色々あったりする）
    ↓
結果を出力する（出力内容をコントロールする）

「いくつかの仕事」があるし、
さらに「データを解析する」みたいな一つの仕事の中にも、別の仕事がある。
「集計する」の中にも、またいくつかの仕事がある。
つまり、

……ということを始めるんだよ。

そうすると、
設計しているつもりなのに、だんだんプログラムの形が見えてくる。
ここまで来ると、前に書いた、

という話とつながってくるわけだ。
設計とプログラミングの境界が・・・重なってくるだろ？（笑）
まあ、そうやって作業するのが似つかわしい仕事（対象）だってことが、前提ではある。
そして、このやり方こそが、Cでプログラムを作る時に俺（たち）がよくやっていた、
「段階的詳細化」
なんだよね。
そうすると、どんな仕事のやり方になってくるか・・・が、次からの話だな（笑）
（2026-08-28）