全ての崩壊は争いから始まる。

とりあえず思いついたもののまとめ。

まずは、ベーシックなものから。

* 変数のスコープをなるべく狭くしろ
* 同じロジックのコードを2度以上書くな
* 汎用コード内で条件分岐コードを減らせ
プログラミングテクニックのまとめ - プログラミング日記

「変数のスコープは狭いほど良い」と妄信する
「同じロジックのコードを2度以上書くな」と妄信する
「同じロジックのコードを2度以上書くな」と妄信する
中途半端に優秀なプログラマが「正しいプログラミングテクニック」だと妄信しがちな３つポイント - 分裂勘違い君劇場

うーんと，30点．「もう少しがんばりましょう」レベル．初心者が惑わされると可哀想なので，一応突っ込んどく．
ちょっと囓っただけの素人が自分を過信して陥る三つの罠？ - カレーなる辛口Javaな転職日記

プログラムは人間の思いとは裏腹に、ただただ冷徹に書かれたコードの通りに動く。 その淡々たる様に反して、プログラミングというのはあまりに曖昧で、プログラミングテクニックと呼ばれるものは皆、ごくごく微妙な且つ大量の前提条件のパラメータによって、適用の可否が分かれる。 以下の３つの事項は、90%以上の前提条件のもとで、正しいのだが、ごく稀にそれを適用しない方が良いという例外事項がある。
中途半端に優秀なプログラマが「迷信」だと思いこみがちな３つの「正しいプログラミングテクニック」 - プログラマーの脳みそ

開発毎に明確にコーディング標準を決めて、みんなでルールに従えばいいんじゃないのか？
変数のスコープとか、同じコードを何回書くかとか、正しい答えなんてないんじゃないのか？

とりあえず、これだけは言える。
万が一開発の真っ最中にこんな論争が始まったらやってらんねぇ

ただ、開発時のメンバーの思想はきっとこの数多のブログのようにバラバラで、
異なる信条を持っているのだろう。それが分かった事は非常に大きな収穫ではないだろうか。

そして、こんな争いがプロジェクト期間中に始まらないようにするのが、PMの役目と言うことなのか？
それとも、このレベルの争いは実装リーダーが何とかしろと言う事で、予め注意させる方か？