04:48まだ「完全に確定」してはいないけど。現在のものが「箸にも棒にもかからない」ことはなくて、「たまに使うのにはいいかも」はほぼ自分的には評価確定。ドキュメントがダメ過ぎるということが一番大問題で、なんというか「言われたからチェックしてみました」というチェックをして「叱られたから直します」というバカ向けにしかなってないような気がしてきた。あまりにもチェック結果の意味が不明過ぎる。やってくれてることがそんなに悪くないもんで後ろ髪引かれる想いもないでもないんだけれど、なんであれ「チミはいったい何を言いたいんだい?」があまりにも多過ぎて、肝心の本題(コードを良くする)方に神経が全然行かない。こりゃぁワタシにはかえってストレスだ。こっちはいちいち全部に「根拠」が説明されてるので、チェック結果の判断をしやすいし、「じゃぁどないせぇちゅうねん」も比較的導出しやすい。「多少ヘンなチェックをしてくれたとしても」、常識的な判断で適用・非適用の決断が出来る。ほかの2つは「たまにほかの観点が欲しくて気紛れに」使えば良かろう。「零点」ではないからね。追記:書く前に気付けば良かった。ドキュメント、滅茶苦茶いい。It」まで書かれてる:実際こういったもろもろの整備がなくて非常に困った経験は数知れず。いうのって、プロジェクトへの適用は注意深くやらなければいけなくて、そうしないと「叱られたから意味もわからずコードを引っ掻き回す」末端エンジニアが後を絶たないことが頻発し、あるいは「チームメンバー間の不協和音」すらもたらすことがある。「叱られたから意味もわからずコードを引っ掻き回す」と何が起こるか、なんて常識的に考えれば「当たり前のこと」しか起こらない。「スタイルを良くすることでアプリケーションをぶち壊す」。結果を受けて「修正しました」」として製品の仕様を捻じ曲げるバカも大量発生することになる。「チームメンバー間の不協和音」とはすなわちこれは「一種の技術格差」の問題である。It」みたいなことが、きちんと理論立てて説明されていないと、「このケースではスタイルチェッカーの不平を聞いてはならない」というまともな判断が出来るエンジニアの方が「非難される側」になりがちである。「厳格に従うのがルールだ!」「スタイルチェッカが不平を言うのは万死に値する!」というわけである。これが不和をもたらすことがある。(不和、というほどではなくても、後輩が「いや、だって...」とひたすらに気に病むのをなだめるのに苦労する、というような構図にもなる。系の何かだったと記憶している)。実際それは「オリジナルの英語の文書」があったので、ワタシはそれにコメントしていくようなスタイルでまとめてた、かな、確か。前のことなので詳細は全く憶えてない。したことが問題となりうるようなプロジェクトでは、これは必ずやった方がいいぞ。簡単には「こういうケースで検出された場合は対象外」という特例を明記することが最低限。「このケースではこう修正することを推奨する」という、正しい方向に導くような示唆を付けておく。これは簡単なことではないが、一定上の経験数を持ったエンジニアがこれを書くべきだろう。WordPressTop。