C言語による構造化/階層化設計 入門講座

プログラミング言語の人気度を示すランキングを公開するサイトがあるようです。TIOBE社やIEEEのランキングが有名なのだそうですが、これらのサイトでは、2017年12月時点で以下のプログラミング言語がトップ5にランキングされていました。

言語 ランキング
C 共に2位
C++ 3位と4位
Java 1位と3位
Python 1位と4位
C# 共に5位

これらの言語の中では、UNIXのコードを書くために開発された「C」言語が最も歴史の古い言語なのですが、2017年現在でも2位にランキングされている事に驚きました。

今現在、私は仕事でCを最も良く使っています。そうか、ランキング2位のトレンディ―なプログラミング言語で仕事してるんだな、良かった!…のかな???

自由の功罪

C言語の特長は「自由」である事だと思います。ポインタとキャストを使えば、どの変数にも、どのアドレスのメモリにもアクセスできます。またクラスがありませんので、クラスの概念を学ぶ事なく、クラスを意識せずにプログラムが書けます。

しかし「自由」であるが故の問題も発生します。プログラムの設計の良し悪しが、プログラマの習慣に大きく依存してしまう問題です。たとえば「大量の書類を整理せずに、その人だけが理解できる習慣で、ごちゃごちゃに積み上げる」ようなソースコードを書く事も、「関連する書類をひとまとめにし、他の人にも理解できる習慣で整理した」ようなソースコードを書く事もできます。勿論、この事は、C言語以外のプログラミング言語においても言える事なのですが、言語仕様の自由度が増すと、個人の習慣に依存するリスクは増えると思います。

この「自由」であるが故の問題は、人間社会においても起こり得ると思います。モラルのある人は、ルール/罰則の無い自由な環境下でも、自らの意志によって節度のある行動が取れますが、そうで無い人は、利己的で、周りの人に迷惑な行為も平気でやってしまいます。よって、適切な教育に加えて、適切なルールが必要になる事が多いです。

束縛の功罪

自由である事が時として問題になる一方で、ルールで束縛する場合にも弊害が生じます。束縛が強すぎると、人はその枠に収まり過ぎて、自由な発想や、革新的なアイデアが生まれ難くなると思いますし、「悪しきルール」が制定されてしまうと、自由な時代よりも状況が悪化してしまいます。

もう30年以上も前の事ですが、仕事で取引のあったある会社のあるチームでは、変数名の命名ルールとして「型名の略語+連番の数字」以外は使ってはならない…というルールが制定されていました。そのチームのマネージャーが制定したルールだったようなのですが、そのルールに基づいて書かれたソースコードは読み辛く、褒められたルールでは無いと感じました。

近年の組み込み向けマイクロプロセッサのトレンド

機器制御のための組み込みソフトウェア開発において、C++では無く、いまだにC言語が使われている理由は、RAM容量の制約を受けるためだと思っています。

がしかし「高速かつ短いコードを書いて、できるだけ安いマイコンを使わねばならない」という組み込みシステムの要件は、近年、緩和されつつあります。今は、組み込み用32ビットマイクロプロセッサ「ARM」の低価格版「ARM Cortex M0」(50MHz ROM:32KB RAM:4KB)が、ネット販売で1個130円で購入できる時代です。C言語を使う場合であっても、ソフトウェアの生産性/保守性/再利用性を向上させるための「工夫」がし易くなった…と言えます。

この記事で提案したい事は

この記事は、C言語によるソフトウェア開発、特に機器制御用の組み込みソフトウェア開発において、

  • 生産性/信頼性/保守性を向上させたい
  • 現実的かつ理解し易い、節度のある設計ルールを制定したい
  • 教育カリキュラムが欲しい

と望んでおられる方々に向けた「提案」です。この記事では、C言語によるソフトウェア設計/実装に関して、具体的に以下の2つの習慣を提案します。

  1. 「特定の役割り」を担う「部品」によってソフトウェア全体を構成する。
  2. オブジェクト指向プログラミングの習慣を取り入れる。

1は、全ての工業製品、たとえば自動車、家電製品、家、ジェット機 等にも適用できるルールだと思います。実際のところ、Java/C#/C++等のオブジェクト指向言語で開発されたソフトウェアの多くは、この条件を満たすと思います。よって「当たり前じゃないか!」と思われる方もおられるかも知れません。ですが、C言語で書かれた組み込みソフトウェアの中には、この条件を満たさないソフトウェアが存在し、その難解な設計/実装のソースコードを再利用した「流用開発」が行われています。

2は、前述した「束縛の功罪」を考慮した提案です。特定の組織や個人でしか通用しないローカルな習慣で無く、オブジェクト指向プログラミングで当たり前に適用されている「良い習慣」を取り入れます。またC言語に既に備わっている言語仕様を有効活用する事も考慮します。

同じ悩みを抱えておられる方はぜひ、ご一読頂ければと思います。

本講座へのリンク

第1回 「特定の役割り」を担う「部品」によってソフトウェア全体を構成する

第2回 Scheduler

第3回 オブジェクト指向プログラミングの習慣を取り入れる