前半の続き。
- 感想
- 命名パターンよりアノテーションを使おう
- メソッドの最初でパラメータの正当性をチェックする
- throwがあるときはその条件をJavadocへ書く
- メソッドのシグニチャは慎重に作ってね
- オーバーロードするときは、それがオーバーライドでできないか考えて
- 可変長引数を使うときは第一引数に引数をつけたほうがいい
- 配列を表示するときは
- 配列とかコレクションを返すメソッドがnullを返すのはヤメよう
- ドキュメントコメントをしっかり書こう
- ローカル変数のスコープを最小限にしましょう
- ライブラリを積極的に使いましょう
- 正確な計算がしたかったらint、long、BigDecimalを使うこと
- 他の型が使えるところで文字列を使わない
- 文字列結合には + ではなく StringBuilder を使いましょう
- 最適化するな
- 命名規約を守ること
- 例外処理を通常の制御フローで使うな
- 熟練者の特徴のひとつは、コードの再利用を高いレベルで行うことに熱心である点
- 例外を投げたあと、メソッドの呼び元が例外から回復することを考慮すること
- マルチスレッドに関する項目
- シリアライズに関する項目
感想
命名パターンよりアノテーションを使おう
@Test public static void m1()
の@部分のことをアノテーションっていうそうだ。うん? デコレータのこと? って思ったけど、ちょっと違うみたい。まあつまりは、testM1()、testM2()、みたいな名前を使うよりも @Test m1()、@Test m2()、みたいな書き方をしたほうがクールってことでいいんじゃないかな。
メソッドの最初でパラメータの正当性をチェックする
確かにこれは必要だと思ってた。strを期待してるところにintがきてないか、とかそういうチェックをしろってことだよね。
throwがあるときはその条件をJavadocへ書く
raiseがあるときはその条件をdocへ書く、って言い換えてよさそう。
メソッドのシグニチャは慎重に作ってね
メソッド名はわかりやすく。メソッドをたくさん作りすぎない。パラメータは4個以下にする。同じ型のパラメータを何個も続けないこと。booleanよりもenumを用意すること。どれもなるほどって感じ。
オーバーロードするときは、それがオーバーライドでできないか考えて
引数デフォルト値を作りまくってるときは、メソッドのオーバーライドで代用できないか考えて、と言い換えてよさそう。
可変長引数を使うときは第一引数に引数をつけたほうがいい
(int... args)
じゃなくて (int a, int... otherArgs)
にしよう。
配列を表示するときは
System.out.println( Arrays.toString(target) )
配列とかコレクションを返すメソッドがnullを返すのはヤメよう
クライアント側にnull判別コードが必要になるのを防ぐため。nullを返す代わりにから配列を返しましょう。いまさらだけどnullってのはpythonのNoneのことか。
ドキュメントコメントをしっかり書こう
メソッドの事前条件、事後条件、投げる例外について。Javadocには引数とか返り値とか例外のフォーマットがあるみたいだけれど、pythonってそういうのないよね。どうすればいいんだろ。
ローカル変数のスコープを最小限にしましょう
俺も最近はプログラムのパッケージ化に慣れてきたし、こういう流儀はよく理解できるぜ。
ライブラリを積極的に使いましょう
「すべてのプログラマは java.lang java.util java.io の内容を知っておけ」「ライブラリのコードはきみの書くコードより優れている」。耳が痛い。ついつい車輪の再発明をしちゃうんだよねー。もうすでに誰かが作っていそうな機能は、積極的にググろう。
正確な計算がしたかったらint、long、BigDecimalを使うこと
9桁まではint、18桁まではlong、それ以上はBigDecimal。
他の型が使えるところで文字列を使わない
これはさっきの、「int enum じゃなくて enum を使いましょう」に似てる。わかる。
文字列結合には + ではなく StringBuilder を使いましょう
Javaの + による文字列結合は遅いんだって。だからプログラム内でなんべんも呼び出される文字列結合があれば、そこは StringBuilder を使ったほうがいいようだ。
最適化するな
この最適化ってのは、「もっと処理を速く」を追い求めることみたい。で、素人がそういうのやると大抵失敗するからヤメとけ、「速いプログラムより良いプログラムを書きましょう」とのこと。
命名規約を守ること
俺はわりとpythonの命名規約を破ってる。とくにモジュール名。pythonのモジュール名はスネークケースで書くべきらしいんだけど俺はキャメルケースで書いている……。なんか格好いいから。けれどまあ、いちどしっかり命名規約、コーディング規約に従ってみるのも楽しめるかも。
例外処理を通常の制御フローで使うな
これは昔よくやったなあw 文字列の数値チェックがやり方わからないから、計算でエラーが出たらそれは数値じゃないとして扱う、とか。そういうことはヤメましょうとのこと(当然だ)。でも当時の、「知ってる技だけでなんとかした」っていうのはよかったと思う。
熟練者の特徴のひとつは、コードの再利用を高いレベルで行うことに熱心である点
これもわかるよ。コードを再利用しようとすると、高度な技術の使用を強いられる傾向にある気がする。すべての処理をベタで書くのがイヤで省略するために関数が登場したり、さんざん首を傾げたクラスやインスタンスも、基本的にコードの再利用を目指したものだと思うし。
例外を投げたあと、メソッドの呼び元が例外から回復することを考慮すること
例外を投げたオブジェクトは元の状態へ戻るのが好ましい。そういうのをエラーアトミック性っていうんだって。そして元の状態へ戻るコードのことを回復コードというそうだ。俺がraiseという文の意味を知ったのは最近のことだから、そこまでピンとこないんだけど。
マルチスレッドに関する項目
……わかんねえ!
シリアライズに関する項目
……わかんねえ!
●
いやわかんねえで終わりかよ。まあ久しぶりのプログラミング本で楽しめた。活かして今後は、「ドキュメントをしっかり書く」「規約に従う」「コードの再利用に努める」あたりを実践してみよっかな。