堅牢なコーディングルールを策定する方法(2) - 都元ダイスケ IT-PRESS
いやー、なんか怖い人（笑）が見てるようだ。突っ込み激しそうぜよｗ さて、前回言っていた「判断ロジック」についての答えは各自考えてみただろうか？ 各方面の反応を見ると「1〜4どれでしょうか*1」という問いにすり替わっちゃってる気がするけど、テーマは「1〜4を決めるロジックを考えてください」なんだ。書き方悪かったもしれんｗ まぁつまり、昨日のエントリの時点では1〜4どれでもないのですよ。判断ロジックがないので。 というわけで本題。アプリケーションレベルでのバグとは「実際の挙動が仕様と違うとき」ですね。挙動があるべき姿(=仕様)と違う時にそいつバグとするのが妥当です。そしてそれはコードレベルでも同じ基準で良いんじゃないでしょうか。 じゃあ、仕様とは何か。Javadocコメントですよ。Javadocがないとバグの定義さえもできないんです。だから口酸っぱくJavadoc書けとｗ*2 まぁつまり「Ja
Javadocを書く - しげるメモ
最近は時間を作ってEffective Javaの2版をよんでます。 Effective Java (Java Series) 作者: Joshua Bloch出版社/メーカー: Prentice Hall発売日: 2008/05/08メディア: ペーパーバック購入: 6人 クリック: 65回この商品を含むブログ (42件) を見る ほとんど1版と同じ内容ですが、"Item 44: Write doc comments for all exposed API elements" を読んでよくまとまってるなと思ったので、触発されてメモがてらに私のやり方を。 引用の2段落目は基本的に超約。 どこに書くか If an API is to be usable, it must be documented. ユーザが利用可能なすべてのAPIにJavadocを書く。 これはとりあえず必須だと思います。ち
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
