Python で書かれた 100 行テトリスのえらいところはだな、 100 行という制限下で可能な限り構造化して読みやすいコードにしているところ。友人の最初に出した条件である 200 行なら、もう少し高い品質でバグの無いコードになったかも。
それでまあプレイしてみたのだが、流石に 100 行だと不具合というか変な挙動があるのは仕方がないよねといったところかな (ブロックが変な風にめり込む)。
「正しい日本語」などのような自然言語の正しさなどという物はまず存在しないが (例えば「全然」と「とても」は明治時代ぐらいには今とは逆の意味で使われていたはず。全然楽しいとかそういう風に。言葉は変化するものなんだよ)、プログラミングにおいての正しいコーディングのしかたについてはある程度正しいといえる物が存在する。というのも、コーディングの正しさというのは理解に何パスかかるかの最適化問題と言い替えることが出来るからだ。
とりあえず論理式を例に挙げる。ド・モルガンの法則によれば、以下の二行は等価である。
not (Kichigai or Hentai)
not Kichigai and not Hentaiこの論理式の場合、俺は and を使った方で記述する。これを自然言語で表現してみると
私はキチガイまたは変態ではない
私はキチガイではなく変態でもないとなり、後者の方がわかり易い。次のように XOR の条件を書くときには、そして複雑な条件を書かなければいけないときには (もっともその場合はリファクタリングした方が良い場合もあるが) より一層実感できると思う。
(Kichigai or Hentai) and not (Kichigai and Hentai)
(Kichigai or Hentai) and (not Kichigai or not Hentai)他の例を挙げると、俺は Perl を書かなければいけない場合、必ず関数の戻り値は return させる。暗黙の戻り値で済むようにコーディングしろといわれるかも知れんが、明示的な return は常にそこで関数からの脱出を意味し、その値も明示する (暗黙の戻り値は void が戻り値の場合 (つまりプロシージャ的な関数) を表現しにくいように思えるし)。 Python を書いていると、自然とそういうコーディングになると思う (Python での lambda 文は例外だが、そもそも Pythoner は lambda を多用しない。例外はあくまでも例外だ)。
こういった意味での正しいプログラムを判断するには、やはり古典的な電話テストが有効だろう。電話テストってのはそのプログラムで何をどうやりたいのかを口頭で説明して、相手が「おまえの説明はワケワカメ」という反応を返したらプログラムの内容を見直すというものだ。高度に数学的なプログラムであればこれは使えないが、普段目にするプログラムの殆どは数学の問題ではなく文章表現の問題なので結構有効に働く。
あんまり関係の無い話だが、文系理系の二分法に囚われている人にはまともなプログラムは書けないと思う。
何か大学時代の後輩から「顔色が悪い」だの「日記の内容が可愛くなった」だの屈辱的なコメントをもらった。いや、顔色が悪いのはいつもの事だし、日記の内容は単なる周期だ。