エントリーの編集
![loading...](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/common/loading@2x.gif)
エントリーの編集は全ユーザーに共通の機能です。
必ずガイドラインを一読の上ご利用ください。
記事へのコメント0件
- 注目コメント
- 新着コメント
注目コメント算出アルゴリズムの一部にLINEヤフー株式会社の「建設的コメント順位付けモデルAPI」を使用しています
![アプリのスクリーンショット](https://b.st-hatena.com/bdefb8944296a0957e54cebcfefc25c4dcff9f5f/images/v4/public/entry/app-screenshot.png)
- バナー広告なし
- ミュート機能あり
- ダークモード搭載
関連記事
コーディング規約再考 - うっくつさん本を読む。
http://d.hatena.ne.jp/bleis-tift/20090804/1249389793の話。 確かに元のコーディング規約は突っ込みど... http://d.hatena.ne.jp/bleis-tift/20090804/1249389793の話。 確かに元のコーディング規約は突っ込みどころが多い。Javaの規約をそのまま持ち込むという時点で規約項目の検討が甘いことは想定できるし、実際の突っ込みも納得できるものが多い*1。 このコーディング規約についてメタレベルの突っ込みを入れてみよう。 チェック法の規定がない。 コーディング規約を守っているかどうかをチェックする方法を規定していない。典型的な検査法にはそれぞれ問題がある。 目視検査 圧倒的に労力の無駄。 抜き取り検査 品質保証であって品質保障ではない。 自動検査 品質保障として使えるが、判定条件を作れるかが疑問*2。 想定される最悪の事態は「何か問題が発生してから遡及してチェックする」という手法だ。品質保証ですらない。 設計に関する内容が含まれている。 設計に関する内容とい