やっぱ、仕事でJavaやる人はEffective Javaは読んでおくべきだと思うよ。 - sawatの日記
めずらしく仕事の話なのですが、なんか年明けから他部署に出稼ぎに行かされています。で、その仕事の内容というのが「別の誰かがつくった膨大なJavaソースにJavadocを書き込む」という訳の分からないことをやらされています。しかも、そのJavadocというのが普通のクラスやメソッドの外部仕様について書くのではなくて、完全な内部仕様でほとんどソースの和訳みたいなのを書かなきゃいけないという･･･。年頭からいったいどうやってやる気を奮い立たせればいいのか分からなくなってきます。まったく。 まあ、とにかくソースを読んでがんばってJavadocを書いてるわけなのですが、人のコードを見るとどうもアラに目がいってしまいエントリのタイトルの通りに思うわけですよ。ハラに溜めておくのは精神衛生上よくないと思うので、気づいたのをここに列挙してみます。 列挙する nullでないことが確定されている変数をnullチェ
堅牢なコーディングルールを策定する方法(2) - 都元ダイスケ IT-PRESS
いやー、なんか怖い人（笑）が見てるようだ。突っ込み激しそうぜよｗ さて、前回言っていた「判断ロジック」についての答えは各自考えてみただろうか？ 各方面の反応を見ると「1〜4どれでしょうか*1」という問いにすり替わっちゃってる気がするけど、テーマは「1〜4を決めるロジックを考えてください」なんだ。書き方悪かったもしれんｗ まぁつまり、昨日のエントリの時点では1〜4どれでもないのですよ。判断ロジックがないので。 というわけで本題。アプリケーションレベルでのバグとは「実際の挙動が仕様と違うとき」ですね。挙動があるべき姿(=仕様)と違う時にそいつバグとするのが妥当です。そしてそれはコードレベルでも同じ基準で良いんじゃないでしょうか。 じゃあ、仕様とは何か。Javadocコメントですよ。Javadocがないとバグの定義さえもできないんです。だから口酸っぱくJavadoc書けとｗ*2 まぁつまり「Ja
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
