コーディングに関する発言でありがちな発言の例を書いてみました。
「引数にconstがついてないなんて、気にしてんじゃねえよ。ちゃんと動けば問題ないだろう。」
間違っている理由：
ソースコードは、コンパイラのために書くのではなくて、コードを保守・追加開発する同僚のために書くものです。読みやすさは、人のために必要です。引数にconstが書いてあれば、それが入力であって、値が変わることがないことが、誰にでも自明なものになります。
「引数にconstがついてないけど、ドキュメンテーションコメントで@param[in] p1 cv::Point と書いてあるんだからいいだろう。」
間違っている理由：
ドキュメンテーションコメントは、const修飾子の代わりになりません。
const 修飾子がついている引数を関数内部で値を書き換えようとすると、コンパイラがエラーを返します。
ドキュメンテーションコメントは、嘘を書いても、コンパイラはチェックをすることがありません。ある時点では正しかったドキュメンテーションコメントが、いつの間にか古くなって正しくなくなることがあります。ですから、const属性をつけることが可能な引数には、必ずconst属性をつけることです。
「余分なヘッダファイルのincludeがあったってかまわないだろう。」
間違っている理由：
ヘッダファイルで余分なincludeをしていると、単体テストがしづらくなります。単体テストをしやすくするためには、極力小さなモジュールとして、その範囲でテストをすることです。余分なincludeがあると、テストしようとする対象に影響を与えるファイルの数が増えてしまうのです。単体テストをしようとするならば、余分なヘッダファイルのincludeは少しでも減らしたくなっていくはずです。
「参照渡しじゃなくて、ポインタ渡し使っているからって気にしなくていいだろう。」
間違っている理由：
ポインタ渡しは、引数の意味がいろんな意味を持ちえます。それに対して参照渡しでは、意味が明確です。意味が明確な分だけ、そのコードを読む人、利用する人は使い間違えることが減ります。ささいなことに思うかもしれませんが、ささいなことの積み重ねが、読んで理解しやすいコードと、理解しがたいコードの違いを生みます。
参照渡しで書いてあるソースコードは、ポインタ渡しで書いてあるコードよりも間違ったコードを書きにくくなります。参照渡しをしていると、NULLポインタの心配がないことの1点でも得をした気分になります。
「不要なコードを削除しているだって、そんなことより、新しい実装の部分を早く書けよ。」
間違っている理由：
不要なコードがあることは、ソースコードの理解を妨げることになります。不要なコードがあれば、不要なコードに対する保守が発生します。不要なコードに対するテストを書かなければなりなくなります。コードのカバレージがあがらなくなります。不要なコードがいっけん、もっともらしいコードとしてあると、目的の本物のコードを保守しているつもりが、使っていないコードの側をいじっていただけになって、貴重な自分の時間を失ってしまいます。
「コードがきたないだと。そんなことを気にしているより、さっさとコードを書け。」
間違っている理由：
ソースコードが汚くなると、次の機能の追加で間違える可能性が高まります。だから、コードを分かりやすく、保守しやすくしておくことはとても大切です。
「データ構造が汚いだって、今までそれで書いて動いているんだから、ほっといてくれ。」
間違っている理由：
そのデータ構造を使っているために、チームとしての開発のしやすさを損なっていませんか。秘伝の奥義を理解した人だけ利用できるのをすごいだろうと思っていませんか。データ構造をわかりやすいものにすることで、同じことが誰にでも理解しやすいものになります。そのことで、間違った使い方がされなくなります。また、そのライブラリを利用したコードを書きやすくなります。だから、データ構造が汚い場合には、リファクタリングをする価値があります。
付記
一言、「Effective C++ 読め」で済みそうな…
そうなんです。
ただ、「Effective C++ 読め」で読んでくれる人ばかりじゃないのが悲しいところです。
qiita Effective C++(第3版)メモ
qiita Effective C++（項1〜5）解説
qiita Effective C++(項6〜10)解説
qiita Effective C++（項11〜15）解説
qiita Effective C++（項16〜20）解説
qiita Effective C++(項21〜25)解説
qiita Effective C++（項26〜30）解説