| report date | 20 Mar 2024 14:40:20 |
| analysis duration | 00:21.931 |
| ndepend version | 2024.1.0 Professional Developer/Build-Machine Edition |
| baseline | Compare with project {NDepend 2023.2.3} most recent analysis result (analysis result obtained on 20 Mar 2024 12:06:09) |
| code coverage data | Loaded! Code Coverage metrics, Queries and Rules relative to code Coverage, can be used. |
Diagrams
Application Metrics
Note: Further Application Statistics are available.
|
23![;InfoSmall.png]()
Clicking a project's name selects its associated source files under the Issues tab.
This occurs because the search pattern for the source files grid is set to the project's name.
- The number of projects with no issues.
- Sort the column #Un-resolved ascending to list these files first.
- The number of projects with at least one unresolved issue but no new issue added since the baseline.
- Sort the column #Un-resolved Issues to list these files first.
- The number of projects with at least one new issue introduced since the baseline.
- Sort the column #New Issues to list these files first.
This occurs because the search pattern for the source files grid is set to the project's name.
| Project Name | #New Issues | #Un- resolved | #Fixed | New Debt | Debt | %Cov | #Types | #Statements |
|---|---|---|---|---|---|---|---|---|
| 0 | 0 | |m100|00| 1 | 0min 0s | 0min 0s | |c94|09| 94.45% | |m100|00| 2 308 | |m100|00| 93 609 | |
| 0 | 0 | |m100|01| 1 | 0min 0s | 0min 0s | |c98|04| 98.62% | |m4|05| 109 | |m5|07| 4 749 | |
| 0 | 0 | |m0|03| 0 | 0min 0s | 0min 0s | |c100|00| 100% | |m0|22| 1 | |m0|21| 83 | |
| 0 | 0 | |m0|04| 0 | 0min 0s | 0min 0s | |c98|03| 98.94% | |m14|03| 344 | |m23|03| 22 415 | |
| 0 | 0 | |m0|02| 0 | 0min 0s | 0min 0s | |c100|01| 100% | |m0|21| 1 | |m0|20| 87 | |
| 0 | 0 | |m0|05| 0 | 0min 0s | 0min 0s | |c100|02| 100% | |m1|11| 30 | |m1|12| 1 034 | |
| 0 | 0 | |m0|06| 0 | 0min 0s | 0min 0s | |c98|06| 98.03% | |m13|04| 316 | |m9|04| 8 541 | |
| 0 | 0 | |m0|07| 0 | 0min 0s | 0min 0s | |c95|07| 95.75% | |m4|06| 101 | |m6|05| 6 287 | |
| 0 | 0 | |m0|08| 0 | 0min 0s | 0min 0s | |c95|08| 95.65% | |m0|19| 3 | |m0|22| 42 | |
| 0 | 0 | |m0|09| 0 | 0min 0s | 0min 0s | |c98|05| 98.15% | |m0|15| 10 | |m0|15| 271 | |
| 0 | 0 | |m0|10| 0 | 0min 0s | 0min 0s | |c83|10| 83.63% | |m34|01| 804 | |m28|02| 26 624 | |
| 0 | 0 | |m0|11| 0 | 0min 0s | 0min 0s | |c82|11| 82.14% | |m2|10| 50 | |m0|13| 812 | |
| 0 | 0 | |m0|12| 0 | 0min 0s | 0min 0s | |c77|12| 77.91% | |m0|13| 20 | |m1|10| 1 630 | |
| 0 | 0 | |m0|13| 0 | 0min 0s | 0min 0s | |c76|13| 76.65% | |m2|09| 54 | |m5|06| 5 497 | |
| 0 | 0 | |m0|14| 0 | 0min 0s | 0min 0s | |c75|14| 75.13% | |m26|02| 619 | |m61|01| 57 545 | |
| 0 | 0 | |m0|15| 0 | 0min 0s | 0min 0s | |c66|15| 66.84% | |m0|17| 8 | |m0|18| 196 | |
| 0 | 0 | |m0|16| 0 | 0min 0s | 0min 0s | |c66|16| 66.67% | |m0|16| 9 | |m0|16| 234 | |
| 0 | 0 | |m0|17| 0 | 0min 0s | 0min 0s | |c65|17| 65.5% | |m0|18| 8 | |m0|17| 200 | |
| 0 | 0 | |m0|18| 0 | 0min 0s | 0min 0s | |c40|18| 40.67% | |m2|08| 63 | |m2|09| 2 274 | |
| 0 | 0 | |m0|19| 0 | 0min 0s | 0min 0s | |c32|19| 32.31% | |m1|12| 26 | |m1|11| 1 149 | |
| 0 | 0 | |m0|20| 0 | 0min 0s | 0min 0s | |c16|20| 16.49% | |m0|14| 13 | |m0|14| 655 | |
| 0 | 0 | |m0|21| 0 | 0min 0s | 0min 0s | 21N/A | |m0|20| 2 | |m0|19| 100 | |
| 0 | 0 | |m0|22| 0 | 0min 0s | 0min 0s | 22N/A | |m3|07| 75 | |m3|08| 3 691 |
- The number of Quality Gates that pass.
- A Quality Gate passes if its value is lower than its warning threshold, and lower than its failure threshold.
- The number of Quality Gates that warn.
- A Quality Gate warns if its value is equal to or higher than its warning threshold, but lower than its failure threshold.
- The number of Quality Gates that fail.
- A Quality Gate fails if its value is equal to or higher than its failure threshold. If any, it means that the code is not ready for production. You have the option to stop the build process upon any Quality Gate failure.
be run on the baseline. Hence they
have blank trend and baseline value.
| Name | Trend | Baseline Status | Status | Group | |||
|---|---|---|---|---|---|---|---|
| Quality Gates | ||||||
| Quality Gates | ||||||
| Quality Gates | ||||||
| Quality Gates | ||||||
| Quality Gates | ||||||
| Quality Gates | ||||||
| Quality Gates | ||||||
| Quality Gates | ||||||
| Quality Gates | ||||||
| Quality Gates | ||||||
| Quality Gates |
- The number of CQLinq rules that are not violated. Those rules are not listed below.
- Notice that Roslyn Analyzers that pass are not imported. Thus, they are not counted in this number.
- The number of CQLinq rules marked as critical that are violated. They are listed below with a top-left red tick.
- By sorting the first column, violated critical rules can be listed first.
- Number of Rules or Queries with Error (syntax error, exception thrown, time-out): 0
Size
% Coverage and % Debt
Issues
Rules
Quality Gates
Debt
Application Statistics
| Stat | # Occurences | Avg | StdDev | Max |
|---|---|---|---|---|
| Properties on interfaces | 627 interfaces | 3.19 | 13.36 | 257 properties on NDepend.Helpers.Theming.ITheme |
| Methods on interfaces | 627 interfaces | 7.86 | 16.79 | 267 methods on NDepend.Helpers.Theming.ITheme |
| Arguments on methods on interfaces | 4,928 methods | 0.74 | 1.14 | 13 arguments on NDepend.WebSite.Base.IDatabaseOperations.RegisterNewEvaluation2(Date,Date,String,LicenseKind,String,String,String,String,String,String,String,String,UserRole) |
| Public properties on classes | 3,684 Classes | 1.58 | 12.02 | 340 public properties on NDepend.Properties.IconsResources |
| Public methods on classes | 3,684 classes | 3.72 | 14.11 | 341 public methods on NDepend.Properties.IconsResources |
| Arguments on public methods on classes | 13,717 methods | 0.83 | 1.42 | 37 arguments on NDepend.WebSite.Base.LicenseRecord.TryBuild_V7AndMore_LicenseRecord(String,String,LicenseKind,String,String,String,String,String,String,String,String,String,String,String,String,String,String,String,String,Int32,DateTime,Decimal,Decimal,String,String,Boolean,Boolean,Int32,Boolean,DateTime,DateTime,DateTime,Boolean,Expirable,LicenseRecord&,String&,String&) |
| IL instructions in non-abstract methods | 32,064 methods | 46.1 | 293.5 | 34101 IL instructions in NDepend.Core.CodeQueryImpl.CQL.Parsing.ParserHelper.GetPossibleExpressionBeginningWith(String) |
| Cyclomatic complexity on non abstract Methods | 32,064 Methods | 3.53 | 19.23 | CC = 1890 for NDepend.Platform.DotNet.AnalysisImpl.DependencyResolver.DepthOfInheritanceComputer.GetDepthOfInheritanceFrameworkType(String) |
| MyRules 000 |
| UIRefactoring 000 |
| Quality Gates 1100 |
| Quality Gate Pass: Percentage Coverage |
• Quality Gate Description:
Code coverage is a measure used to describe the degree to which the source code of a program is tested by a particular test suite. A program with high code coverage, measured as a percentage, has had more of its source code executed during testing which suggests it has a lower chance of containing undetected software bugs compared to a program with low code coverage.
Code coverage is certainly the most important quality code metric. But coverage is not enough the team needs to ensure that results are checked at test-time. These checks can be done both in test code, and in application code through assertions. The important part is that a test must fail explicitly when a check gets unvalidated during the test execution.
This quality gate define a warn threshold (70%) and a fail threshold (80%). These are indicative thresholds and in practice the more the better. To achieve high coverage and low risk, make sure that new and refactored classes gets 100% covered by tests and that the application and test code contains as many checks/assertions as possible.
Scalar Result: 87.35 %
| Quality Gate Pass: Percentage Coverage on New Code |
• Quality Gate Description:
New Code is defined as methods added since the baseline.
To achieve high code coverage it is essential that new code gets properly tested and covered by tests. It is advised that all non-UI new classes gets 100% covered.
Typically 90% of a class is easy to cover by tests and 10% is hard to reach through tests. It means that this 10% remaining is not easily testable, which means it is not well designed, which often means that this code is especially error-prone. This is the reason why it is important to reach 100% coverage for a class, to make sure that potentially error-prone code gets tested.
Scalar Result: 94.68 %
| Quality Gate Pass: Percentage Coverage on Refactored Code |
• Quality Gate Description:
Refactored Code is defined as methods where code was changed since the baseline.
Comment changes and formatting changes are not considered as refactoring.
To achieve high code coverage it is essential that refactored code gets properly tested and covered by tests. It is advised that when refactoring a class or a method, it is important to also write tests to make sure it gets 100% covered.
Typically 90% of a class is easy to cover by tests and 10% is hard to reach through tests. It means that this 10% remaining is not easily testable, which means it is not well designed, which often means that this code is especially error-prone. This is the reason why it is important to reach 100% coverage for a class, to make sure that potentially error-prone code gets tested.
Scalar Result: 84.72 %
| Quality Gate Pass: Blocker Issues |
• Quality Gate Description:
An issue with the severity Blocker cannot move to production, it must be fixed.
The severity of an issue is either defined explicitly in the rule source code, either inferred from the issue annual interest and thresholds defined in the NDepend Project Properties > Issue and Debt.
No issue matched
| Quality Gate Pass: Critical Issues |
• Quality Gate Description:
An issue with a severity level Critical shouldn't move to production. It still can for business imperative needs purposes, but at worst it must be fixed during the next iterations.
The severity of an issue is either defined explicitly in the rule source code, either inferred from the issue annual interest and thresholds defined in the NDepend Project Properties > Issue and Debt.
No issue matched
| Quality Gate Pass: Critical Rules Violated |
• Quality Gate Description:
The concept of critical rule is useful to pinpoint certain rules that should not be violated.
A rule can be made critical just by checking the Critical button in the rule edition control and then saving the rule.
This quality gate fails if any critical rule gets any violations.
When no baseline is available, rules that rely on diff are not counted. If you observe that this quality gate count slightly decreases with no apparent reason, the reason is certainly that rules that rely on diff are not counted because the baseline is not defined.
No rule matched
| Quality Gate Pass: Percentage Debt |
• Quality Gate Description:
% Debt total is defined as a percentage on:
• the estimated total effort to develop the code base
• and the the estimated total time to fix all issues (the Debt)
Estimated total effort to develop the code base is inferred from # lines of code of the code base and from the Estimated number of man-day to develop 1000 logical lines of code setting found in NDepend Project Properties > Issue and Debt.
Debt documentation: https://www.ndepend.com/docs/technical-debt#Debt
This quality gates fails if the estimated debt is more than 30% of the estimated effort to develop the code base, and warns if the estimated debt is more than 20% of the estimated effort to develop the code base
Scalar Result: 0 %
| Quality Gate Pass: New Debt since Baseline |
• Quality Gate Description:
This Quality Gate fails if the estimated effort to fix new or worsened issues (what is called the New Debt since Baseline) is higher than 2 man-days.
This Quality Gate warns if this estimated effort is positive.
Debt documentation: https://www.ndepend.com/docs/technical-debt#Debt
Scalar Result: -0.012 man-days
| Quality Gate Pass: Debt Rating per Namespace |
• Quality Gate Description:
Forbid namespaces with a poor Debt Rating equals to E or D.
The Debt Rating for a code element is estimated by the value of the Debt Ratio and from the various rating thresholds defined in this project Debt Settings.
The Debt Ratio of a code element is a percentage of Debt Amount (in floating man-days) compared to the estimated effort to develop the code element (also in floating man-days).
The estimated effort to develop the code element is inferred from the code elements number of lines of code, and from the project Debt Settings parameters estimated number of man-days to develop 1000 logical lines of code.
The logical lines of code corresponds to the number of debug breakpoints in a method and doesn't depend on code formatting nor comments.
The Quality Gate can be modified to match assemblies, types or methods with a poor Debt Rating, instead of matching namespaces.
No namespace matched
| Quality Gate Pass: New Annual Interest since Baseline |
• Quality Gate Description:
This Quality Gate fails if the estimated annual cost to leave all issues unfixed, increased from more than 2 man-days since the baseline.
This Quality Gate warns if this estimated annual cost is positive.
This estimated annual cost is named the Annual-Interest.
Each rule can either provide a formula to compute the Annual-Interest per issue, or assign a Severity level for each issue. Some thresholds defined in Project Properties > Issue and Debt > Annual Interest are used to infer an Annual-Interest value from a Severity level. Annual Interest documentation: https://www.ndepend.com/docs/technical-debt#AnnualInterest
Scalar Result: -0.083 man-days
| Quality Gate Pass: Treat Compiler Issues As Error |
// <QualityGate Name="Treat Compiler Issues As Error" Unit="issues" />
failif count > 0
context.IssuesSet.AllIssues.Where(
i => i.Rule.Provider == RuleProvider.Import &&
i.Rule.Id.StartsWith("CS"))
failif count > 0
context.IssuesSet.AllIssues.Where(
i => i.Rule.Provider == RuleProvider.Import &&
i.Rule.Id.StartsWith("CS"))
No issue matched
| Code Smells 000 |
| Hot Spots 000 |
| Code Smells Regression 000 |
| Object Oriented Design 000 |
| Design 000 |
| Architecture 000 |
| API Breaking Changes 000 |
| Code Coverage 000 |
| Dead Code 000 |
| Security 000 |
| Immutability 000 |
| Naming Conventions 000 |
| Source Files Organization 000 |
| .NET Framework Usage 000 |
| Defining JustMyCode 000 |
| Trend Metrics 000 |
| Code Diff Summary 000 |
| Roslyn Analyzers 000 |
| Failed to load rule file : RuleFile22.ndrules 000 |
| Rules in : RuleFile.ndrules 000 |
| Rules extracted from Source Code 000 |
Abstractness versus Instability Diagram
The Abstractness versus Instability Diagram helps to detect which assemblies are potentially painful to maintain (i.e concrete and stable) and which assemblies are potentially useless (i.e abstract and instable).
- Abstractness:
If an assembly contains many abstract types (i.e interfaces and abstract classes) and few concrete types, it is considered as abstract.
- Instability: An assembly is considered stable if its types are used by a lot of types from other assemblies. In this context stable means painful to modify.
Online documentation: