きれいな、読みやすいソースコードを書け、と言われたとして
ソースコードを書いてきた皆さんの軌跡はばらばらなわけです。
ある開発チームでは「常識」だった書き方も
別の開発チームでは「何だよこれ、みづれーよ」となるわけです。
インデント
半角SP4文字
半角SP2文字
Tab
で意見が分かれます(大部分は半角SP4文字でしょうか)
好みの問題もあるとは思いますが、ソースコード上混在すると見づらいことこの上なしです。
波括弧
if文の後ろにつける括弧ですが、
if(条件式) {
・・・
}
if(条件式)
{
・・・
}
2つの流派が存在します。後者はC言語を主にやってきた人が書くことが多い気がします。
条件式が真である時の実行行が1行の場合、波括弧を書かなくても言語使用上問題ありませんが、
デグレの元になるので使用は控えるべきでしょうね。
余計なimport
そのままにしておいても実害はありませんが、
警告つきのソースコードをリリースするなんて考えられない。
コメントの山
昔の実行行(と思われるもの)を後生大事にコメント化してとっておく。
(バージョン管理システム使ってるにも関わらず!)
で、そのコメントを元に戻した時用にコンパイルエラーが起きないようにimport文の整理もしない。
私は、そんなコメントがあって混乱したことはあっても元に戻したことなんかないです。
いらない実行行は消して、バージョン管理のコミットログに書いておいてくれればそれで良いのですが。
checkStyleやFindBugsで指摘されないようなコードにしようよ、としても
「たくさん警告が出て全部直すのは時間がかかるし、Eclipseが遅くなるから」
とかいう(訳のわからない)理由で切ってしまう。
そりゃーできるひとはどんなコーディングスタイルでも読めるかもしれないですがね、
そうでない人が後を引き継ぐことの方が多いわけですよ。
最初にソースコード書いた後、変更もされないし見られもしないなんてものはないんですから。
実行行が少ないから良いソースコードか、っつうとそんなことないと。
メンテするのは最初にソースコードを書いた人か、っつうとそんなことないと。
手離れの良いソースコードを書ける人がいいなぁ。
動くから問題ないだろうというスタンスでソースコード書かれるとキツイッすね。
現状を悔やんでもしょうがないので、チーム内でコンセンサスを取ってからやりましょう。
ソースコードはみんなの目に晒されてよりよくしていくもの、と思わないと。
ただ、私は自分のソースコードに無断で修正されるのをひどく嫌いますが(笑)
