プログラマyasuhoの隠れ家

某ソフトウェア企業に勤務するおじさんプログラマyasuhoです

プログラミングスタイルで大切なことは?


人によって文章の書き方がいろいろあるように、プログラマによってプログラムの書き方は千差万別です。インデントやネーミングなどのスタイルに始まり、クラスや構造体などの構築方法、アルゴリズムの選択など、プログラマの数だけ書き方がありますよね。


ロジック上のミスは別として、プログラミングに正解というものはありません。それはたいてい視点や考え方の違いや、優先度の違いから生じるものです。


とはいえ、他人のプログラミングスタイルを学ぶということには価値があります。よい例はもちろん、悪い例であっても半面教師となってくれます。以下に書いた私のスタイルは半面教師としてしか使えないかもしれませんが(笑)、もしも誰かの参考になれば嬉しいですね。

yasuhoのプログラミングスタイル

初期デザイン


まずはプログラムのコンセプトを決める。達成すべき機能、利用する環境やシステム、レスポンスやメモリ・ディスク利用目標などについて、優先度をつけながら目標を(いれば)利用者と決めていく。これを初期の時点できっちり決めておくと、後で機能追加や変更を行うかどうかの判断がしやすい。


次に大まかな構成について考える。UIのイメージ、プログラムやデータ構造などを頭の中で組んで動かしてみる。場合によっては図を書いたり、Pseudo codeや簡単なプログラムを書いてイメージをつかむ。


仕様をどの程度break downするかはプログラムや環境に依存するが、目標やコンセプトだけははっきりさせておくことを心掛けている。そうでないと

  • これ、何のために作ってるんだっけ?
  • 作ってみたけど、結局使われなかったなあ

なんて事態に陥りやすい。

プロトタイピング


最初に仕様が決定できない場合は、プロトタイプを作ることもある(近年はこういったケースが増えた)


プロトタイプ作成では、特に強調したい部分の見せ方を重点的に考える。見せ方一つで製品のイメージなどが定着しやすいから。ビジュアルのセンスがないyasuhoだけど、デザインはいろいろ考える。


紙芝居はなるべく避ける。もちろん必要な局面はあるのだけれど、プロトタイプと製品の差は失望に変わりやすいから。

実装


実装は多くの視点があるが、特に気をつけているのは最初に思いついた論理を尊重すること。


ソフトウェアを難しく書くことは、実は簡単。いろいろと考え、あれこれ直しているうちにプログラム構造は複雑で分かりにくいものになっていく。難しそうなことを分かりやすいロジックで書くことは簡単そうに思えるけど、そうじゃない。


シンプルで思想の統一された分かりやすいプログラムを書くのは、とても難しい。最初に思いついたアルゴリズムは後で見返しても思い出しやすく、理解しやすい気がする。


ソフトウェアは小さな部品から作ってテストしながら、パーツを組み合わせていく、いわゆるボトムアップ的なアプローチが好き。これはたぶん組み込みやOS寄りのソフトウェアを書くことが多いからかな。

コーディング


コーディングスタイルはBSD UNIXをベースに自己流を加えたもの。タブはスペース8文字が好みだけど、最近はどうしても4文字が多い。いっそハードタブも4文字になったらいいのに(笑)


コメントは多くない。関数やメソッドの開始、それに分かりにくいと思われるロジックの補足程度。本人が無精者だからだけど、コード変更時に必ずしもコメントが変更されるとは限らないから、という言い訳もある(笑)


例え他の環境へ移植する予定がなくても、なるべく移植性のよいコーディングを目指している。移植性を高めることでシステム等への依存性が低くなり、コードの品質が上がるような感覚があるので。

デバッグ


いわゆるDebug printの類はあまり使わない。デバッガでピンポイントに問題を調べる。ASSERTよりエラーチェックを多く使うし、ログも必要に迫られた時にしか作らない。これらはyasuhoの横着なのだろうけど、ちょっとしたコード追加でタイミングの変わるOS寄りのプログラムを多く書いてきたからかも。

大事なことって!?


だいたいこんな感じでyasuhoはプログラムを書いています。でも、上記にあげたスタイルよりさらに強いルールがあります。それは既存のプログラムを変更する場合はそのプログラムのスタイルに従うということ。


一般的に業務におけるプログラミングは、新規に作ることより、既存のプログラムに変更を行う方が圧倒的に多いです。プログラムは複数の人によって変更されることになります。そして、そこには「暗黙のルール」が存在しています。


コーディング規則。それもルールの一つですね。でもそれはそんなに重要なことじゃありません。大事なことは設計思想だと思います。ソフトウェアが目標としていること。コンセプト。エラーや例外発生時にどんな振る舞いをすべきか。そういった思想が統一されているプログラムは見通しがいいだけでなく、ユーザが結果を予測しやすくなります。yasuhoの言うスタイルとは、プログラムのコンセプトを理解し、それを尊重すること。


プログラミングというと、言語やOOPなどの手法などがよく注目されますが、大事なことはどんなソフトウェアを作りたいか、だと思うのです。なんか当たり前のことみたいですが、そんなプログラミングを心がけていきたいですね。


あなたは、どんなふうにプログラムを書いてますか?