最近私が開発作業をしていて感じたことを少しまとめておきます。
あまりためになるような話ではないかもしれませんが、
世間話くらいの感じで読んでいってください。
きっかけ：SQL Serverと他のデータベースの違い
SQL Serverでは、SQLのSELECT句ではBoolean型を指定することはできません。
…と急に言われてもピンと来ないかもしれませんね。
例えば、こんなSQLを書いたとします。
SELECT 1 = 0 AS 結果;
１と０が同値かどうか（当然falseですね）を結果列に表示するSQLです。
他のデータベースでは問題なく動作しますが、
SQL Serverではそもそも構文エラーとなります。
IIFやCASEで０１の数値として指定すれば似た動きはできるので
デメリットと言うほどではないですが、少し不自由を感じた仕様でした。
不自由はメリットにもなる
不自由、つまり選択肢が少ない状況は直感的には悪く感じますが、
捉え方や活かし方によってはメリットにもなります。
例えば、C#やVB.NETはクラスのオーバーライドをデフォルトでは禁止されています。
オーバーライドを簡単に説明すると、
元々あるクラスをもとに、動きを少し変えたり足したりして改造版クラスを作るというものです。
上手に使えば便利ですし、これぞオブジェクト指向！って感じですが、
闇雲に使ったりよく理解せずに使ったりすると
かえって読みにくくて修正しにくいクソコードになります。
そうならないよう共通機能を作るときはオーバーライドを禁止する方は多そうですが、
言語によってオーバーライドを許可・禁止する方法が微妙に違っているという話です。
何が言いたいかというと、
書き方が制限されると、自然と統一感のあるプログラムになるのです。
同じような処理を書く場合でも、人によって書く内容にはズレが生じます。
そしてそのズレは時限爆弾のようにテストや保守の段階になってから響いてくるものです。
チーム開発においては独自の言語を作るレベルで共通機能をガチガチに作りこんで、
下っ端プログラマーの書き方を狭めてあげた方が作成物やプロジェクト的には良いと言えるでしょう。
（でもそうすると下っ端の言語理解が～成長が～と別な話が長くなりそうなので今回はここまで）
まとめ
チーム開発の中では、統一こそが正義です。
「俺がこの現場に新しい風を吹かせてやるんだ！」と突飛なコードを書くのはやめておきましょう。
コーディングルールを読んで、人の書いたコードをチラチラ見て比べて、
まるで一人が書いたかのような統一感のあるシステム開発を目指しましょう！