(データマイニング班) コードレビュー終了

			<blockquote class="twitter-tweet">

青空の有効活用 pic.twitter.com/KHYlZGcsJV

— Naruaki TOMA (@naltoma) February 4, 2016

つかの間の晴れ間が。いいタイミング（昼食で食堂行こうと思ったタイミング）で晴れ間が少し広がったので、（ほんの数分）少し足伸ばして一人撮影大会してました。やっぱり日光＋青空の下だとより映えるなぁ。もっと接写したいんだけど、今回ぐらいでもピンぼけ気味だな。やっぱりそれなりのカメラが必要か。

先週(2/2)の時点で近いうちに「コードレビューするぞー。」と伝えていたにも関わらずリポジトリに殆どコミットがないorゼロな学生がいて。しくしく。作業レビューした限りではそれなりには書いてたからローカルで作業してるのは知ってるんですが、ちゃんとバージョン管理使えよ！

コメントを英語で書いてるグループは初めて見ました。エライ。

以下、比較的共通してたツッコミ一覧。

• まず何を見たら良いのかわからない。（トップ階層にtxtファイルありすぎ、整理されていない。どれがドキュメントかわからない）
• 実験再現手順がわからない。
• __pycache__ は自動生成されるのでリポジトリには含めない方が良い。（.hgignore使おう）
• 関数定義の前後、ブロックの後は空行を入れよう。
• 余程の理由がない限りglobal 利用は避けよう。多くの場合は各関数の引数として渡すか、クラス変数として設計し直せるはず。
• ファイルや関数の説明は docstring / sphinx / doxygen 形式で書こう。
• 関数上部とかではなく、コード中にコメント書くのは最小限にとどめよう。特に「コードの後ろにコメント」が大量にあると、コードが読みにくくなります。
• ループに関連する変数の初期化はループの直前でやろう。離れすぎると意図がわかりにくくなります。
• 関数定義を挟む形で、前後にコードを書くのは辞めよう。本来連続して処理すべきコードが離れてると読みにくい。
• クラス名・関数名・変数名から何をするか想像できないので、適切な名称付けよう。
• マジックナンバーを含め、ハードコーディングはできるだけ避けよう。コードを再利用性しづらいし、利用しようとした時点で直接コード書き直しの手間が入るので、トラブルのもとになる。
• readlines() は避けよう。対象が大きすぎるとメモリ不足で死ぬので、readline()で1行ずつ処理するように書きなおしたほうが良い。
• open() は、その後で close() し忘れることがあるので with 構文使うとベター。
• 不必要に変数を増やさないようにしよう。対象が長すぎて省略名で繰り返し使いたいとか理由があるなら良いが、不必要に変数増やすとそれだけ読みにくくand/orバグの温床になる。
• キャストするだけの関数は逆にコード増えてしまうので辞めよう。それ以外にも処理あるならわかる。
• インデントを統一しよう。