Java読書会BOFでは昨年10月からClean Codeを読み始めています。
- 作者: Robert C. Martin,花井志生
- 出版社/メーカー: アスキー・メディアワークス
- 発売日: 2009/05/28
- メディア: 大型本
- 購入: 27人 クリック: 914回
- この商品を含むブログ (83件) を見る
第3回（12月開催）の補足
前回の12月は、ソースコードの書式化、例外といったことろで議論が活発に行われました。
書式化については、開き波括弧の位置（行末か行頭か）、そしてインデントを空白文字かTAB文字かについて、やはり議論となりました。
開き波括弧の位置については、ウィキペディア「字下げスタイル」に流派が幾つか紹介されています。
インデントに空白文字かTAB文字かについては、いまだに議論となります。
TAB文字の人も、TAB文字が何桁になるかはばらばらです（2桁, 3桁, 4桁, 8桁が多い）。
昨今、ソースコードはエディタ上だけでなく、Webブラウザ（リポジトリやJavadocなどのドキュメント）、コンソール（grep, diff, patch等のコマンドの出力結果）などで見ることが多いですが、ブラウザやコンソールはTABを8桁にするので、インデントをTAB文字で行い、TAB文字を8桁以外に設定していると整合がとれなくなってしまいます。
TAB文字を好む人の中には、空白文字によるインデントは、インデントのたびに多量の空白文字をキーボードで入力しなければならない非常識な規約と思っている人がいるのでちょっと想定外でした。
例外については、お決まりのJavaでのチェック例外悪玉論で、「Clean Code」の著者Robert C. Martinもその論者です。
あのときはチェック例外はすばらしい考えだと思っていました。実際、確かに利点もあります。しかし、堅牢なソフトウェアの開発には、必ずしも必要でないことが明らかになりました。C#にはチェック例外はありません。果敢な試みにもかかわらず、C++にもありません。Python、Rubyにもありません。こうした言語でも堅牢なプログラムは書けるのです。
（「Clean Code」p.153より抜粋）
他の言語にないから不要、という論調には同意できそうにありません。「オブジェクト指向プログラミングの機能がなくてもC言語でもオブジェクト指向プログラミングができるのです。」という論調に思えてしまいます。
Martin氏が挙げるチェック例外の問題点は次です。
チェック例外の代償は、開放／閉鎖原則に違反する点です。もしもあるメソッドでチェック例外をスローし、3レベル上の呼び出し元でキャッチした場合、そのキャッチとの間にあるメソッドすべてのシグネチャに例外を追加しなければなりません。
以前からチェック例外については否定的な意見ばかり見かけていたので（たぶん言語仕様にある機能なので、異論を持たない人はとりたて賛同を表明しないからかかと思いますが）、チェック例外の是非について調べてはてな日記に書いたものがあります。
第4回（2014-01-18開催）について
「Clean Code アジャイルソフトウェア達人の技」を読む会第4回は、1月18日（土）開催です。
今回は、第8章 境界、第9章 単体テスト、第10章 クラス、第11章 システム、第12章 創発 になるかと思います。
第8章 境界は、APIの考え方・設計について
第10章 クラスは、カプセル化・単一責務の原則・凝集性・変更への備えについて
第11章 システムは、使用と構築の分離からDI、関心事の分離（アスペクト）、ドメイン特化言語について
が書かれています。いよいよこの本の佳境です。
Java読書会の開催案内／申し込みは次のURLからです。興味のある方はお気軽に参加ください。
http://www.javareading.com/bof/
