ファイルごとのコード行、クラスごとのメソッド、循環的複雑度など。開発者は、すべてではないにしてもほとんどの場合、抵抗し、回避します。Joelの優れた記事があります (今すぐ見つける時間はありません)。
「くだらないコード」を自動的に識別するために、どのコード メトリクスを使用することをお勧めしますか?
このコードが「がらくた」であると開発者のほとんどを納得させることができるもの (いくつかのくだらないメトリックに私たち全員を納得させることはできません! :O))。
自動で測定できる指標のみがカウントされます。
自動化されたソリューションではありませんが、1 分あたりの WTF が役立つと思います。
(ソース: osnews.com )
コーディング スタイルに関するメトリックは、このような警告の一部ではありません。
私にとっては、コードの静的分析に関するものであり、常に「オン」にすることができます。
このようなテストには時間がかかる可能性があるため、カバレッジ テストを 2 番目のステップに入れます。
「くだらない」コードはメトリクスではなく、メトリクスの組み合わせと進化(「傾向」のように)によって検出されることを忘れないでください:コードメトリクスの魅力は何ですか? の質問を参照してください。
つまり、「「くだらないコード」を自動的に特定する」ためにコード メトリクスを推奨するだけでなく、それらのメトリクスに沿った適切な組み合わせと傾向分析も推奨する必要があります。
ちなみに、私はあなたの欲求不満を共有しています;）、そして私はトローチの視点を共有していません（別の回答のコメントで）「漠然とした質問をして、漠然とした答えを得てください」と彼は言います...あなたの質問は値する具体的な答え。
プロダクション コードの 1 行あたりのコメント アウトされた行数。一般的に、バージョン管理を理解していないずさんなプログラマーを示します。
ビルド時にコンパイラが出力する警告の数。
開発者は、自分たちに対して使用されているメトリックに常に関心を持っており、「くだらない」コードを呼び出すことは良い出発点ではありません。これは重要です。なぜなら、開発者が彼らの周りでゲームをしているのを心配している場合は、メトリクスを彼らの有利/不利になるものに使用しないためです。
これが最もうまく機能する方法は、メトリクスがコードのどこに問題があるかを教えてくれるのではなく、メトリクスを使用してどこを見る必要があるかを判断することです。コード レビューを行って確認し、問題を修正する方法の決定は、開発者とレビュー担当者の間で行われます。また、メトリックに対して開発者側でエラーが発生します。コードがまだメトリクスにポップしているが、レビュアーがそれが良いと思う場合は、そのままにしておきます。
しかし、指標が改善し始めたら、このゲーム効果を念頭に置くことが重要です。これで 100% のカバレッジが得られましたが、単体テストは適切でしょうか? メトリクスは私が大丈夫だと言っていますが、まだそれをチェックして、何が私たちをそこに導いたのかを調べる必要があります.
要するに、人間が機械に勝るということです。
グローバル変数の数。
存在しないテスト (コード カバレッジによって明らかに)。これは必ずしもコードが悪いことを示しているわけではありませんが、重大な警告サインです。
コメントでの冒涜。
メトリクスだけでは、お粗末なコードは識別できません。ただし、疑わしいコードを特定することはできます。
OO ソフトウェアには多くの指標があります。それらのいくつかは非常に便利です:
より多くの実行可能な指標があり、それらはツールを使用して計算できます。これは、お粗末なコードを識別するのに役立ちます。
私の個人的なお気に入りの警告フラグは、コメント フリー コードです。通常、コーダーがそれについて考えるのをやめていないことを意味します。さらに、自動的に理解しにくくなるため、くだらない比率が高くなります。
一見：コードイディオムのカーゴカルトアプリケーション。
よく見るとすぐに、プログラマーによる明らかなバグと誤解があります。
私の賭け: 循環的複雑度 (CC) と自動テスト (TC) からのコード カバレッジの組み合わせ。
CC | TC
2 | 0% - good anyway, cyclomatic complexity too small
10 | 70% - good
10 | 50% - could be better
10 | 20% - bad
20 | 85% - good
20 | 70% - could be better
20 | 50% - bad
...
crap4j - 可能なツール (Java 用) と概念の説明... C# に適したツールを探しています :(
誰もcrap4jについて言及していないことに驚いています。
残念ながら、私が知っている指標はありません。心に留めておくべきことは、あなたが何を選んだとしても、プログラマーはシステムを操作してコードの見栄えを良くするということです。あらゆる種類の「自動」メトリックが配置されていることを私は見てきました。
意味のあるコメントに対する価値のないコメントの数:
'Set i to 1'
Dim i as Integer = 1
文字列との間の多くの変換。一般に、これは開発者が何が起こっているのかを明確に理解しておらず、何かがうまくいくまでランダムなことを試しているだけであることを示しています。たとえば、次のようなコードをよく見かけます。
object num = GetABoxedInt();
// long myLong = (long) num; // throws exception
long myLong = Int64.Parse(num.ToString());
彼らが本当に望んでいたのは：
long myLong = (long)(int)num;
そのような指標はないと思います。想定されていることを実際に実行しないコード (これはまったく余分なレベルのくだらないことです) を除いて、「くだらない」コードとは、保守が難しいコードを意味します。これは通常、メンテナが理解するのが難しいことを意味します。これは常にある程度主観的なものであり、悪い書き込みと同じです。もちろん、誰もがその書き方 (またはコード) がくだらないことに同意する場合もありますが、そのための指標を書くのは非常に困難です。
さらに、すべてが相対的です。速度の最後のサイクルごとに最適化された最小限のメモリで非常に複雑な関数を実行するコードは、制限のない単純な関数と比較して非常に見栄えが悪くなります。しかし、それはくだらないことではありません - やるべきことをやっているだけです。
時々、あなたはそれを見たときにそれを知っているだけです。たとえば、今朝私は見ました：
void mdLicense::SetWindows(bool Option) {
_windows = (Option ? true: false);
}
「なぜ誰かがこれをするのか」と自問しなければなりませんでした。
さて、コードが良いコードであるかどうかを指摘するために使用できるさまざまな方法があります。以下はそれらのいくつかです：
凝集性：まあ、クラスであろうとメソッドであろうと、コードのブロックが複数の機能を提供していることがわかった場合、コードの凝集性は低いことがわかります。凝集性が低いコードは、再利用性が低いと言えます。これはさらに、保守性の低いコードと呼ぶことができます。
コードの複雑度：McCabeの循環的複雑度（決定ポイントの数）を使用して、コードの複雑度を決定できます。コードの複雑度が高いと、使い勝手が悪い（読みにくく、理解しにくい）コードを表すために使用できます。
ドキュメント：ドキュメントが不足しているコードは、コードの使いやすさの観点から、ソフトウェアの品質が低いことに起因する場合もあります。
コードレビューのチェックリストについては、次のページをご覧ください。
TODO:生産コードのコメント。開発者がタスクを最後まで実行していないことを示すだけです。
冒とく的な表現を含むコメントと含まないコメントの比率。
高い = より良いコード。
30 個の引数を持つメソッド。Web サービスで。それだけです。
私は多層アプローチを採用し、最初の層は合理的な読みやすさであり、解決される問題の複雑さによってのみ相殺されます。可読性テストに合格できない場合、私は通常、そのコードはあまり良くないと考えます。
コード カバレッジにはある程度の価値がありますが、それ以外の場合は、コードのプロファイリングに頼って、コードが粗悪かどうかを判断する傾向があります。
コメント行 / コード行
value > 1 -> bad (too many comments)
value < 0.1 -> bad (not enough comments)
自分の経験に応じて数値を調整してください;-)
The Code CRAP Metricに関するこの愉快なブログ投稿は役に立つかもしれません。