例外について色々と考えてみた - ぐるぐる～
オブジェクト倶楽部、コーディング規約の会の「C# コーディング標準」の駄目なところ - ぐるぐる〜から派生して、 「他の例外クラスを継承しただけの例外クラスを作らない」に不同意の理由 - Diary of Dary、 例外クラスの指針 - 猫とC#について書くmatarilloの雑記や、さらには Twitter で Java の検査例外と非検査例外についての議論へと発展したので例外についてまじめに考えてみた。 あくまで、今の自分の考えなので真に受けない方がいいかも！そもそも経験が少ないので、トンチンカンなことを言ってるかもしれません。 あ、それと、用語は基本的に Java から取ってきています。ただ、メソッドじゃなくて関数を使っているけど、これに深い意味はありません。多分。 例外とは まず、例外とは一体何者なのか、ということ。 ここでは面倒を避けるために、Meyer 先生の定義を借りること
コーディング規約再考 - うっくつさん本を読む。
http://d.hatena.ne.jp/bleis-tift/20090804/1249389793の話。 確かに元のコーディング規約は突っ込みどころが多い。Javaの規約をそのまま持ち込むという時点で規約項目の検討が甘いことは想定できるし、実際の突っ込みも納得できるものが多い*1。 このコーディング規約についてメタレベルの突っ込みを入れてみよう。 チェック法の規定がない。 コーディング規約を守っているかどうかをチェックする方法を規定していない。典型的な検査法にはそれぞれ問題がある。 目視検査 圧倒的に労力の無駄。 抜き取り検査 品質保証であって品質保障ではない。 自動検査 品質保障として使えるが、判定条件を作れるかが疑問*2。 想定される最悪の事態は「何か問題が発生してから遡及してチェックする」という手法だ。品質保証ですらない。 設計に関する内容が含まれている。 設計に関する内容とい
オブジェクト倶楽部、コーディング規約の会の「C# コーディング標準」の駄目なところ - ぐるぐる～
C# のコーディング規約としては、オブジェクト倶楽部のもの (PDF) が有名だけど・・・正直、これ使いたくない。 冒頭に「このドキュメントは Java コーディング標準(オブジェクト倶楽部バージョン)、VB.NET コーディング標準を C#用に変更したもの」なんて堂々と書いてる時点で・・・ で、この規約のどこが駄目なのか、なぜ駄目なのか、どうすればいいのかをまとめてみた。 なんだかんだで長文エントリ。 追記： ちなみに、C# の規約としてはクラス ライブラリ開発者向けのデザイン ガイドラインで十分だと思う。 更に追記： ブコメで教えてもらったんだけど、どうやらクラス ライブラリ開発のデザイン ガイドラインの方が新しいらしい。 2. ファイル構成 (1) ファイル名 public クラスはそのクラス名の 1 ファイルにする。 例：public class Customer は、Custom
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
コマンド ピクチャ演算子
