なんかたいそうなタイトルですが、まー気軽に読んでください。僕が普段注意してることを書いてるだけですし、注意してるだけで実際に守っているってこととは別問題ですから（爆）。
　それに、現実問題として、すべてのプログラマーさんがこれを守れるとは限りませんし、「んなの守ってたらやってられんわ！」とゆー会社もあることでしょう。でももし気に入った格言があったら、後輩に教えたり新入社員研修とかで使ってね（爆）。

　プログラミングは情報が命。何か分からないことがあった場合に、いかに素早く正確な情報を入手できるかがとても大きいでしょう。そのためのラインをしっかと継ないでおきましょう。とりあえずお勧めを上げておきます。
　
・本：基本中の基本。お金があるのならバシバシ買ってきましょう。
・ホームページ：意外と有益な情報がなかったりします。プログラミング系ホームページはそんなに増えてないかも……。ただ、ＣＰＵの命令セットとか標準Ｃ＋＋のドラフトなど、オフィシャルの情報とかが簡単に手に入ったりします。要するに、個人より企業？
・ＢＢＳ：返答はあんまり期待しない方がいいかもしれませんが、逆に、もっとも気軽に訊ける場所と言えます。まずはこの辺からがいいかも。
・メーリングリスト：比較的安定した情報源です。とりあえず見ていかなきゃいけないので、目新しい情報に触れる機会も多いでしょう。読むだけでもいいかも。
・ニュースグループ：ＢＢＳとシステムは似てるんですが、質問をするには向いてないかも（汗）。読むだけにしておいた方が。あと、英語のグループは情報量も多いので、こっちもチェックしておくといいかも。
・人：優れたプログラマーが身近にいるとは思わないこと（笑）。もしいたらそれは「天の導き」でしょう。時間的にゆとりがある場合なら、理解できるまでじっくりと訊けるのがいいところ。
・鏑矢の憂鬱：困ったらここ（笑）。

　プログラミングを始めたばかりの時は、とにかく大きなアプリケーションをいきなり作ろうとしてしまいがちです。そういうときには、大きなアプリケーションを構成する小さな機能を取り出して、それをテストするための小さなアプリケーションを作っていきましょう。
　小さなアプリケーションを作ると、もちろんコードは少なくて済みますし、関数に閉じこめる形が多くなるのでそれをまとめてライブラリ化するクセが着きやすいでしょう。ってゆーかそうしましょう（爆）。
　つまり、プログラムを小さくモジュール化して、それを使い回すことに慣れるために、大きなプログラムをいきなり作らず、小さなプログラムを作ってテストしましょう、ということです。

　これは「２」の逆です。コーディングしまくっていくと、「コンパイル至上主義」とでも言える状態になることがあります。「コンパイルできたコードは正しい！」と思いこんでしまいがちになってしまうと、ちょっとまずいです。
　そこで、自分が書いたコードについて、「ここはこの方法とこの方法とこの方法があって、その中からこういう理由でこの方法を選びました」ということをはっきりと言えるようにしましょう。「コンパイルが通ったから」というのは当たり前の話で、理由にはなりません。
　また、これは自分の主張を通すことにもなります。何人かが作ったコードのうちひとつが採用される場合、「なんとなく」ではアピールできないでしょう。「コードの優劣」を決めるときには「理由」が大きなポイントになります。そういう点に気を付けてコーディングすると、出世も早いかもしんない（笑）。

　自分の作った関数を自分で使う場合、比較的融通が利きます。「この引数はこういう意味」とか、そういうことを自分で知っているわけですから。そういった関数やクラスを当分使わない場合や他の人が使う場合、その「意味」をコメントとして書くことになるでしょう。今度使う時は、そのコメントを頼りにライブラリを使用することになります。
　でも、それに頼りすぎてはいけません。ある関数の引数が非 const 型のポインタだったとします。その引数についてのコメントに「データを渡してください」と書かれていても、少し不安に感じるでしょう。渡したデータは、本当に改竄されないのかどうか……。
　
　こういった場合には、引数を const にしてしまえばいいわけです。これは、コメントに「データを渡してください」と書く以上に大きな意味を持ちます。もしこの引数が改竄されたら、コンパイラがエラーを発生させるからです。
　Ｃ＋＋になってから、「コンパイラへの情報」となる構文が多くなりました。メンバ関数の const といった const の関係の他、まだサポートされていませんが例外などでもそういう構文が使われ始めています。これらはコンパイラがチェックして、サポートします。
　そういった構文を使うことで、ユーザーのミスを防ぐ、言い換えればユーザーの好き勝手にはさせないライブラリを作ることができます。逆に、そういったライブラリのユーザーは、ライブラリの意図するところを読み解けるようになっておいた方がいいでしょう。なぜここはポインタではなく参照になっているのか、それは大きなヒントになっている場合があるというわけです。

　この「３層構造」はWindows DNAとは別物ですが、構造的には同じです。自分でプログラムを作る場合、この「３層構造」を意識して作ると可読性、保守性、柔軟性が高まります。
　
　「データベース層」は、一番ローレベルの操作を行います。配列の操作やメモリの動的確保などのポインタを駆使したコードや、機種依存性の高いコードを埋め込みます。ＡＰＩやプライベートメンバ関数がこれに当たるでしょう。
　こういった「プリミティブ」な機能を操作するのが「処理層」です。ここでは「データベース層」の関数を呼び出すことでデータをコントロールします。メンバ関数全般や、ＳＴＬがこの辺を受け持ちます。
　これらを実際に使い回すのが「インターフェイス層」です。クライアントが使いやすく分かりやすいようなパブリックメンバ関数を持つクラスを作成し、パッケージングします。しばしばこれはクライアントそのものにも含まれます。
　
　Ｃ＋＋はＣ言語の機能をそのままに持っています。Ｃ言語が持つ「システム寄りのコードを書ける機能」を持ちつつ、高度なオブジェクト指向機能を実現しています。これらをごちゃ混ぜにすると、何がなんだか分かりにくくなります。
　たとえば単純な配列でも、ラッピングしてイテレーターを装備することで格段に使いやすくなります。この場合、配列に直に触れる層が「データベース」、イテレーターを実現するのが「処理」、イテレーターを操作するのが「インターフェイス」ということになります。
　このように分けることでプログラムが見やすくなり、バグの発生を局所化でき、使い回しやすくなります。プログラムの規模が大きくなったら、特に重視しましょう。

　完成したアプリケーションは芸術的であった方がいいかもしれませんが、そのためのプログラムには芸術性がないようにしましょう。つまり「まさにありきたり」が一番、ということです。
　プログラムは誰が見ても、未来の自分が見ても、分かりやすくあるべきです。そこに必要なのは「ピカソ」のようなものではなく、「ドラえもん」のようなものであるべきでしょう。
　特にＳＥの場合には、「アプリケーションを売る」ことと「プログラムを売る」ことは別ということを憶えておいた方がいいでしょう。アプリはお客さんに売るものであり、プログラムは自分の勤めてる会社に売るものです。その事を分けて、アプリケーションには独自性のある斬新なものを、プログラムにはありきたりさをと、別々に求めるべきでしょう。
　
　一応フォロー（笑）。アプリはあまり独自性がない方がいいかも（汗）。そのために「ウィンドウズＧＵＩ」ってあるんだし……。でも独自性が必要なところもあるし、そういった部分の兼ね合いが大事かも？
　自分の会社はプログラムを買ってくれない？　うーん、どうしよう……。
　あと、「見やすく分かりやすい」というのは難しい部分もあります。たとえば「水戸黄門」なんて日本人なら誰でも知っていますが、外国では知られてないでしょう。そういう「地域性がありそうでないわかりやすさ」っていうのもあると思います。
　たとえば、ポインタばりばりのシステムよりのコードと、クラスを繋ぎ合わせたコードとで、どっちが見やすいかというのは人によりけりだと思います。でも「両方ともしっかりと理解している」うえで、もし「こっちの方が見やすく分かりやすい」という方法があれば、そちらを取るべきじゃないかな……。

　残念ながら、世の中にあふれるサンプルコードには「おおっ！」と思えるものは少ないと思います（もちろんうちも含めて（爆））。紙面の都合で重要な部分をカットしたり、特別なロジックには詳しくても全体的なコーディング能力がなかったりと、総合的な面での「コーディングのいい例」というのはあまりないと思います。
　逆に言えば、皆さんは自分のコードに満足しないで、常により良いコードを書くよう努めてください。もし「芸術的なプログラム」があるとすれば、それは「限りなく純粋で分かりやすいプログラム」でしょう。

　ああっ、またえらそうなことを言ってしまった（爆）。でもなんだかんだ言っても、日本がプログラミングに関して後進国的なことは否めないと思います。もし日本のソフトハウスがどんどんソフトウェアを輸出するようになっていたら、今の不景気もなかったかも（笑）。
　これからの日本を引っ張るのは君たちだ！　って感じでがんばってください。応援してます！＜応援するだけかい。