若作りするためのJavaコード - 谷本心 in せろ部屋

このエントリーは Java Advent Calendar 2012 の10日目として書きました。
なんか色々あって、公開が2日ぐらい遅れてしまってごめんなさい（＞＜）

前日は、Hideki Kishida (@quicy) さんの「Xtend の Lambda とストリーム処理」です。
http://legacy-style.blogspot.jp/2012/12/xtend-lambda.html

翌日は、Katsumi Kokuzawa (@kokuzawa) さんの「WiiRemoteJで遊ぼう on OSX 10.8.7」です。
http://kokuzawa.github.com/blog/2012/12/11/wiiremotejdeyou-bou-on-osx-10-dot-8-7/

どちらも今風ですね！

そんな中、若干、加齢臭が気になり始めたこの頃の私としては、
若さアピールのためのJavaプログラミングとかちょっと気にしたりするわけですよね。
イマドキのプログラミングスタイルにしなきゃいかん、的なね。

そんな同世代、あるいはもう少し上の、プログラマの定年を超えたJavaエンジニアの皆さんにも
業界に入ったばかりで、古い定石など知らないJava プログラマの皆さんにも、
ちょっと見てもらいたい、「若作りするためのJavaコード」です。

要するに、イマ風のコードを書くための注意点、ですね。
ランキングづけしていきましょう。

まずは第三位から。

第三位 : no native2ascii, no life

Javaではメッセージの外部化や国際化対応などのために、
メッセージをまとめたリソースファイルを作成して
Propertiesクラスを使って読み込むという事を、よくやります。

皆さんも一度ならず経験があると思いますが、こんな感じですよね。

public static void main(String[] args) throws IOException {
	Properties props = new Properties();
	InputStream in = Main.class.getResourceAsStream("/messages.properties");
	try {
		props.load(in);
	} finally {
		in.close();
	}
	System.out.println(props.getProperty("message"));
}

そして、ここで読み込むリソースファイルはUnicode変換しておく必要があるため
native2asciiコマンドや、それに相応する開発環境、プラグインなどを利用していたかと思います。

message=\u30c6\u30b9\u30c8

なんかもうこの一連の流れが、おっさんなわけですね。

「native2asciiが許されるのは、Java5までだよねー！」

みたいな、意外と元ネタが十分に知られていなくて、ネタだけ先行しているようなものは
けっこう滑るので注意が必要なわけですが、
Java6以降ならメッセージは別に日本語のままでも良いんです。

message=テスト

というのも、Properties#loadメソッドにReaderクラスを渡せるようになったからです。

public static void main(String[] args) throws IOException {
	Properties props = new Properties();
	InputStream in = Main.class.getResourceAsStream("/messages.properties");
	Reader reader; 
	try {
		// readerを使ってCharsetを明示！
		reader = new InputStreamReader(in, "UTF-8");
		props.load(reader);
	} finally {
		in.close();
	}
	System.out.println(props.getProperty("message"));
}

Java5までは、CharsetのないInputStreamしか利用できませんでしたが
Java6には、Charsetを指定したReaderを利用できるようになった所がポイントです。
というか、こんなの最初から用意しとけよと誰しも思っているでしょうけどね。

ちなみにPropertiesクラスを使っているフレームワーク側が
ReaderではなくInputStreamを使っていれば、結局Unicode変換しなきゃいけないんですけどね！

第二位 : リソースはfinallyでクローズする？

第二位は、「リソースはfinallyでクローズする」という鉄則です。
もう何年間も鉄則だ、定石だと教わってきました。
第三位に書いたソースも、きちんとその鉄則をきちんと守っています。素晴らしい！

「と思うやんかー？ finally不要なんよー。」

テレビCMを文字ったネタは、意外とテレビを見ない昨今は滑りやすいので、これまた注意が必要で
どちらかと言えば、ネットの流行語を取り入れた方が良いわけですが、最近はこんな風に書きます。

public static void main(String[] args) throws IOException {
	Properties props = new Properties();
	try (InputStream in = Main.class.getResourceAsStream("/messages.properties");
			Reader reader = new InputStreamReader(in, "UTF-8");) {
		props.load(reader);
	}
	System.out.println(props.getProperty("message"));
}

Java7以降はtry-with-resourcesを使うことでリソースが自動的にクローズされるため、
わざわざfinallyでクローズする必要はありません。

もう十年以上も言われ続けてきたfinallyでのクローズも、いよいよおさらばですね！

第一位 : pubilc static void main(String[] args)

ところで、mainメソッドの宣言と言えば、

pubilc static void main(String[] args)

皆さん、こうですよね。

たまに、おいたしちゃって

pubilc static void main(String args[])

こんな形になっている宣言もあったりしますが、まぁこんなもんですよね。

でも、最近の若者は、こんな風に書くらしいですよ？

public static void main(String... args)

＿人人人人人人人人人人人＿
＞　突然の可変長引数！　＜
￣^Y^Y^Y^Y^Y^Y^Y^Y^Y^￣

テンポが悪いと滑る感じにすらならないため、大けがをしかねないわけですが
確かにmainメソッドは、まさに可変長引数がぴったり合うところです。
長年 String args と宣言してくると、なかなか気づかなかったりしますよね。

いまだEclipseでのmainメソッドの自動生成は String args なわけですが
各IDEでどんなmainメソッドを作っているか調べてみたら、
ちょっとしたイマドキ判定ができるかも知れませんね！

まとめ

Before

public static void main(String[] args) throws IOException {
	Properties props = new Properties();
	InputStream in = Main.class.getResourceAsStream("/messages.properties");
	try {
		props.load(in);
	} finally {
		in.close();
	}
	System.out.println(props.getProperty("message"));
}

After

public static void main(String... args) throws IOException {
	Properties props = new Properties();
	try (InputStream in = Main.class.getResourceAsStream("/messages.properties");
			Reader reader = new InputStreamReader(in, "UTF-8");) {
		props.load(reader);
	}
	System.out.println(props.getProperty("message"));
}

・元ネタは知らないけど、ネタだけ知っている、というものは滑りやすい。
・テレビCMネタは、テレビを見ていない人が多い昨今は多用を避けること。
・突然の◯◯！　は意外性とともにテンポ良く出すこと。

トラシューネタとか言っておいて、
全然違うネタを出して、ごめんなさいね！
今度また連載にでもしますよ！

おまけ

少しだけ宣伝ですが、
日経ソフトウエアの「Javaのイケてるコード、残念なコード」という連載にて
1月号、2月号の2回に分けて
「そのコーディングスタイルはもう古い、Javaの新定石を学ぶ」を執筆しました。
http://www.acroquest.co.jp/company/press/2012/1125p1.html
http://ec.nikkeibp.co.jp/item/backno/SW1176.html

今回書いたような内容を含む、Java5からJava7あたりまでに導入された機能を使った
イマドキの書き方を紹介していますので、ぜひそちらもご覧ください m(_ _)m