うは，すごい長文お疲れ様です．
クラスは型である
グローバル変数を使用していたコードをローカル変数を使用する方法に改良して、さらに最終的には「より良いコード」としてひどいコードを紹介している。
あー・・・．完成形のコードとして見るならこれはひどいと言わざるを得ない．「より良いコード」というか「先の例よりもマシなコード」を示そうというのならば，どの悪い点を改良したのかを明示してあればよかったんだけど．それにしても
void getTopLeft()
{
cout << "左上のX座標>";
cin >> x1;
cout << "左上のY座標>";
cin >> y1;
}
これは三瞬（なんだこれ．ああそうか．いや違う．ああそうかそうか．いやいや違う．ああーそうかそうかってええー）何をしているのかわからなかった．「クラスは型である（特にC++では！）」はオブジェクト指向の大原則ではなかったの？
はて，「クラスは型である」はどれくらいの範囲で成り立つ原則なのかな．これが成り立つ言語と成り立たない言語をまとめた記事が読みたい（他力本願ｗ）．
コメントアウトが許される場面もあるかも
コメントアウトして残しておくよりも、バージョン管理システムを使ったほうがいいと思う。
編集中のコードにノイズものらないし、完璧に元に戻すことも出来る。
コメントアウトよりよっぽど便利じゃないか。
ですよね−．しかしながら，これだけ「コードをコメントアウトして残す」が広く行われている以上，そこに何らかの利点があると考えざるを得ないのでは*1．
人が書くコードはその人が初心者から上級者になるまで徐々に洗練されていくものであるのは当然のことですが，そもそもコードというものは徐々に洗練していって完成に至るもの・・・だと思うのです．コードを書いてる途中で設計のまずさに気づいたりすることはありませんか（僕はしょっちゅうあります＞_＜；）？
せっかく書いたコードを消してしまうのはもったいない・・・．そういうときにコードをコメントアウトして残してしまう場合はきっと多いのではないでしょうか．コードスニペットは関数化がそぐわないような定型文の再利用が主眼だと思いますし，もったいないコードはどのように残しておくのがいいんでしょうね−．
難しいことを砕いて教えるには
よく，初心者にとって難しいことを教えるとき，そのままでは理解してもらえないので砕いて教えることがあります．このとき，教える手法として「別の観点における間違いが含まれているが妥協する」という手法が採られることがあります．プログラミング関係の書籍ではこの手法は極度に嫌われることが多いように思います．ある説明に別の観点における間違いが含まれるがしかし今はその点の話をする場面ではないので据え置くという場合には，そのように説明の主眼や言及範囲を付記しておくようにしたいものです．
