にゃん太郎さん、こんばんは。

saki1208です。
しばらくぶりにコメントさせていただきます。
突発的に忙しくなったもので、コラムは拝見させていただいていましたが...

私もコーディング規約自体は必要だと思いますが足枷にならない程度のものであることが重要ではないかと思います。
命名規則については直感的に機能がわかるとか、変数の用途/意味がわかるというのが重要で、ハンガリアン記法のような「変数の型」がわかることはあまり重要ではないと考えます。
なぜなら、最近のプログラミングではIDEを使用して開発することが多く、マウスポインタを合わせれば型などの情報は表示することができます。また、機能とは関係ありませんし、普段使用しない型や省略形が同じになり得る型では思考が停止してしまいます。

私の作業場所では例外無くハンガリアン記法ですけどねorz

それよりも、禁止事項や推奨事項を充実させることの方が重要ではないでしょうか。
記述内容/方法によりバグの温床となってしまうものやそこまでではないけどできるだけこっちで!!みたいなものを理由や事例をもとに説明して守らせるほうがよいと思います。

どこかで書きましたけど「すべてのブロックの先頭でOn Error Resume Next」が記述されているVB(.Net前)なんて最低です。
後は、数百行のメソッドとか...

コーディング規約もプロジェクトを繰り返す度に進化していけばよいのですが厳しく縛り付けられるところほどメンテは行われない気がします。

にゃん太郎さん、こんばんは。

私はコーディング規約は必要派です。

しかし、既存のコーディング規約はひどいものが多く、それが技術の伸びを殺している。それで「変えろ！」と、ちょうど揉めているところで、飲んで暴れたところですorz。

技術者が前例主義になってどうする！
技術者が技術的検証をしないでどうする！

つってもね、サラリーマンには分かるまい……。

酔っ払いですみません。

自分以外の人が保守する確率が高いというようなことも含めて、
開発する環境によるものが大きいと思うのですが、
開発メンバーの能力をどの程度以上であると前提としておけるかというのが、
きわめて重要なのだなと思いました。

はっきりいって、
> ローカル変数の使い回しはしない（ループ変数など）
こんなことを守るのはバカらしいというか、
そもそも最近はループ変数の使用頻度そのものが少なくなっていたりしますが、
こんなことをルールとして決めなくてはならないのがかわいそうでなりません。

こういっちゃ悪いですが、コーディング規約を決める人の能力が低いばかりに、
普通に書いたコード、もっと言えば保守性を考慮したためにテクニカルになっているコードを
(よくわからないから)読みにくいなどと言われるのは勘弁してほしいです。

さすがに「読みやすい = 保守しやすい」と単純に考えているとは思っておりませんが…。

saki1208さん、ありがとうございます。

　「推奨事項」って言うのはあまり考えないですよね。「コーディング規約」＝「やっちゃいけない事」ですから。最近のIDEはカッコ前後のスペースとかインデントとかは割合いい感じでやってくれるので昔ほど気を使わないで良いのがありがたいです。そういや、昔はソースコードを整形してくれるツールもあったっけ。

　コーディング規約でバグが無くなることはないでしょうが、少なくともアホらしいバグは減ると思ってます。ですから、

> 記述内容/方法によりバグの温床となってしまうものやそこまでではないけど
> できるだけこっちで!!みたいなものを理由や事例をもとに説明して守らせる
> ほうがよいと思います。

　これには賛成できます。是非、使わせて頂きます（笑）

生島さん、ありがとうございます。

> 技術者が前例主義になってどうする！
> 技術者が技術的検証をしないでどうする！

　おっしゃる通りでございます（笑）

　コーディング規約だけに限らないと思いますが、サラリーマンだとどうしても楽な方に流れてしまうのは制度上（？）仕方ないと思います。私の部下を見てもそう思うので。もっともあまり人の事は言えませんが…あう。

　でも、今年いっぱいでサラリーマン生活にはさよならする予定ですけど、どうなることやら（苦笑）

Atsushi777さん、ありがとうございます。

> こんなことをルールとして決めなくてはならないのがかわいそうでなりません。

　私はどちらかと言えばコーディングを「規約を決めてまでルール化しなくても良いんじゃない？」とは考えています。でも、好き勝手にすると統一感がなくて読みにくいコードがあちこちに出来てしまいます。エンジニアなら時間が掛かるかどうか別にして他人のコードを読むことは出来ると思いますが、読みにくい事により仕様変更時などにバグを入れ込んでしまう可能性もあります。

> 普通に書いたコード、もっと言えば保守性を考慮したためにテクニカルになっている
> コードを(よくわからないから)読みにくいなどと言われるのは勘弁してほしいです。

　これもコラムで少し書きましたが「保守性を考慮したためにテクニカルになっているコード」は人によって意見が分かれるところと思います。メンバーや管理者のスキルや考え方の方が大きく、結局はPMやSEがどこまで「規約」を詰めるかになってしまいます。生産性も保守性もキーワードとして重要ですがソフトウェア開発では意外と抽象的で人によって考え方の差異が大きいと思います。それを解決する方法の1つとしてコーディング規約があるのでしょうが、奥が深くて難しい問題です。

にゃん太郎さん、こんにちは。

.NET専門会社の弊社の場合ですが、ぱっと思いついた項目を書きます。
過去に経験したプロジェクトで問題になった部分です。
VB.NETとC#が混ざっている点はご容赦ください(^^)

-----------------------------------------------------------

・配列を戻り値にするメソッド
返すものがない場合、空の配列を返すのか、nullを返すのか

・string型変数の初期値
空文字を入れておくのか、nullのままでよいのか

・ループ
do whileを禁止して、whileのみで書くのか

・VB6.0時代の互換のキャスト
CInt、CLongなどを許可するか

・参照型のキャスト
DirectCast、CType、TryCastのどれに統一するか

・文字列の連結
&で連結するか、+で連結するか

・三項演算子やIIFの使用を許可するのか

・null結合演算子(null coalescing operator)の使用を許可するか

・null許容型(Nullable Type)の使用を許可するか

・Subから抜ける場合、Exit SubかReturnのどちらに統一するか

・ifの評価は、ショートサーキット評価での記述を厳密化をするか

・yield returnの使用を許可するか

・DBのコネクション
1つだけ作って開け閉めするか、毎回作って破棄するか

・IDisposable型
usingでの解放を義務づけるか、各自が責任を持ってDisposeを書くか

・usingでのエイリアスの定義の使用を許可するか

・VB.NETでのメソッドのオーバーロード
Optionalで省略可能な可能なメソッドとして書くか、改めて引数を増やしたシグネチャで書くか

・初期データ付きで静的なHashtable
プロパティとして定義し、プロパティ内で生成と初期値の設定を行うか
フィールドにして定義し、静的コンストラクタで生成と初期値の設定を行うか

-----------------------------------------------------------

失礼しました。

はやしさとしさん、ありがとうございます。

　なんかいっぱいありますね（苦笑）まぁ、うちも.Net使うから良く分かりますが。

　JavaやC#を使うようになって「null」と空をどうするかという事は前は結構悩みました。あまりこの辺りって明文化しないですから（私の経験、では）DBもそうかな。C/C++が長いとnullもゼロも同じ（型違い、だったっけかな。でもC++ではintだったような気がする）感覚になるので、最初はC#でマジで「null＝0」と思ってた。

　こういう細かい事も必要なのか、ねぇ。

にゃん太郎さん、おはようございます。

目指すところは、「コードレベルのムラをなくして平均化する」ということでしょうか。
言いかえるならば「落とし所」を設定するという感じ。

若い人向けメッセージ→
新しい機能を使いたいのはわかるけど、「家に帰ってからも趣味のプログラムを組む人」ばかりじゃないから、手加減してね。
新機能といえども、実現手段の一つであって、新機能を使うことが目的じゃないからね。

ベテラン向けメッセージ→
確かにVB6.0の頃のコードでも「下位互換性」のために動かすことができるけど、新規プロジェクトでは、VB.NETの作法で書いてね。
VB6.0の頃の書き方を、新人が鵜呑みしてコピペするから、本当にやめてね。

興味深い話題ですね。
日本のコーディング規約と米国のものとは毛色が違うと感じます。
日本のは「みんな一緒の新人用儀式」。
米国のは「プロ集団としての規約」。
これはC++ Coding Standards、Effective C++、Effective Java・・・などの書籍を見れば感じ取れると思います。
さらに大きな違いは、米国は実装デザインと論理デザインを考慮した「設計と実装を横断するプロの知識」をコーディング規約にしているのに対して、
日本では「現場を知らない管理者」や「設計を知らないプログラマ」が決めているという事が多いように感じられます。
私が今まで目にした規約は、プロとしての規約とは思えなんですよね・・・
相でない現場もあるでしょうが、コーディング規約を何か誤解している現場が多いように感じてしまいます。

はやしさとしさん、ありがとうございます。

> 言いかえるならば「落とし所」を設定するという感じ。

　個人的には「そうではない」様にしたいのですが、結果的にはそうなってると思います。経験とスキルの差もありますが、例えばマイクロソフトに限って言えば都合よく売るためにコロコロ仕様を変えてくれる。その影響はベテランには今までのやり方の否定を迫り、若手には便利で面白い機能を提供して興味をそそるようにしてくれる。こうなるとコードの書き方や考え方がバラバラになってしまう。管理する側からするとどっちの言い分も理解できますが、それじゃ進まないので「規約」という体裁で落とし所を作ってるとは正直思います。

インドリさん、ありがとうございます。

　もともと日本ではコーディング技術や考え方に関しては教育しないのでそういう意味では未熟だと思っています。出来上がった「もの」がすべてなので（これに関しては間違いではないのですが…）「コーディング規約」が統一感を出すための指針と言う性格になってしまいます。本来はパフォーマンスも考慮したものなのですが。

　ソフトウェアのビジネスモデルと言うのはSI以外では（携帯電話みたいな組み込みも含めて）開発→リリース→バージョンアップ作業→リリース…の繰り返しとなります。日本ではこのサイクルが早いのでとにかく商売上早くリリースする事を求められます。ですから設計も実装もとにかく「作って動作させる」事が優先なため、コーディング技術に関してはやや置き去りでも完成さえすれば黙認されます。この黙認の歴史が現在の状況なんでしょうね。

にゃん太郎さん、こんばんは。

saki1208です。

>　「推奨事項」って言うのはあまり考えないですよね。「コーディング規約」＝
>「やっちゃいけない事」ですから。
>> 記述内容/方法によりバグの温床となってしまうものやそこまでではないけど
>> できるだけこっちで!!
引用していただいた私のコメント内の前者が禁止事項、後者が推奨事項の意味で書いてました。わかりにくくてすいません。

ハンガリアン記法は、積極的に使います。使わないなんて、勿体ない！まして、使うななんて、信じられない。

Jittaさん、ありがとうございます。

> ハンガリアン記法は、積極的に使います。使わないなんて、勿体ない！
> まして、使うななんて、信じられない。

　いや、信じて下さい（笑）ま、個人なら好みで良いと思いますし、職場ならそのガイドラインに従えば良いと思います。これが良いのか悪いのかは各々職場なりで議論して頂ければ。私のチームでは「使いません」と言うだけです。まぁ、基本がオブジェクトなので接頭語が面倒くさそうなだけだと思うけど。

# そういや、うちの職場の若い子が「string」が変数だと思っていたらしい。おいおい

はじめまして。ようすけと申します。
仕事の合間にざっとしか読んでいないのですが、（あとで全部拝見します！）
同感してしまう部分が多々あり、思わずコメントしてしまいました。

私はフリーランスのPG・SEで経験としてはまだ10年も満たない者です。
これまで携わった開発現場はなぜかコーディング規約が存在しない現場が多く、私の感覚ではどうしても納得できない(読みにくい）コーディングによく出くわしました。逆もしかりで、わかりやすい(読みやすい？）コーディングに出会うこともあります。

と、勝手に人のコーディングを自分なりに評価していますが、私は自分ののコーディングを人に評価してもらったことがなく、なかなか自信を持てずにいます。
経験をつんでいけば自信を持てるのでしょうか？

駄文失礼いたしました。

ようすけさん、ありがとうございます。

> 経験をつんでいけば自信を持てるのでしょうか？

　コーディング規約ってそもそも他人のために「こうやってコーディングしましょう」って言うものですから、職場毎に考え方はあると思います（それの良し悪しは別として）評価にしても評価する人の基準が統一されないでしょうから結局、自信は己で納得する以外ないと思います。そういう意味では経験を積むのが一番ですが、個人的にはコードレビューしてもらうのがいいかと。ダメなときは「なぜダメなのか？」を明確にしてもらいます。単純に「良くない」と言われた時はその人にとって気に入らないだけですから無視して構いません。私は「ダメ」な理由は明確にします。逆に明確にならない時は言いませんが。

　日々精進が一番ですよ。頑張ってください。

> まぁ、基本がオブジェクトなので接頭語が面倒くさそうなだけだと思うけど。
　はぁ。。。やはり、「誤解」の方が広まっているんですね...
　にゃん太郎さんはじめ、ここで「ハンガリアンいらね」派の方々は、「型によるハンガリアン」を使っていらっしゃるのだと思われます。確かに、それは、要らなくなりました。コンパイラが型を厳密にチェックするようになったし、オブジェクト指向言語ではまず意味を持たないでしょう。
　しかし、私が言っているのは、「意味によるハンガリアン」です。これを、「アプリケーション ハンガリアン」と言います。
http://ja.wikipedia.org/wiki/%E3%83%8F%E3%83%B3%E3%82%AC%E3%83%AA%E3%82%A2%E3%83%B3%E8%A8%98%E6%B3%95
『
本来、シモニーの考案したハンガリアン記法とは、変数の意味や使用目的から接頭辞を決定することであり、型では区別できない情報を変数名に付与することで、紛らわしい変数の意味を明白にし混同をさけるためのものであった。たとえば、論理座標とデバイス座標、X軸とY軸、ドルと円などで、これらは単純に型による安全性に頼ることはできない。
』
　例えば、「ユーザーが入力したままの文字列」、「SQL 用にエスケープした文字列」、「HTML 用にエスケープした文字列」、「データベースから持ってきたままの文字列」、「Shift_JIS な文字列」、「EUC_JP な文字列」などを、区別することは必要だと思われませんか？これらは全て「文字列」であり、型によって区別する必要はない、区別することは出来ません。しかし、データベースへ引き渡すのに、「ユーザーが入力したままの文字列」を渡していれば、それは危険です。コンパイラも検出してくれませんし、テストでも適切なデータを用意していなければ検出できません。そういうミスを、コードを書いている段階で防ぐことが出来る可能性を引き上げます。

つれづれに思うことのつづきです
スパム防止のため非公開とでたので、前文が掲載できたか不明です。

----
・書き方の規則性 について

　書き方にルールを与えることで、書き方の違反をチェックする
ようなツールがあります。

ビルド環境が支援する型チェックやコード・チェックが使えます。
　コンパイラは、変数の型変換(キャスト)は常に正しいという前提ですが
"lint"などの静的解析ツールでは警告になる場合があります。
また、バッファー・オーバーフロー、変数のオーバーフロー、0割り算
などもツールで検出できる場合もあります。すべて検出できるわけ
ではありません。ただ、決まった書き方をして条件を狭めれば、そのような
不具合を自動で検出する効果を高められる場合もあります。

　"CCCC"などを使用すれば、各モジュールのマッケーブの複雑度など
ソフトウェアのメトリクス(尺度)も取れます。コードを計量化できれば
ルールとしては、複雑度は20以下にするという風に書けると思います。
いわゆる、コピペ・コードも、コード・クローン検出ツールなどで
検査し直していけます。

　インデントはそろえておこきたいです。
インデントが4文字のソースコードの中に8文字の
コードが混じっていると、見た瞬間は、分かりにくいと
も思えます。
　そこにネスト(入れ子)の動作が判読できないとき、単に理解が
足りないのだろうけど、間違った理解なのかで混乱します。
　インデントは個人的にはtab は 4文字が好きですが、
条件で変わるtab文字より tab文字を使わず空白文字が尚更好きです。
ただ、空白文字は4文字にしたいところが3文字になったり
間違いやすいので趣味としての意見です。

　また、演算子などの優先順位のについても、
「よく分かっている人」と「わかって無い人」が混じっていると、
「他人」からみると、明らかにレベルの低い記述である部分は
不快を感じるだけですが、括弧('('と ')')の無い部分は読むのに
難儀します(「仕様」とよく突き合せなくてはならないため)。

----
・命名規則

　よくソースコードを読めといいますが、
個人的にはコード自体は結局に処理の手続き順序でしかないと
考えています。

　重要なのは、どのようなデータが入力されて、どのように加工されて、
どんな結果がでれば良いのかだと思います。

　それを分かりやすくするのがデータの構造と名前、名前空間やスコープ
の問題だと感じます。

　型(タイプ)についてですが、C言語では、これはむしろ、
きっちり宣言をすることや、ヘッダーを適用範囲や境界(ドメイン)を
意識して作ることなどで重複しない形に参照しやすくすることで回避
するとか。不要なヘッダを参照していないなど、調査の範囲から
限定しやすくすることです。

　例えば、画像を加工するソフトを考えるとき、３つの部位
（ファイル、データ加工、表示）があったとして、テキストの検索で
10000行中に200箇所もデータ転送に関するTransfer()という記述があったら
げんなり するでしょう。
　ただ、３つの部分でやり取りされるデータは、同じ構造の
image_format(固定長)と image_data(可変長)のように1つに
定義できるでしょう。
　また、それぞれが、File.Transfer(), Processe.Transfer(),
Display.Transfer() であったら共通の機能 Transfer() の定義は
1箇所でしょう。３つの部位のどれかを検索する場合には、
その内の 1箇所を調べればいいよとなりましょう。

　他には、変数 xxxx_100msは、100ms毎に内容が変更されることを
期待したいとします。
これが、実際には1000ms毎で変更されていたら怪しいと思いますよね。

　もっとも、最初から完璧な命名にこだわる必要も無く、それぞれの
名詞に同じものがない・固有であれば、まずは良いようにも思えます。
そこに、目的や、意味などから、きっちりしたものへの変更は、
テキスト･エディターなどでも簡単に一括変更できるから、
最終的にはまとめる方向は持たせたいです。
そうすれば、名前は索引のようにも機能します。

　コール･グラフをとればモジュールの参照順序が分かるので
循環参照しているなど、良くない部分や同じような機能の階層
が揃っているかも判断できるでしょう。
同じような名前を含むものが、違う境界(ドメイン)の同じ階層に
あれば内容の把握を手助けするでしょう。

　Doxygenなどのソースコードのコメントからドキュメントを作成
するようなツールでは、テストコードやサンプルとのリンクを貼る
ことで簡単な関数仕様書みたいなものも作成できます。
また、変数の索引も生成できるので、それを見て似たような内容を
扱う変数たちの、日本語のコメントが ばらばら だったら直そうと
思うでしょう。

　ソースコードをツールに掛けることで名前やコメントが
抽出できたり加工できるということは、
名前やコメントも「リファクタリング」の対象であるともいえます。

　コメントが ちぐはぐ だったり、間違っていると、
間違った理解を誘発して苦労することになります。

長くて申し訳ありません
こんどはXSS攻撃と間違われたようで、書き込みに苦労しました。
（半角中括弧がNGワードなのね？）
---
・ if / else

　if (flag1 == a1)　
　　｛　
　　　/* 処理１ */　
　　｝　
　　/* else はない */　

　if (flag2 == a2)　
　　｛　
　　　/* 処理２ */　
　　｝　
　　else if (flag3 == a3)　
　　｛　
　　　/* 処理３ */　
　　｝　
　　else if (flag4 == a4)　
　　｛　
　　　/* 処理４ */　
　　｝　
　　/* else はない */　

と、いうようなときを考えてみます。
ここで、処理条件が変更になった。その正しいコードはこう。

　if (flag1 == a1)　
　　｛　
　　　/* 処理１ */　
　　｝　
　　else if (flag3 == a3)　
　　｛　
　　　/* 処理３ */　
　　｝　
　　/* else はない */　

しかし、このソースを触っている別の人がいたとしましょう。
このソースは正しいのだけれど、変更した当人と話していない場合、
間違って処理を消してしまったかのか判断が難しいと思うかもしれません。
ただ、/* else はない */ の消し方で、
処理２と処理４は意図的に消したかなとは思えるかもしれません。

かといって、変更した当人と話していても、当人は正しいと
主張するかもしません。
まぁ、テスト仕様書やテストコードがあって「パス」していたら
問題ないでしょう？ 結果の少なくとも再現できます。

元のコードでは、少なくとも処理1.5だとか処理５は無いのは
分かりますよね。

::: 「絶対に通らない処理は作らない」
これは自分も賛成です。理由としては「他人」から見るとそのコード
に遷移する条件が「あるように」見えるからです。

　さて、先の例の元のコード 処理１～４がある状態を示す値を返す判定
をするものだとします。処理１～４を通らない場合の状態の値は０ です。
　ただし、このとき、この上の部分で「状態の値が-1」を出していたと
しましょう。つまり、上の部分に「不具合があった」と。
ここで /* else はない */の部分で「念ために」と else を
つけて、「状態の値 ０」としていたらどうでしょうか。
「勝手に」に「バグが正常」となってしまう「爆弾」に変わります。
本来あってはならない、状態の値が-1 が検出できなくなっている
(まぁ、単体テストをしっかりやっていれば検出できるでしょうが)。
　ようは、不要なコードは品質を低下させるということ。
　もし、「念のため」というのなら、"assert文"(主張)で来ないはずの
ものがきた場合は、異常通知してもらう方が、デバッグやすい訳です
(最終状態で、assertが実行されては困るけど)。

　コードで値や状態がどのように変化していくか把握しておきたい訳です。

----
・ goto
個人的には、共通のエラー処理などとしてのgotoは自分も使います。
理由は、Linux Kernel のコーディング・スタイルと同じ。

----
・関数の終点

　関数の出口(return)は一箇所にする。
これは、デバッガーでブレークポイントを貼るときに1つの出口に
１つ貼るだけでよいからです。
出口が複数あると、出口の数だけブレークポイントを貼ることになります。
また、貼り忘れると いつの間にか関数から抜け出していて
テストし直しという手間が増えますね。
　さらには、「いつの間にか抜け出していて」いるようなものは
不具合との判定もできるということです。

----
NULL(ナル/ヌル)
C/C++言語の「仕様上の定義」ではNULLはNULLという独立した意味です。
NULL = 0 ではありません。
多くのコンパイラやライブラリで「実装上」そうなっているだけです。

「実装上」そうなっているので、0で扱わないとうまく動作しない
場合もあるようです。

なお、ASCII文字セットのNULL文字は、エンコード 0x0 です。

> 設計も実装もとにかく「作って動作させる」事が優先なため、
> コーディング技術に関してはやや置き去りでも完成さえすれば黙認されます。

欧州の自動車業界にはMISRAというガイドラインがあるけれど、
日本においてはIPAなどがガイドラインの検討をしているようです。

C言語のコーディング作法(ver 1.0)
http://sec.ipa.go.jp/download/dl.php?filename=report/200606/CMGuide_V1-0.pdf

> if(flag == true)
booleanの使い方・名前のつけ方がわかってない人の発想で、「フラグ」という概念から抜けだしてないです。「フラグ」だとtrueが何でfalseが何を表してるかわからないです。
「enabled」「exist」「isなんとか」等、見たことあると思います。こういう名前をすんなり受け入れられるようになると if (exist == true) { って野暮ったく感じませんか？ if (a == 1 == true) { って書いたら変ですよね？それと同じレベルということです。

規約関係でまだ話に出てないようですが、変数の宣言を全部メソッドの上に書く人がいるけど、あれ読みにくい(いつからどういう値が入っているか分かりにくい)し、使わないのに宣言したり、使いまわしたりの原因となります。変数のスコープが最小になるように書くことを規約にいれたほうがいいと思ってます。

間違った記述が、さも正しいように書かれていたので突っ込みます。

> NULL(ナル/ヌル)
> C/C++言語の「仕様上の定義」ではNULLはNULLという独立した意味です。
> NULL = 0 ではありません。
> 多くのコンパイラやライブラリで「実装上」そうなっているだけです。

「NULL == 0 ではない」の記述ミスだと思いますが・・・

NULL == 0 ではない？
仕様書を読みましたか？

C の仕様書には次の記述があります。

The macro NULL is defined in (and other headers) as a null pointer constant

では null pointer constant の定義はというと

An integer constant expression with the value 0, or such an expression cast to type
void *, is called a null pointer constant.57) If a null pointer constant is converted to a
pointer type, the resulting pointer, called a null pointer, is guaranteed to compare unequal
to a pointer to any object or function.

したがって NULL == 0 というのは「仕様上正しい」

では C++ ではどうか？
NULL がマクロで、null pointer constant であるという定義は C と同じ。
C++ における null pointer constant の定義はというと

A null pointer constant is an integral constant expression (5.19) rvalue of integer type that evaluates to zero
or an rvalue of type std::nullptr_t. A null pointer constant can be converted to a pointer type; the result
is the null pointer value of that type and is distinguishable from every other value of pointer to object or
pointer to function type. Two null pointer values of the same type shall compare equal. The conversion of
a null pointer constant to a pointer to cv-qualified type is a single conversion, and not the sequence of a
pointer conversion followed by a qualification conversion (4.4). A null pointer constant of integral type can
be converted to an rvalue of type std::nullptr_t.

したがって、C++ でも NULL == 0 は間違いというわけではありません。

次に「NULL 文字」
「NULL 文字」というものは C/C++ の仕様上存在しません。
大文字で "NULL" と表記した場合は、上記定義が存在するため、
null pointer constant を意味することになります。

ASCII 文字セットの NUL 文字は、C および C++ どちらの仕様書でも
null character として定義されています。
( なお C, C++ どちらの仕様書でも NUL とあった場合には
ASCII character set のヌル文字を指します。)

-------

このエントリの本題の「コーディング規約」については、
わたしは最低限の規約は必要だと思っています。
「最低限」の線をどこに引くかは、言語によって、また環境によっても異なると思います。

C++ の場合は、次の規約は最低限必要ではないでしょうか？

* コンストラクタ・デストラクタの中で例外が発生するコードは書かない
* goto は使わないようにしましょう
* グローバル変数は使わないようにしましょう
* 使い終わったリソースは解放しましょう
* 非公開 API は使わないようにしましょう
* obsolete がついたものは使わないようにしましょう

ぱっと思いついたものはこれくらいしかないのですが・・・

コーディング規約は読みやすく、メンテしやすいコードを書くためのもの
という考えはわたしもその通りだと思います。

開発メンバー全員がこの心がけを持っていれば、規約は少なくなると思います。
その逆の環境ではコーディング規約は増えると思います。

>　プログラマの仕事は、究極的には設計書通りにバグなしで早く動作する
>（ストレスがない動作をする）プログラムをコーディングすることだといえます。
この人、何バカなこと言ってるの？(*ﾟ▽ﾟ*)
設計書どうりに作ったらバグだらけだよ。
実力が十分ならバグのないプログラムを作るのは可能だけど
むしろ、バグの無い設計書を作るのがどれだけ大変かわかってないんじゃないの？
プログラムより設計書の方が難易度が高いから、設計書作る人のが給料高いのだよ？