プログラミングのルールは絶対でなく、臨機応変に　（現場ルール）

正当な理由があればどんなルールにも例外を認める方が効率的である。たとえば、Ｃ言語で多重ループしていて、一気にループを抜けるのにgoto文なんかを使うのはスマートだと思われる。前提条件によるが多重ループの必要性があって、一気にループから抜けないとダメなら、そうするのがベストである。ここで、ルールを何も考えずに適応するのはよろしくない。

１.変数のスコープは小さい方が良いのはよい。

これは変数のスコープが大きいのは良くないと言ってるわけではなくて、変数のスコープが大きいものは少ないほどよいと言うぐらいなものである。言語仕様や用途によって違うとは思う。スコープが小さくて困ることはまずないけど、大きいと困ることもあるというぐらいだと思う。小さい方がよい。

２.DRY = 同じロジックのコードを2度書くな

私のプログラムは、コピペで大半ができています。以前に書いたコードの一部をコピーして一部書き換えるとかそういうことが多いような気がします。同じロジックを２度書くなというのは、現場向きだとは思えないなと思う。

3.プログラミング言語のキワミ、アー!

時間の無駄かなと思う。現場向きじゃないと思う。言語仕様なんか細かいものがいっぱいあるから、なるべく危なさそうなものは使わないで組み立てていけたら、極めるなんてことしなくてもよいとは思う。Ｃでポインター分からないのなら、使わずに書けばよいと思う。

しつこいほどくりかえす。ユーザー視点において、 What to Code に比べたら、 How to Code などブロックをendで閉じるか}で閉じるかほどの意味しかないことを。
しかし、その差が気にならない人が良いプログラマーになるということもまずないのだけれども。
そろそろ3つのポイントについて「弾言」しとくか（404 Blog Not Found）

各自自分自身でよく考えてみましょう。考えないのが一番よくない。
よきプログラマーはきれいで整形されたソース（プログラム）を書く人ではないと私は思ってます。