|
漁師プログラマ
山崎敏 YAMAZAKI Satoshi
vol.01 |
|
|
●●はじめに |
|
|
●ある日
とある冬のある日，私が担当するプログラムは無事に完成し「納品」という作業を行っていました．
その日，予定していた作業を無難にこなし，定時で帰ることを確信し，機嫌よく残りの時間をすごしていました．気持ちはすでに明後日からのスキー場．
と，そこに「ビビビ！…」取ってはいけない電話のベルがけたたましく鳴るのです．「はい．アプリケーション開発部です」「山崎君？，例の仕事は終わっているよね？」「あ，はい．後は納品のみです」「急な話で申し訳ないのだけど，明日こっちに来てくれないかな？」「（ゲ！ヤバッ！なにか断る用事を考えなくは…）明日ですか？」「なんとかなるよね？」「は，はぁ，まぁなんとかなりますが…」「じゃぁ明日ね，よろしく（ガチャ！，ツーツー）」．翌日，この嫌な予感は的中します．
話を要約するとこうなります．「某プロジェクトが火をふいているので，助けてほしい．期間はあと1月．仕様書はない．プログラムは半分できているが，コードはグチャグチャ．書いた本人は病気になり今はいない．さらに仕様を知っているのはその彼しかいない…」．よくみると私と同じように，何が起こっているのか知らされずに，どこからともなく集められて来た人たちが数人，内容を聞いて唖然としています．私はこの後，友達とスキーに行く予定があり1秒でも早く帰って荷造りをしたいと思っていたところ，このプロジェクトのまとめ者の一言が私をキレさせたのです．「明日の土曜と明後日の日曜も出てくれないか？できれば今日から泊まって仕事をしてほしい」「は？…（しばし沈黙）」「土日も出てほしい」「…，む，無理です．予定が入っています」「みんな出てくれるぞ」「（そんなの知るか！こっちはちゃんと自分の仕事を終わらせて，これからスキーに行く予定なんだ！それはそっちのミスだろ！なんでオレがそこまで付き合う必要があるんだ！）…無理です」その後，想像どおり，かつて経験したことのないほど激しい嵐がやってきたのでした．ちゃんちゃん．え？スキーには行ったのかって？も，もちろん行きましたとも！
●小さい問題が大きい問題に
この話はもちろんフィクションですが，プログラマという職業をしていると程度の差こそあれ，このようなシステムに遭遇することがあります．片方のシステムでは，なんの問題もなく健康的に仕事ができているのに対して，別のシステムは健康を害するほど病んでいて，何人もの犠牲者を出すのです．なぜ，このような差が生まれるのでしょうか？技術力の問題でしょうか？それとも人の問題でしょうか？管理者の問題？会社の問題？考え始めるときりがなくなります．私が思うのは，ある特定の問題があるのではなくて，おそらく漠然とした大きな習慣が小さな問題を起こし，その小さな問題がたくさん集まり大きな問題になっていると思うのです．その元となる習慣による違いが結果的に大きな違いになると思うのです．
これから数回にわたり，このあたりの習慣の話を主に書いていきたいと思います．
●なぜ「最前線」なのか？
これは「理論か？実践か？」という話なのですが，私は理論派ではなくて実践派であるという理由から「最前線」という言葉を使っています．「現場」という意味も多いので「漁師プログラマ」という言葉も使います．プログラマという職業が漁師という職業にも似ているからでもありますが，とにかく理屈ではなくソフトウェアを書き上げなくてはならない，バグを取らなければならない，正しく動かさなければご飯が食べられない，プログラマとはそういった職業だと思っているからなのです．
理論ではわかっていても「知る」と「する」では大違いで，どんなに詳しく知っていても実際にそれができるかどうかとは別問題であると言いたいわけです．魚のこと，場所のこと，餌のこと，釣り糸のこと，竿のこと，どんなに多くの知識があっても釣れなければダメで，逆に，まったく知識がなくても1匹でも釣った人の勝ちなのです．
さらには，1度や2度のまぐれではこれもダメで，この品質をコンスタントに保ちつづけることも要求されます．それには経験や勘も必要とされるでしょう．そんな世界なので「理屈は知らんけど，こんなんするのがいいんとちゃいますかぁ」という話を取り上げることが重要ではないかと思っているわけです．
これ以降に書かれている内容に対して「理論的におかしい」とか「正しくない」という考えは漁師的な趣旨からずれることになります．「そんな考え方もあるのか」とか「ホントかよ？自分でやってみるまで信じないよ」という考えが適当だと思います．
まずは肩の力を抜いて気楽に糸を垂らしてください．あまり力が入っていると魚のアタリを逃してしまいますよ．
|
|
|
●●バグらないのは簡単？！ |
|
|
トップダウン式に結論を先に言うと，バグをなくすのは簡単です．「バグらないようにしよう」と考えればバグはなくなるのです．バグは困ると思っている人は多いと思います．では，バグが入らないようにしようと考えている人はいますか？バグが入らないように行動している人はいますか？何がわかっていて何がわからないのか理解していますか？時間に追われて仕事をしていませんか？昨日はゆっくり眠れましたか？朝はしっかり食事をしましたか？私が言いたいのはこのあたりなのです．本当にバグに困っているのなら何をすれば良いのか考えて，なんらかの行動を起こすべきです．魚を釣りたいのなら，魚のいる場所へ行くべきなのです．
「金持ち父さんのキャッシュフロー・クワドラント」（ロバート・キヨサキ著／白根美保子訳／筑摩書房／ISBN：448086332X）というベストセラーがあります．その本の中に良い言葉がいくつか書いてあったのですが，その中に「持つ→する→なる」という言葉があります．その意味を簡単に書くと，人の思考過程で最初に思うのは「欲しい」「手に入れたい」という物理的な欲求なのだそうです．これが最初のレベルの「持つ」です．次のレベルに上がると，持つために（手に入れるために）何か行動をし始めるわけです．これが「する」です．さらにレベルが上がると，ただ闇雲に何かを「する」のではなく，目標を持った行動になるわけです．これが「なる」なのです．この「なる」のレベルに到達することができれば，自然に（無意識に）「する」ことになり，さらには強く望まなくても容易に結果を手に入れることができるようになるというのです．
私は，この言葉は何事にもあてはまる言葉であると思っています．たとえば，バグを書かない方法論を持つには，バグを書かない方法を考えて実際に行動すると良いのです．その行動を保つにはそういうバグに対する意識を持ち続ける人になれば良いわけです．釣りがうまくなりたいのなら漁師の意識を持つ人になれば良いわけです．そうなるように「いつも心掛けることが肝心である」という話なのです．
|
|
|
●●バグによく効く薬 |
|
|
魚にもいろいろな種類の魚がいるように，バグにもいろいろなバグがあります．よって，効果的なバグ取りの秘訣もいろいろあります．しかし，万能薬はなくても共通する考え方というか習慣や経験から来る法則はあります．現場の技と言いましょうか，漁師の勘と言いましょうか．では，漁師プログラマの「バグによく効く薬」を見てみましょう．
●頭脳
まず，一番効くのは「クリアに，そして冷静に考えられる頭脳」です．納期に追われてパニックを起こしていませんか？やるべき項目や優先順位はちゃんと把握できていますか？休日はしっかり休みましたか？時間が足らなくて睡眠時間を削っていませんか？サービス残業をしていませんか？きちんと食事をしましたか？バグを減らしたいと思うなら，まずは自分自身をベストなコンディションに保ちましょう．仕事のパートナーや，チームのコンディションもベストに保ちましょう．コードを書く前から，すでにバグとの戦いは始まっているのです．まずは冷静な頭脳を用意しましょう．
●時間
次に効くのは「割り込みの無い，まとまった時間」です．せっかくクリアな頭脳を用意できても，電話などの割り込みが頻繁に入ったり，ガヤガヤとノイズの多い環境では威力もガタ落ちです．とにかくクリアな頭脳はバグに良く効きます．この集中力を持続させるための環境作りもバグを減らすための行動になります．お客さんからのクレームを今日は何回応対しましたか？携帯に今日は何通メールが入りましたか？上司や部下，同僚から質問責めにあっていませんか？あなたの時間はどのくらいありますか？プログラミングやシステムの設計にはとくに集中力を必要とします．しかし，人の集中力はコンピュータのように，電源を入れてすぐには起動しません．
何分も時間をかけて集中します．しかも一度の割り込みで，その集中力はゼロに戻ります．再び集中するにはまた同じ時間をかけないといけないわけです．長く集中できる時間を確保しましょう．
「ピープルウェア第2版−ヤル気こそプロジェクト成功の鍵」トム・デマルコ，ティモシー・リスター著／松原友夫，山浦恒央訳／日経BP／ISBN：4822281108）という本に，騒音や雑音，割り込みなどとコードの品質（バグの数の関係）に関しての具体的な数値やグラフが書いてあります．手持ちの資金や，会社の予算に余裕がありましたら1冊買ってみる価値があると思います．
●通勤時間（通勤地獄）
もし，あなたがあるチームの管理的な立場にいて，新たにチームに人を入れようとしていたとするなら，そのときに，ぜひ考えてほしいことがあります．
それは，その人の通勤時間です．自らの決断で長い通勤時間を選んだ人は少ないでしょう（逆に，郊外でないと家が持てないと，自ら苦渋の決断をした人もいるでしょうが）．
多くの場合，会社の上司（管理者）の決断でやむを得ず通っているのです．ここで「仕事だから仕方がない」と決めないでほしいのです．生産性や品質のことを考えてください．通勤時間が2時間以上になることがあらかじめわかっていた場合，その人を採用したら生産性はどのくらい上がるのでしょうか？長い目で見て，その人ではなく別の通勤時間の短い人を採用した場合はどうでしょうか？通勤時間が長いことは，働く本人にとってもチームにとってもデメリットだとは思いませんか？
●空間
これも考え方は時間と同じです．割り込みの無い，まとまった空間が必要です．とくにチームで仕事をするときはチームで「まとまった空間」を用意する必要があるでしょう．別々の場所にいても，メールと電話があれば仕事ができるというのは妄想です．非効率的です．
さらに「机とイス」も効きます．あなたの机の広さはどうでしょうか？机そのものが広くても，デスクトップタワー型PCと，17インチのディスプレイ，そしてフルサイズキーボードに光学マウス，外付けHDDにMOドライブ…．おそらく快適なプログラミングに必要と思われる環境を追求した結果，机の広さはかなり犠牲になっているのではないでしょうか？では，その机でA4の書類を開くことができるでしょうか？コーヒーカップの置き場所を確保できるのでしょうか？その机で思考や集中が途切れることなくコーディングできるでしょうか？マウスを動かすと机からFDが落ちてしまうような環境は今すぐに改めるべきです．最近はノートタイプのPCの性能もかなり良くなりました．省スペース化の意味を考えて，デスクトップタワータイプから大きめのノートタイプ（持ち運びは考慮しない，省スペースとして）のPCや，液晶ディスプレイへ移行することもお勧めします．あなたの意思が働かない限り，あなたの机はエントロピー増大の法則に従うだけなのです．
プログラマの多くは，画面内のコードのみを見て仕事をしていることが多いでしょう．しかし，バグに効くツールとしてソースコードをリストに出す（印刷する）ことがあります．リストに出すと画面上では見えなかった範囲を一度に見渡すことができるようになり，思考の整理ができます．さらに，赤いペンなどで書き込みができるし，複数の人が見てチェックもできます．バグ退治にはなかなか便利なツールです．このリストも，できる限り大きく拡げ全体を把握できたほうが効率が良いので，ここでもやはり広い机がバグに効果的になります．
また，イスも重要です．長い時間座っていても疲れずに，集中力を維持できることは，自分のCPUの性能を上げていることにもなりますし，体のことを考えてもそれなりにお金をかけるべきところであると思います．漁師プログラマの間では「アーロンチェア」（http://www.hermanmiller.com/）が有名ですが，私も資金さえあれば，今すぐにでも買いたいと思っているイスです．
●コードレビュー
コードレビューはバグに効きます．コードレビューとは誰かが書いた1つのソースコードを複数人でレビュー（検証）することです．レビューと言うと，必ずバグをすべて見つけ出さなければならないとか，コーディング規約に対して一字一句間違いがないか？無駄なコードや無駄なアルゴリズムがないか？など大変な作業を想定してしまいがちです．
しかし，あるとき私はコードレビューの本当の効果に気が付きました．それは「ごく簡単なコードレビューを実施するだけでバグは減る」ということなのです．コードレビューの質や内容はバグには関係がないのです．
コードレビューをするとなると，「見せるコードを書く」ようになります．少なくとも見せても問題のない程度のコードを書こうというスタンスをとるわけです．これはすなわち可読性の向上につながるのです．コードレビューをすると，他人のコードを見る機会も増えます．それは，どういったコードが読みやすいのか？どのように書けば理解しやすいのか？などのヒントを受ける機会も増えることになります．そのコードが必ずしも読みやすく可読性の良いパーフェクトなコードである必要はまったくないのです．そのコードが読みにくいと思うのであれば，おそらく反面教師として読みやすいコードを知ったことになるからです．
コードレビューの内容はともかくコードレビューをすることで，レビューをする側もされる側もコードの品質を上げることにつながるのです．コードの品質が上がり読みやすくなれば，自然にバグは減ります．コードレビューはバグを取るのに効果のあるポジティブなループであると言えるのです．
なお，コードレビューはメールなどで済まさずに，できるだけレビューする人数分のリストを紙に出して会議室に集まってワイワイガヤガヤとやるほうが効果的であると思います．
●可読性
万病に効く万能薬は「笑顔」だそうですが，バグに効く万能薬も案外「笑顔」なのかもしれません．
笑っていればバグはなくなるという楽観的な意味ではなくて，笑顔のあるような精神状態であれば，バグも入りにくい状態であろうという意味です．もっと具体的かつ理論的な薬がほしい人には「可読性（簡単に理解することができるかどうか？）」が良いでしょう．
CPUやメモリなどのリソースが乏しい環境で，多くの修羅場を乗り越えてきた人たちには「可読性は二の次，とにかく高速で，とにかく省メモリ」という習慣が染み付いてしまっている人も多いのではないでしょうか．組み込み機器を主なターゲットとしたプログラマも多いでしょうから，CPUやメモリなどのリソースが無尽蔵とまでは言わないまでも，それほど気にしなくて良くなった現在のPCのような恵まれた環境の人たちばかりではないのでしょう．一方，最近では，そういったリソースの制約がゆるくなった人たちも多くいるわけで，そうなってくると効果的なのが「可読性」となるわけです．
可読性と書くと難しい言葉に見えますが，簡単に書けば「読みやすいかどうか？理解しやすいかどうか？そこを重視しましょう」という考え方なので，複数の書き方が考えられる場合，理解しやすい書き方を選択すれば良いわけです．どういう書き方が理解しやすいか漠然というと「普通のコード」が良いのです．誰が考えても同じ書き方になるようなコードが理解しやすいということになるのです．
「それではプログラマの存在意義が薄れるではないか！」とお叱りの声も聞こえそうです．そういう人には，ぜひとも，他人には理解不可能なアクロバッティックなコードを書いていただき，そのコードのメンテナンスも延々と1人でこなしてもらいたいものです．もし，その人の手を離れることがあれば，メンテナンスは不可能なので，そのコードは破棄されてしまうか，その人には問い合わせの電話が殺到し，今の仕事の邪魔をすることになるでしょう．
漁師プログラマの中には，1人で閉じてしまうような仕事をする人も多いと思います．しかし，5年前に書いた自分のコードを見たことがありますか？おそらく他人の書いたコードと変わらない違和感を感じることでしょう．少なくとも私は1年前の自分のコードでも違和感を感じてしまいます．「3年たったら他人のコード」ではありませんが，未来の自分のためにも可読性に配慮するのはそれなりにメリットのある話だと思います．
可読性に関しては「Cプログラミング診断室―うつくしく健康なプログラムのために」藤原博文著／技術評論社／ISBN：4874085717）という本が参考になります．また，「C/C++によるプログラミングスタイルブック」（林晴比古著／ソフトバンクパブリッシング／ISBN：4797311835）も良いでしょう．
●KISS Principle
アメリカではビジネスマンからエンジニアまで幅広く使われている法則に「KISSの法則」という言葉があります．KISSとは“Keep
It Simple,Stupid!”の頭文字だそうです．これを日本語に訳すと「単純にしろよ！ゴルァ！」や「難しくするな！ボケェ！」となるでしょうか．これです．これがバグに効くのです．なぜ効くのかはここまで読んできた皆さんには容易に理解できることだと思います．
“KISS”の本来の意味は“Keep It Simple and Small”や“Keep It Short and
Simple”のように「簡潔なほうが正解だろ」という万能な用途に使う言葉ではないかとも思いますが，上の表現のほうが有名ですね．
●そしてコーディング？
まだまだ具体的なコーディングの話にはなりません．コードを書く習慣よりも，バグに効く習慣があります．それは「単体テストの習慣」です．
「鉄は熱いうちに打て」ということわざがあります．コードも熱いうちにテストしたほうが効率的なのです．ソースコードの量が増えれば増えるほどバグを取るためのテストコードが増えます．しかも，増え方は指数関数的に増えるのです．これは，100行単位に分割しされた10個のソースコードをテストするテストコードより，1000行で1つのソースコードをテストするテストコードのほうが何倍も多くなると言いたいのです．これでは非効率的であるのは明らかであるし，テストコード自信の信頼性も悪くなります．テストコードにバグがあったら一体何を信じれば良いのでしょうか？さらに，できるだけ，テストコードはソースコードにくっつけておきましょう．単純にテストコードが行方不明にならないために効果的であるし，そのことはデグレードの防止にもつながるからです．
| リスト1 main()関数の実装 |
//foo.c
int foo(int in )
{
... // foo 関数の実装
return n ;
}
#ifdef __foo_c__unit_test__
int main()
{ // foo()のテストコード
assert( foo(1 )==100 ) ;
...
}
#endif //__foo_c__unit_test__
|
たとえば，リスト1のように，foo.cという1つのファイルの中にfoo()関数の実装とfoo()関数をテストするmain()関数を実装しておくのです．コンパイル時にデファインオプションとして__foo_c__unit_test__を指定することで，何度でも簡単にテストすることが可能になります．また，テストコードを上手に書くことで，リファレンスマニュアルやチップス（サンプルコード集）の意味も持たせることが可能になります．テストができてデグレードが防止できて，マニュアルの代わりにもなる．これこそ「一石三鳥」というべき方法ではないでしょうか？
|
|
|
●●コードの話 |
|
|
最後に具体的なコードの話をします．ここから先に書いてあることは，漁師プログラマである私が長年の勘を頼りにあみ出した技（おおげさ）なので，必ずしも正解であるとか，絶対に効率的にバグを減らすことが実証されたモノではありません．その点を誤解のないようにお願いします．
●スコープは短く
| リスト2 4つのスコープ |
int a_global ; // グローバル変数
static int b_file_local ; // ファイルローカルな変数
void foo()
{
int c_func_local ; // 関数ローカルな変数
{
int d_local ; // ローカルな変数
}
} |
スコープとは，変数などのライフタイムや名前空間の概念なのですが，C言語で簡単に説明すると，リスト2のように大まかに4種類のスコープが存在します．よりグローバルであるほど更新される範囲が広くどこで更新されるのかわかりにくくなります（範囲が広いほどバグが入りやすいとも言えます．
グローバル変数有害論はよく耳にしますね）．ようするに可読性が落ちるのです．できる限りスコープの短いローカルな変数を使いましょう．
●最適化はしない
これは可読性をどこまで優先するのか？という話にもなるのですが，一般的に速度やメモリ使用量を最適化しようとすると，コードが複雑になり読みにくくなります．速度が速くなるとは言っても，小手先の最適化では数％程度の性能向上であることが多く，これでは可読性を犠牲にする価値がないということになるのです．
最適化をしたければ，もっと根本的なアルゴリズムや設計思想の段階でよく練りこむ必要があると思います．そうしなければ10％を超える最適化の効果は得られないと思います．さらには最初は最適化を無視して可読性を重視してコーディングすることで，実際に動き始めてから速度などの性能を測り，その後「どうしても性能が欲しい」という部分のみを集中して最適化するというアプローチもあります．この場合，コードの可読性は良いはずなので，最適化の範囲も最小限に限定できるというメリットもあるでしょう．
最近のPCの性能向上は目を見張るものがあります．ソースコードに何も手を加えなくても1年で2倍程度の高速化ができるという見方もできます．さらに，可読性を上げることでソースコードのそのものの寿命が延びればそのぶん長くハードの高速化の恩恵を受けることができます．コードの最適化を行ったためにハードに依存するコードになってしまうのでは，長い目で見たらコードの高速化に失敗しているとも言えるのです．
●ポインタは使わない
ポインタを使わないコーディングというのはC言語ではおそらく無理です．しかし，C++であれば可能です．C++にはリファレンス（参照）やSTLがありますから，これらを使うことで容易にポインタを撲滅できます．ポインタの危険性については多くの場所で語られていますので，ここで詳細は語りませんが「ポイントする先の有効性や信頼性が低い」という問題が大きいと思います．
よって，ポインタは使わずに，リファレンスを使うことをお勧めします．リファレンスを使ったことのないプログラマはまず関数の引数について，ポインタ，リファレンス，コピーの3つの違い（メリット／デメリット）をよく理解するところから始めてください．理解した上で上手に使い分けてください．
詳しくは筆者のWebページにある「ポインタ不要論」（http://www.01-tec.com/#doc）を参照してください．
●キャストはしない
そもそもキャストというのは，goto文と同じように強引なコードであると思うのです．設計上の誤りを「まぁまぁ，そんな固いこと言わずに通してよ」とか，「俺の言うことを信じろ！プログラマは完璧なんだ！」と言って強引に通してしまおうという態度に見えます．キャストの多いコードに出会ったら，それは設計がダサいのではないか？と疑って良いと思います．
C++ではポリモーフィズムなコードを書く場合など，どうしても避けられないケースもありますが，それは稀です．漁師プログラマの経験から，ほとんどのケースで回避できると断言できます．とくにC++にはテンプレートという概念があるので，こちらを使いましょう．
●継承は使わない
最近は継承に関する有害論もちらほらと増えてきました．オブジェクト指向の根幹を揺るがすような発言なのですが，有害であると思う人は確実に増えているようです（私もその中の1人です）．とくに，実装を多重に継承することは，巨大で複雑なクラスを安易に量産するだけなので，「カプセル化（情報隠蔽）」というとても有効な設計手法に対して逆行していると言えるのです．
C++の継承には主に「実装の継承」と「インターフェースの継承」と2種類の概念があります．とくに実装の継承に関しては使うべきではないと思います．カプセル化を重視すべきでしょう．継承がポリモーフィズムを実装可能にするメリットは理解していますが，それはインターフェースの継承であり必ずしも実装の継承とは言えないと思うのです．
| リスト3 C++による継承と包含の記述例 |
class A : public Boo // Boo を継承
{
...
}
class A
{
public:
Boo m_boo ; // Boo を包含
}
|
実装の継承を検討する場合は，その前に包含で解決できないかよく検討すべきと思います（リスト3）．
包含の概念は，階層化構造をとるため，巨大な一枚板のクラスの乱造を避けることができます．ここまで可読性について何度も書いてきたので「一枚板の構造より，階層構造のほうが可読性が上がる」ことは容易に理解いただけると思います．よって「実装を継承するよりも包含したほうが可読性が上がる」ということも理解していただけると思います．
私は，実装の継承は「百害あって一利無し」であると思っています．
|
|
|
●●おわりに |
|
|
これらの具体的な方法さえ実行していれば必ずバグが減るとは考えないでください．最初に書いたように，バグを減らすには「具体的な方法論」ではなく，バグを減らすにはどうしたら良いのか「考え続ける姿勢」が大事なのです．他人の言うことを鵜呑みにせず，自分でしっかり検証して，本当にそれで効果があるのか？もっと効率的な方法はないのか？最終的には自分で判断する姿勢が大切なのです．この世の中すべて自分しだいなのですよ．
次回は「コードのメンテナンス」の話を書く予定です．お楽しみに．
|
|
|
コラム■ハンガリアン記法 |
|
|
ハンガリアン記法（Hungarian Notation）とは「変数名や，関数名は，こういう書き方をしましょう」という命名規約です．ハンガリー記法とも言われます．コーディング規約の一部と言える作法の1つです．ハンガリー出身のプログラマが考えた規約なのでこう呼ばれているそうです．Microsoftが採用しているので，Windowsのサンプルプログラムではとてもよく見かけます．
lpszFileNameとかlpdwSizeなど，さまざまですが（ちなみにlpszとは“long
pointer to a string terminated byzero”早い話「文字列のポインタ」を表すそうです），要するに「変数名の先頭に型の情報を入れて，理解しやすく，誤り難くしよう」という考え方のようです．
しかし，漁師プログラマの立場としては，やはり可読性を重視したいので，このlpszのような意味不明な書き方は却下したい気持ちでいっぱいです．変数名には型情報のほかにも優先して記述したい情報は多いのです．
たとえば，引数なのか？ローカルなのか？グローバルなのか？スタティックなのか？クラスのインスタンスなのか？メンバなのか？パブリックなのか？プライベートなのか？コンスト（定数）なのか？リファレンス（参照）なのか？配列なのか？ポインタなのか？などなど，たくさんあるわけです．それらの情報よりも型の情報を優先するメリットが理解できないのです．
・ g_ グローバル変数
・ m_ メンバ変数
この程度は容認できますけど，それ以外は意味がないでしょう．各自，何を優先すべきなのか，よく考えて書きましょう．ちなみに筆者は，規則（規約）は少ないほど良いと思っています．
|
|
|
コラム■ローカル変数 |
|
|
C++やJavaなどでは，変数宣言がどこでも可能です．
どこでもというのは言い過ぎですが，必要になる直前で変数を宣言することで可読性を上げることができます（リストA）．
| リストA 直前に変数の宣言 |
void foo()
{
int i =0 ; // 普通は先頭で宣言します
if (...)
{
...
}
int j=0 ; // C++やJava では，
... // こんなところでも宣言できます
} |
C言語でも同じような書き方ができます．新たなスコープを作ることで，そのスコープの先頭で宣言ができるのです（リストB）．
| リストB 新たなスコープを作成 |
void foo()
{
int i =0 ; // 普通は先頭で宣言します
if (...)
{
...
}
{ // 新たなスコープを作る
int j =0 ; // C言語でも宣言できます
...
} //有効範囲はここまで
}
|
スコープを作って変数の有効範囲を限定すると，可読性を上
げてバグを減らす効果があります．C言語でなくても，C++でもJavaでもこの方法は有効です．安易ですが有効な方法なので皆さんもジャンジャン使ってバグを減らしましょう．
|
|
いかにして、バグらないか？