ndepend
- report summary
- application nameFlightSystem2 (v1.0.0.0)report build date12-11-2019 00:06:00analysis duration00:18ndepend
- version
- 2019.3.0 Evaluation 13 days leftbaseline for comparisonBaseline is same code base snapshot.code coverage data
- Not Defined. To import Code Coverage Data, please read this online documentation.
-
Get started.Quick tips.Back to NDepend.
- The present HTML report is a summary of data gathered by the analysis.
- It is recommended to use the NDepend interactive UI capabilities
- to make the most of NDepend by mastering all aspects of your code. -
- It is recommended to use the NDepend interactive UI capabilities
- to make the most of NDepend by mastering all aspects of your code. -
Diagrams
Application Metrics
- Note: Further Application Statistics are available. -
|
Quality Gates summary
902
- Some Quality Gates fail. The build- can be stopped upon quality gate
- failure. Online documentation. -
- Quality Gates that measure diff cannot- be run on the baseline. Hence they
- have blank trend and baseline value. -
| Name | Trend | Baseline Value | Value | Group | |||
|---|---|---|---|---|---|---|---|
|  |  N/A % | N/A % | Project Rules \ Quality Gates | |||
| | N/A % | N/A % | Project Rules \ Quality Gates | |||
| | N/A % | N/A % | Project Rules \ Quality Gates | |||
| | 0 issues | 0 issues | Project Rules \ Quality Gates | |||
| | 0 issues | 0 issues | Project Rules \ Quality Gates | |||
| 0 issues | Project Rules \ Quality Gates | |||||
| |  2 rules | 2 rules | Project Rules \ Quality Gates | |||
| | 11.14 % | 11.14 % | Project Rules \ Quality Gates | |||
| 0 man-days | Project Rules \ Quality Gates | |||||
| | 4 namespaces | 4 namespaces | Project Rules \ Quality Gates | |||
| 0 man-days | Project Rules \ Quality Gates |
Rules summary
136142- - Number of Rules or Queries with Error (syntax error, exception thrown, time-out): 0
- - Number of Rules violated: 16
- Rules can be checked live at- development-time, from within Visual
- Studio. Online documentation. -
- Rules that rely on diff cannot be- run on the baseline. Hence they
- have blank # Issues Fixed or Added. -
Application Statistics
| - Stat - | - # Occurences - | - Avg - | - StdDev - | - Max - |
|---|---|---|---|---|
| - Properties on interfaces - | 6 interfaces - | 0 | 0 | 0 properties on FlightSystem.Api.Src.Integration.Common.IAirportData |
| - Methods on interfaces - | 6 interfaces - | 1.83 | 0.9 | 3 methods on FlightSystem.Api.Src.Integration.Common.IFlightData |
| - Arguments on methods on interfaces - | 11 methods - | 1.09 | 2.23 | 8 arguments on FlightSystem.Api.Src.Application.Common.IJourney.GetJourney(Boolean,String,String,String,String,Boolean,Int32,String) |
| - Public properties on classes - | 32 Classes - | 0.88 | 1.76 | 7 public properties on FlightSystem.Api.Domain.Entities.Flight |
| - Public methods on classes - | 32 classes - | 3.34 | 2.95 | 15 public methods on FlightSystem.Api.Domain.Entities.Flight |
| - Arguments on public methods on classes - | 107 methods - | 0.72 | 1.4 | 8 arguments on FlightSystem.Api.Src.Integration.Neo4J.Data.FlightParser.GetFlight(String,INode,String,String,String,String,INode,INode) |
| - IL instructions in non-abstract methods - | 123 methods - | 19.17 | 34.71 | 277 IL instructions in FlightSystem.Api.Src.Integration.Neo4J.Data.RouteData.FillRoute2Data(IRecord) |
| - Cyclomatic complexity on non abstract Methods - | 123 Methods - | 1.74 | 1.76 | - CC = 13 for FlightSystem.Api.Src.Integration.Neo4J.Data.RouteData.FillRoute2Data(IRecord) |
Assemblies Metrics
- If you wish to define thresholds on assemblies' Code Metrics, consider writing some Rules.
- Clicking column header arrows sorts values.
- Clicking column header title text redirect to the online Code Metric definition.
- Clicking column header arrows sorts values.
- Clicking column header title text redirect to the online Code Metric definition.
| - Assemblies - | # lines of code | # IL instruction | - # Types - | - # Abstract Types - | # lines of comment | % Comment | % Coverage | Afferent Coupling | Efferent Coupling | Relational Cohesion | Instability | Abstractness | Distance |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| FlightSystem.Api v1.0.0.0 | 361 | 2358 | 38 | 6 | 5 | 1.37 | - | 0 | 77 | 2.63 | 1 | 0.18 | 0.13 |
- If you wish to define thresholds on types' Code Metrics, consider writing some Rule.
- Clicking column header arrows sorts values.
- Clicking column header title text redirect to the online Code Metric definition.
Types Metrics : Code Quality
| - Type Name - | Type Rank | # Lines Of Code | # IL Instructions | # Lines Of Comment | % Comment | Cyclomatic Complexity | IL Cyclomatic Complexity | % Coverage | Afferent Coupling | Efferent Coupling | - Type Namespace - |
|---|---|---|---|---|---|---|---|---|---|---|---|
| Entity | 4.32 | 0 | 4 | - | - | - | 1 | - | 12 | 2 | FlightSystem.Api.Src.Domain.Common |
| Airport | 3.77 | 10 | 38 | 1 | 9.09 | 10 | 10 | - | 7 | 8 | FlightSystem.Api.Domain.Entities |
| Country | 3.32 | 8 | 31 | 0 | 0 | 8 | 8 | - | 6 | 8 | FlightSystem.Api.Domain.Entities |
| Flight | 3.2 | 14 | 53 | 0 | 0 | 14 | 15 | - | 10 | 11 | FlightSystem.Api.Domain.Entities |
| TripParams | 2.85 | 10 | 38 | 0 | 0 | 6 | 6 | - | 8 | 10 | FlightSystem.Api.Src.Domain.Entities |
| ResponseBody | 1.12 | 1 | 7 | 0 | 0 | 1 | 1 | - | 5 | 6 | FlightSystem.Api.Src.Integration.Common |
| Journey | 1.11 | 6 | 20 | 0 | 0 | 3 | 3 | - | 3 | 11 | FlightSystem.Api.Src.Domain.Entities |
| Route | 0.89 | 11 | 41 | 0 | 0 | 3 | 3 | - | 4 | 9 | FlightSystem.Api.Src.Domain.Entities |
| IFlight | 0.87 | - | - | - | - | - | - | - | 4 | 4 | FlightSystem.Api.Src.Application.Common |
| Dates | 0.86 | 7 | 39 | 0 | 0 | 5 | 5 | - | 3 | 7 | FlightSystem.Api.Src.Common |
| Neo4JContext | 0.83 | 6 | 34 | 0 | 0 | 4 | 4 | - | 5 | 13 | FlightSystem.Api.Src.Integration.Neo4J |
| ResponseError | 0.74 | 5 | 24 | 0 | 0 | 5 | 5 | - | 1 | 8 | FlightSystem.Api.Src.Integration.Common |
| ResponseHeader | 0.64 | 1 | 7 | 0 | 0 | 1 | 1 | - | 1 | 5 | FlightSystem.Api.Src.Integration.Common |
| Response | 0.63 | 2 | 10 | 0 | 0 | 1 | 1 | - | 4 | 6 | FlightSystem.Api.Src.Integration.Common |
| Trip | 0.6 | 2 | 8 | 0 | 0 | 1 | 1 | - | 2 | 9 | FlightSystem.Api.Src.Domain.Entities |
| IFlightData | 0.58 | - | - | - | - | - | - | - | 2 | 4 | FlightSystem.Api.Src.Integration.Common |
| IAirportData | 0.55 | - | - | - | - | - | - | - | 2 | 2 | FlightSystem.Api.Src.Integration.Common |
| ICountryData | 0.55 | - | - | - | - | - | - | - | 2 | 2 | FlightSystem.Api.Src.Integration.Common |
| FlightManager | 0.55 | 4 | 33 | 0 | 0 | 4 | 4 | - | 3 | 9 | FlightSystem.Api.Src.Application .FlightInfo |
| ILocation | 0.51 | - | - | - | - | - | - | - | 2 | 3 | FlightSystem.Api.Src.Application.Common |
| FlightData | 0.47 | 33 | 255 | 0 | 0 | 10 | 21 | - | 1 | 25 | FlightSystem.Api.Src.Integration.Neo4J .Data |
| IJourney | 0.41 | - | - | - | - | - | - | - | 2 | 4 | FlightSystem.Api.Src.Application.Common |
| MyImageConverter | 0.4 | 11 | 48 | 0 | 0 | 4 | 6 | - | 1 | 12 | FlightSystem.Api.Src.Integration.Common |
| FlagImageData | 0.39 | 10 | 58 | 0 | 0 | 4 | 7 | - | 1 | 11 | FlightSystem.Api.Src.Integration .FileSystem |
| CountryData | 0.39 | 10 | 66 | 0 | 0 | 3 | 7 | - | 1 | 17 | FlightSystem.Api.Src.Integration.Neo4J .Data |
| AirportData | 0.39 | 10 | 80 | 0 | 0 | 3 | 7 | - | 1 | 17 | FlightSystem.Api.Src.Integration.Neo4J .Data |
| FlightParser | 0.38 | 1 | 112 | 0 | 0 | 1 | 2 | - | 2 | 12 | FlightSystem.Api.Src.Integration.Neo4J .Data |
| RouteData | 0.31 | 68 | 636 | 0 | 0 | 17 | 33 | - | 1 | 24 | FlightSystem.Api.Src.Integration.Neo4J .Data |
| RouteManager | 0.3 | 45 | 243 | 2 | 4.26 | 13 | 20 | - | 1 | 17 | FlightSystem.Api.Src.Application .JourneyInfo |
| LocationManager | 0.27 | 7 | 34 | 0 | 0 | 3 | 3 | - | 1 | 11 | FlightSystem.Api.Src.Application .AirportInfo |
| JourneyManager | 0.27 | 18 | 111 | 0 | 0 | 6 | 8 | - | 1 | 18 | FlightSystem.Api.Src.Application .RouteInfo |
| AllLocationsController | 0.15 | 10 | 54 | 0 | 0 | 3 | 3 | - | 0 | 22 | FlightSystem.Api.Src.Integration .Controllers |
| AllFlightsController | 0.15 | 9 | 46 | 0 | 0 | 3 | 3 | - | 0 | 21 | FlightSystem.Api.Src.Integration .Controllers |
| JourneyController | 0.15 | 9 | 54 | 0 | 0 | 3 | 3 | - | 0 | 22 | FlightSystem.Api.Src.Integration .Controllers |
| City | 0.15 | 6 | 24 | 0 | 0 | 6 | 6 | - | 0 | 8 | FlightSystem.Api.Domain.Entities |
| Startup | 0.15 | 11 | 54 | 2 | 15.38 | 6 | 7 | - | 0 | 16 | FlightSystem |
| FlightController | 0.15 | 9 | 47 | 0 | 0 | 3 | 3 | - | 0 | 21 | FlightSystem.Api.Src.Integration .Controllers |
| Program | 0.15 | 7 | 49 | 0 | 0 | 3 | 7 | - | 0 | 19 | FlightSystem |
Types Metrics : Code Members and Inheritance
| - Type Name - | # Instance Methods | - Nb Static Methods - | - Nb Properties - | # Fields | # Children Classes | Depth Of Inheritance Tree | - Type Namespace - |
|---|---|---|---|---|---|---|---|
| Entity | 1 | 0 | 0 | 0 | 7 | 1 | FlightSystem.Api.Src.Domain.Common |
| Airport | 10 | 0 | 5 | 5 | 0 | 2 | FlightSystem.Api.Domain.Entities |
| Country | 8 | 0 | 4 | 4 | 0 | 2 | FlightSystem.Api.Domain.Entities |
| Flight | 15 | 0 | 7 | 7 | 0 | 2 | FlightSystem.Api.Domain.Entities |
| TripParams | 6 | 0 | 4 | 4 | 0 | 1 | FlightSystem.Api.Src.Domain.Entities |
| ResponseBody | 1 | 0 | 0 | 1 | 0 | 1 | FlightSystem.Api.Src.Integration.Common |
| Journey | 3 | 0 | 2 | 3 | 0 | 2 | FlightSystem.Api.Src.Domain.Entities |
| Route | 3 | 0 | 0 | 3 | 0 | 2 | FlightSystem.Api.Src.Domain.Entities |
| IFlight | 3 | 0 | 0 | 0 | - | - | FlightSystem.Api.Src.Application.Common |
| Dates | 0 | 3 | 0 | 0 | 0 | 1 | FlightSystem.Api.Src.Common |
| Neo4JContext | 0 | 3 | 0 | 1 | 0 | 1 | FlightSystem.Api.Src.Integration.Neo4J |
| ResponseError | 5 | 0 | 2 | 2 | 0 | 1 | FlightSystem.Api.Src.Integration.Common |
| ResponseHeader | 1 | 0 | 0 | 1 | 0 | 1 | FlightSystem.Api.Src.Integration.Common |
| Response | 1 | 0 | 0 | 2 | 0 | 1 | FlightSystem.Api.Src.Integration.Common |
| Trip | 1 | 0 | 0 | 3 | 0 | 2 | FlightSystem.Api.Src.Domain.Entities |
| IFlightData | 3 | 0 | 0 | 0 | - | - | FlightSystem.Api.Src.Integration.Common |
| IAirportData | 1 | 0 | 0 | 0 | - | - | FlightSystem.Api.Src.Integration.Common |
| ICountryData | 1 | 0 | 0 | 0 | - | - | FlightSystem.Api.Src.Integration.Common |
| FlightManager | 4 | 0 | 0 | 1 | 0 | 1 | FlightSystem.Api.Src.Application .FlightInfo |
| ILocation | 2 | 0 | 0 | 0 | - | - | FlightSystem.Api.Src.Application.Common |
| FlightData | 5 | 0 | 0 | 1 | 0 | 1 | FlightSystem.Api.Src.Integration.Neo4J .Data |
| IJourney | 1 | 0 | 0 | 0 | - | - | FlightSystem.Api.Src.Application.Common |
| MyImageConverter | 0 | 2 | 0 | 0 | 0 | 1 | FlightSystem.Api.Src.Integration.Common |
| FlagImageData | 3 | 0 | 0 | 0 | 0 | 1 | FlightSystem.Api.Src.Integration .FileSystem |
| CountryData | 3 | 0 | 0 | 0 | 0 | 1 | FlightSystem.Api.Src.Integration.Neo4J .Data |
| AirportData | 3 | 0 | 0 | 0 | 0 | 1 | FlightSystem.Api.Src.Integration.Neo4J .Data |
| FlightParser | 2 | 0 | 0 | 0 | 0 | 1 | FlightSystem.Api.Src.Integration.Neo4J .Data |
| RouteData | 5 | 0 | 0 | 1 | 0 | 1 | FlightSystem.Api.Src.Integration.Neo4J .Data |
| RouteManager | 7 | 0 | 0 | 6 | 0 | 1 | FlightSystem.Api.Src.Application .JourneyInfo |
| LocationManager | 3 | 0 | 0 | 2 | 0 | 1 | FlightSystem.Api.Src.Application .AirportInfo |
| JourneyManager | 4 | 0 | 0 | 2 | 0 | 1 | FlightSystem.Api.Src.Application .RouteInfo |
| AllLocationsController | 2 | 0 | 0 | 2 | 0 | 1 | FlightSystem.Api.Src.Integration .Controllers |
| AllFlightsController | 2 | 0 | 0 | 2 | 0 | 1 | FlightSystem.Api.Src.Integration .Controllers |
| JourneyController | 2 | 0 | 0 | 2 | 0 | 1 | FlightSystem.Api.Src.Integration .Controllers |
| City | 6 | 0 | 3 | 3 | 0 | 2 | FlightSystem.Api.Domain.Entities |
| Startup | 4 | 0 | 1 | 1 | 0 | 1 | FlightSystem |
| FlightController | 2 | 0 | 0 | 2 | 0 | 1 | FlightSystem.Api.Src.Integration .Controllers |
| Program | 1 | 2 | 0 | 0 | 0 | 1 | FlightSystem |
Types Metrics : Lack Of Cohesion Of Methods and Association Between Classes
| - Type Name - | Lack Of Cohesion Of Methods | Lack Of Cohesion Of Methods HS | Association Between Classes | - Type Namespace - |
|---|---|---|---|---|
| Entity | 0 | 0 | 1 | FlightSystem.Api.Src.Domain.Common |
| Airport | 0 | 0 | 1 | FlightSystem.Api.Domain.Entities |
| Country | 0 | 0 | 1 | FlightSystem.Api.Domain.Entities |
| Flight | 0 | 0 | 1 | FlightSystem.Api.Domain.Entities |
| TripParams | 0 | 0 | 3 | FlightSystem.Api.Src.Domain.Entities |
| ResponseBody | 0 | 0 | 2 | FlightSystem.Api.Src.Integration.Common |
| Journey | 0 | 0 | 1 | FlightSystem.Api.Src.Domain.Entities |
| Route | 0.33 | 0.5 | 3 | FlightSystem.Api.Src.Domain.Entities |
| IFlight | - | - | 0 | FlightSystem.Api.Src.Application.Common |
| Dates | 0 | 0 | 4 | FlightSystem.Api.Src.Common |
| Neo4JContext | 0 | 0 | 6 | FlightSystem.Api.Src.Integration.Neo4J |
| ResponseError | 0 | 0 | 1 | FlightSystem.Api.Src.Integration.Common |
| ResponseHeader | 0 | 0 | 2 | FlightSystem.Api.Src.Integration.Common |
| Response | 0 | 0 | 3 | FlightSystem.Api.Src.Integration.Common |
| Trip | 0.67 | 0 | 1 | FlightSystem.Api.Src.Domain.Entities |
| IFlightData | - | - | 0 | FlightSystem.Api.Src.Integration.Common |
| IAirportData | - | - | 0 | FlightSystem.Api.Src.Integration.Common |
| ICountryData | - | - | 0 | FlightSystem.Api.Src.Integration.Common |
| FlightManager | 0 | 0 | 5 | FlightSystem.Api.Src.Application .FlightInfo |
| ILocation | - | - | 0 | FlightSystem.Api.Src.Application.Common |
| FlightData | 0.6 | 0.75 | 26 | FlightSystem.Api.Src.Integration.Neo4J .Data |
| IJourney | - | - | 0 | FlightSystem.Api.Src.Application.Common |
| MyImageConverter | 0 | 0 | 10 | FlightSystem.Api.Src.Integration.Common |
| FlagImageData | 0 | 0 | 9 | FlightSystem.Api.Src.Integration .FileSystem |
| CountryData | 0 | 0 | 14 | FlightSystem.Api.Src.Integration.Neo4J .Data |
| AirportData | 0 | 0 | 16 | FlightSystem.Api.Src.Integration.Neo4J .Data |
| FlightParser | 0 | 0 | 19 | FlightSystem.Api.Src.Integration.Neo4J .Data |
| RouteData | 0.4 | 0.5 | 24 | FlightSystem.Api.Src.Integration.Neo4J .Data |
| RouteManager | 0.62 | 0.72 | 23 | FlightSystem.Api.Src.Application .JourneyInfo |
| LocationManager | 0.33 | 0.5 | 7 | FlightSystem.Api.Src.Application .AirportInfo |
| JourneyManager | 0.38 | 0.5 | 19 | FlightSystem.Api.Src.Application .RouteInfo |
| AllLocationsController | 0.25 | 0.5 | 13 | FlightSystem.Api.Src.Integration .Controllers |
| AllFlightsController | 0.25 | 0.5 | 12 | FlightSystem.Api.Src.Integration .Controllers |
| JourneyController | 0.25 | 0.5 | 12 | FlightSystem.Api.Src.Integration .Controllers |
| City | 0 | 0 | 1 | FlightSystem.Api.Domain.Entities |
| Startup | 0 | 0 | 5 | FlightSystem |
| FlightController | 0.25 | 0.5 | 12 | FlightSystem.Api.Src.Integration .Controllers |
| Program | 0 | 0 | 11 | FlightSystem |
Namespaces Metrics
- If you wish to define thresholds on namespaces' Code Metrics, consider writing some Code Rules.
- Clicking column header arrows sorts values.
- Clicking column header title text redirect to the online Code Metric definition.
- Clicking column header arrows sorts values.
- Clicking column header title text redirect to the online Code Metric definition.
| - Namespaces - | # lines of code | # IL instruction | - # Types - | # lines of comment | % Comment | % Coverage | Afferent Coupling | Efferent Coupling |
|---|---|---|---|---|---|---|---|---|
| FlightSystem | 18 | 103 | 2 | 2 | 10 | - | 0 | 18 |
| FlightSystem.Api.Domain.Entities | 38 | 146 | 4 | 1 | 2.56 | - | 9 | 5 |
| FlightSystem.Api.Src.Common | 7 | 39 | 1 | 0 | 0 | - | 2 | 2 |
| FlightSystem.Api.Src.Integration .FileSystem | 10 | 58 | 1 | 0 | 0 | - | 1 | 7 |
| FlightSystem.Api.Src.Integration .Controllers | 37 | 201 | 4 | 0 | 0 | - | 0 | 15 |
| FlightSystem.Api.Src.Integration.Common | 20 | 96 | 8 | 0 | 0 | - | 5 | 14 |
| FlightSystem.Api.Src.Integration.Neo4J | 6 | 34 | 1 | 0 | 0 | - | 2 | 3 |
| FlightSystem.Api.Src.Integration.Neo4J .Data | 122 | 1149 | 5 | 0 | 0 | - | 3 | 12 |
| FlightSystem.Api.Src.Domain.Entities | 29 | 107 | 4 | 0 | 0 | - | 7 | 8 |
| FlightSystem.Api.Src.Domain.Common | 0 | 4 | 1 | - | - | - | 4 | 1 |
| FlightSystem.Api.Src.Application .AirportInfo | 7 | 34 | 1 | 0 | 0 | - | 1 | 7 |
| FlightSystem.Api.Src.Application .JourneyInfo | 45 | 243 | 1 | 2 | 4.26 | - | 1 | 9 |
| FlightSystem.Api.Src.Application .RouteInfo | 18 | 111 | 1 | 0 | 0 | - | 1 | 10 |
| FlightSystem.Api.Src.Application .FlightInfo | 4 | 33 | 1 | 0 | 0 | - | 2 | 7 |
| FlightSystem.Api.Src.Application.Common | 0 | 0 | 3 | - | - | - | 5 | 4 |
| Quality Gates 902 |
|
 | 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 explicitely 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: N/A %
| 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: N/A %
| 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 considerd 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: N/A %
| 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 explicitely 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 explicitely 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: New Blocker / Critical / High Issues |
• Quality Gate Description:
-An issue with the severity Blocker cannot move to production, it must be fixed.
-An issue with a severity level Critical shouldn't move to production. It still can for business imperative needs purposes, but at worth it must be fixed during the next iterations.
-An issue with a severity level High should be fixed quickly, but can wait until the next scheduled interval.
-The severity of an issue is either defined explicitely 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 Fail: 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.
2 rules matched -
| 2 rules | issues | Full Name |
|---|---|---|
| Avoid methods with too many parameters | 5 issues | Rule |
| Avoid non-readonly static fields | 1 issue | Rule |
Statistics
| Stat | issues |
|---|---|
| Sum: | 6 |
| Average: | 3 |
| Minimum: | 1 |
| Maximum: | 5 |
| Standard deviation: | 2 |
| Variance: | 4 |
| 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 logicial 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: 11.14 %
| 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 man-days
| Quality Gate Fail: 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.
4 namespaces matched -
| 4 namespaces | debtRating | debtRatio | devTimeInManDay | debtInManDay | issues | Full Name |
|---|---|---|---|---|---|---|
| FlightSystem.Api.Src.Integration.Neo4J | D | 20.25 | 1h 43min | 21min | 5 issues | FlightSystem.Api.Src.Integration.Neo4J |
| FlightSystem.Api.Src.Domain.Common | D | 38.58 | 25min | 10min | 2 issues | FlightSystem.Api.Src.Domain.Common |
| FlightSystem.Api.Src.Application .RouteInfo | E | 67.3 | 3h 44min | 2h 31min | 5 issues | FlightSystem.Api.Src.Application .RouteInfo |
| FlightSystem.Api.Src.Application.Common | E | 85.75 | 1h 26min | 1h 14min | 2 issues | FlightSystem.Api.Src.Application.Common |
Statistics
| Stat | debtRating | debtRatio | devTimeInManDay | debtInManDay | issues |
|---|---|---|---|---|---|
| Sum: | - | 211.89 | 7h 20min | 4h 16min | 14 |
| Average: | - | 52.97 | 1h 50min | 1h 4min | 3.5 |
| Minimum: | - | 20.25 | 25min | 10min | 2 |
| Maximum: | - | 85.75 | 3h 44min | 2h 31min | 5 |
| Standard deviation: | - | 25.29 | 1h 12min | 55min | 1.5 |
| Variance: | - | 639.36 | 650d | 389d | 2.25 |
| 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 man-days
| Hot Spots 000 |
| Code Smells 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 |
| Visibility 000 |
| Immutability 000 |
| Naming Conventions 000 |
| Source Files Organization 000 |
| .NET Framework Usage 000 |
| Defining JustMyCode 000 |
| Trend Metrics 000 |
| Code Diff Summary 000 |
| Rules extracted from Source Code 000 |
| Code Smells 611 |
|
 | Critical Rule Violated: Avoid methods with too many parameters |
• Rule Description:
-This rule matches methods with 7 or more parameters. Such method is painful to call and might degrade performance. See the definition of the NbParameters metric here: https://www.ndepend.com/docs/code-metrics#NbParameters
-This rule doesn't match a method that overrides a third-party method with 7 or more parameters because such situation is the consequence of a lower-level problem.
-For the same reason, this rule doesn't match a constructor that calls a base constructor with 7 or more parameters.
-
-
- • How to Fix Issues of this Rule: -More properties/fields can be added to the declaring type to handle numerous states. An alternative is to provide a class or a structure dedicated to handle arguments passing. For example see the class System.Diagnostics.ProcessStartInfo and the method System.Diagnostics.Process.Start(ProcessStartInfo). -The estimated Debt, which means the effort to fix such issue, varies linearly from 1 hour for a method with 7 parameters, up to 6 hours for a methods with 40 or more parameters. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1004:AvoidMethodsWithTooManyParameters", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- • How to Fix Issues of this Rule: -More properties/fields can be added to the declaring type to handle numerous states. An alternative is to provide a class or a structure dedicated to handle arguments passing. For example see the class System.Diagnostics.ProcessStartInfo and the method System.Diagnostics.Process.Start(ProcessStartInfo). -The estimated Debt, which means the effort to fix such issue, varies linearly from 1 hour for a method with 7 parameters, up to 6 hours for a methods with 40 or more parameters. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1004:AvoidMethodsWithTooManyParameters", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
5 methods matched -
-
- Formatting: bold means added, underlined means code was changed,
strike-boldmeans removed (since baseline) -
| 5 methods | # Parameters | Debt | Annual Interest | Full Name |
|---|---|---|---|---|
| Get(Boolean,String,String,String,String ,Boolean,Int32,String) | 8 | 1h 9min | 5min | FlightSystem.Api.Src.Integration .Controllers.JourneyController.Get (Boolean,String,String,String,String ,Boolean,Int32,String) |
| GetFlight(String,INode,String,String ,String,String,INode,INode) | 8 | 1h 9min | 5min | FlightSystem.Api.Src.Integration.Neo4J .Data.FlightParser.GetFlight(String ,INode,String,String,String,String,INode ,INode) |
| GetJourney(Boolean,String,String,String ,String,Boolean,Int32,String) | 8 | 1h 9min | 5min | FlightSystem.Api.Src.Application .RouteInfo.JourneyManager.GetJourney (Boolean,String,String,String,String ,Boolean,Int32,String) |
| FormSearchRequest(Boolean,String,String ,String,String,Boolean,Int32,String) | 8 | 1h 9min | 5min | FlightSystem.Api.Src.Application .RouteInfo.JourneyManager .FormSearchRequest(Boolean,String,String ,String,String,Boolean,Int32,String) |
| GetJourney(Boolean,String,String,String ,String,Boolean,Int32,String) | 8 | 1h 9min | 5min | FlightSystem.Api.Src.Application.Common .IJourney.GetJourney(Boolean,String ,String,String,String,Boolean,Int32 ,String) |
 | Rule Violated: Avoid methods potentially poorly commented |
• Rule Description:
-This rule matches methods with less than 10% of comment lines and that have at least 20 lines of code. Such method might need to be more commented.
-See the definitions of the Comments metric here: https://www.ndepend.com/docs/code-metrics#PercentageComment https://www.ndepend.com/docs/code-metrics#NbLinesOfComment
-Notice that only comments about the method implementation (comments in method body) are taken account.
-
-
- • How to Fix Issues of this Rule: -Typically add more comment. But code commenting is subject to controversy. While poorly written and designed code would needs a lot of comment to be understood, clean code doesn't need that much comment, especially if variables and methods are properly named and convey enough information. Unit-Test code can also play the role of code commenting. -However, even when writing clean and well-tested code, one will have to write hacks at a point, usually to circumvent some API limitations or bugs. A hack is a non-trivial piece of code, that doesn't make sense at first glance, and that took time and web research to be found. In such situation comments must absolutely be used to express the intention, the need for the hacks and the source where the solution has been found. -The estimated Debt, which means the effort to comment such method, varies linearly from 2 minutes for 10 lines of code not commented, up to 20 minutes for 200 or more, lines of code not commented. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1006:AvoidMethodsPotentiallyPoorlyCommented", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- • How to Fix Issues of this Rule: -Typically add more comment. But code commenting is subject to controversy. While poorly written and designed code would needs a lot of comment to be understood, clean code doesn't need that much comment, especially if variables and methods are properly named and convey enough information. Unit-Test code can also play the role of code commenting. -However, even when writing clean and well-tested code, one will have to write hacks at a point, usually to circumvent some API limitations or bugs. A hack is a non-trivial piece of code, that doesn't make sense at first glance, and that took time and web research to be found. In such situation comments must absolutely be used to express the intention, the need for the hacks and the source where the solution has been found. -The estimated Debt, which means the effort to comment such method, varies linearly from 2 minutes for 10 lines of code not commented, up to 20 minutes for 200 or more, lines of code not commented. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1006:AvoidMethodsPotentiallyPoorlyCommented", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
2 methods matched -
-
- Formatting: bold means added, underlined means code was changed,
strike-boldmeans removed (since baseline) -
| 2 methods | Percentage Comment | # lines of code (LOC) | # lines of comment | nbLinesOfCodeNotCommented | Debt | Annual Interest | Full Name |
|---|---|---|---|---|---|---|---|
| FillRoute2Data(IRecord) | 0 | 31 | 0 | 31 | 3min 6s | 16min | FlightSystem.Api.Src.Integration.Neo4J .Data.RouteData.FillRoute2Data(IRecord) |
| FillRouteData(IRecord) | 0 | 22 | 0 | 22 | 2min 12s | 16min | FlightSystem.Api.Src.Integration.Neo4J .Data.RouteData.FillRouteData(IRecord) |
| Object Oriented Design 1220 |
| Rule Violated: A stateless class or structure might be turned into a static type |
• Rule Description:
-This rule matches classes and structures that are not static, nor generic, that doesn't have any instance fields, that doesn't implement any interface nor has a base class (different than System.Object).
-Such class or structure is a stateless collection of pure functions, that doesn't act on any this object data. Such collection of pure functions is better hosted in a static class. Doing so simplifies the client code that doesn't have to create an object anymore to invoke the pure functions.
-
-
- • How to Fix Issues of this Rule: -Declare all methods as static and transform the class or structure into a static class. -By default issues of this rule have a Low severity because they reflect more an advice than a problem. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1206:AStatelessClassOrStructureMightBeTurnedIntoAStaticType", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- • How to Fix Issues of this Rule: -Declare all methods as static and transform the class or structure into a static class. -By default issues of this rule have a Low severity because they reflect more an advice than a problem. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1206:AStatelessClassOrStructureMightBeTurnedIntoAStaticType", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
2 types matched -
-
- Formatting: bold means added, underlined means code was changed,
strike-boldmeans removed (since baseline) -
| 2 types | methodsUsingMe | Debt | Severity | Full Name |
|---|---|---|---|---|
| FlagImageData | 1 method | 2min 0s | Low | FlightSystem.Api.Src.Integration .FileSystem.FlagImageData |
| FlightParser | 5 methods | 6min | Low | FlightSystem.Api.Src.Integration.Neo4J .Data.FlightParser |
| Rule Violated: Methods should be declared static if possible |
• Rule Description:
-When an instance method can be safely declared as static you should declare it as static.
-Whenever you write a method, you fulfill a contract in a given scope. The narrower the scope is, the smaller the chance is that you write a bug.
-When a method is static, you can't access non-static members; hence, your scope is narrower. So, if you don't need and will never need (even in subclasses) instance fields to fulfill your contract, why give access to these fields to your method? Declaring the method static in this case will let the compiler check that you don't use members that you do not intend to use.
-Declaring a method as static if possible is also good practice because clients can tell from the method signature that calling the method can't alter the object's state.
-Doing so, is also a micro performance optimization, since a static method is a bit cheaper to invoke than an instance method, because the this reference* doesn't need anymore to be passed.
-Notice that if a matched method is a handler, bound to an event through code generated by a designer, declaring it as static might break the designer generated code, if the generated code use the this invocation syntax, (like this.Method()).
-
-
- • How to Fix Issues of this Rule: -Declare matched methods as static. -Since such method doesn't use any instance fields and methods of its type and base-types, you should consider if it makes sense, to move such a method to a static utility class. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1208:MethodsShouldBeDeclaredStaticIfPossible", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- • How to Fix Issues of this Rule: -Declare matched methods as static. -Since such method doesn't use any instance fields and methods of its type and base-types, you should consider if it makes sense, to move such a method to a static utility class. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1208:MethodsShouldBeDeclaredStaticIfPossible", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
6 methods matched -
-
- Formatting: bold means added, underlined means code was changed,
strike-boldmeans removed (since baseline) -
| 6 methods | staticFieldsUsed | methodsCallingMe | Debt | Severity | Full Name |
|---|---|---|---|---|---|
| GetFlagImageString(String) | no field | 1 method | 1min 0s | Medium | FlightSystem.Api.Src.Integration .FileSystem.FlagImageData .GetFlagImageString(String) |
| GetAirportFromResult(INode) | no field | 1 method | 1min 0s | Medium | FlightSystem.Api.Src.Integration.Neo4J .Data.AirportData.GetAirportFromResult (INode) |
| GetCountryFromResult(INode) | no field | 1 method | 1min 0s | Medium | FlightSystem.Api.Src.Integration.Neo4J .Data.CountryData.GetCountryFromResult (INode) |
| GetFlight(String,INode,String,String ,String,String,INode,INode) | no field | 3 methods | 2min 0s | Medium | FlightSystem.Api.Src.Integration.Neo4J .Data.FlightParser.GetFlight(String ,INode,String,String,String,String,INode ,INode) |
| AddRouteInfo(List<Route>) | no field | 3 methods | 2min 0s | Medium | FlightSystem.Api.Src.Application .JourneyInfo.RouteManager.AddRouteInfo (List<Route>) |
| SortAndCutRoutes(List<Route>) | no field | 1 method | 1min 0s | Medium | FlightSystem.Api.Src.Application .JourneyInfo.RouteManager .SortAndCutRoutes(List<Route>) |
| Design 1020 |
| Rule Violated: Avoid namespaces with few types |
• Rule Description:
-This rule warns about namespaces other than the global namespace that contain less than five types.
-Make sure that each of your namespaces has a logical organization and that a valid reason exists to put types in a sparsely populated namespace.
-Namespaces should contain types that are used together in most scenarios. When their applications are mutually exclusive, types should be located in separate namespaces. For example, the System.Web.UI namespace contains types that are used in Web applications, and the System.Windows.Forms namespace contains types that are used in Windows-based applications. Even though both namespaces have types that control aspects of the user interface, these types are not designed for use in the same application. Therefore, they are located in separate namespaces.
-Careful namespace organization can also be helpful because it increases the discoverability of a feature. By examining the namespace hierarchy, library consumers should be able to locate the types that implement a feature.
-Notice that this rule source code contains a list of common infrastructure namespace names that you can complete. Namespaces with ending name component in this list are not matched.
-
-
- • How to Fix Issues of this Rule: -To fix a violation of this rule, try to combine namespaces that contain just a few types into a single namespace. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1305:AvoidNamespacesWithFewTypes", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- • How to Fix Issues of this Rule: -To fix a violation of this rule, try to combine namespaces that contain just a few types into a single namespace. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1305:AvoidNamespacesWithFewTypes", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
9 namespaces matched -
-
- Formatting: bold means added, underlined means code was changed,
strike-boldmeans removed (since baseline) -
| 9 namespaces | types | Debt | Severity | Full Name |
|---|---|---|---|---|
| FlightSystem.Api.Src.Common | 1 type | 5min | Low | FlightSystem.Api.Src.Common |
| FlightSystem.Api.Src.Integration .FileSystem | 1 type | 5min | Low | FlightSystem.Api.Src.Integration .FileSystem |
| FlightSystem.Api.Src.Integration.Neo4J | 1 type | 5min | Low | FlightSystem.Api.Src.Integration.Neo4J |
| FlightSystem.Api.Src.Domain.Common | 1 type | 5min | Low | FlightSystem.Api.Src.Domain.Common |
| FlightSystem.Api.Src.Application .AirportInfo | 1 type | 5min | Low | FlightSystem.Api.Src.Application .AirportInfo |
| FlightSystem.Api.Src.Application .JourneyInfo | 1 type | 5min | Low | FlightSystem.Api.Src.Application .JourneyInfo |
| FlightSystem.Api.Src.Application .RouteInfo | 1 type | 5min | Low | FlightSystem.Api.Src.Application .RouteInfo |
| FlightSystem.Api.Src.Application .FlightInfo | 1 type | 5min | Low | FlightSystem.Api.Src.Application .FlightInfo |
| FlightSystem.Api.Src.Application.Common | 3 types | 5min | Low | FlightSystem.Api.Src.Application.Common |
| Rule Violated: Do implement methods that throw NotImplementedException |
• Rule Description:
-The exception NotImplementedException is used to declare a method stub that can be invoked, and defer the development of the method implementation.
-This exception is especially useful when doing TDD (Test Driven Development) when tests are written first. This way tests fail until the implementation is written.
-Hence using NotImplementedException is a temporary facility, and before releasing, will come a time when this exception shouldn't be used anywhere in code.
-NotImplementedException should not be used permanently to mean something like this method should be overriden or this implementation doesn't support this facility. Artefact like abstract method or abstract class should be used instead, to favor a compile time error over a run-time error.
-This rule warns about method still using NotImplementedException.
-
-
- • How to Fix Issues of this Rule: -Investigate why NotImplementedException is still thrown. -Such issue has a High severity if the method code consists only in throwing NotImplementedException. Such situation means either that the method should be implemented, either that what should be a compile time error is a run-time error by-design, and this is not good design. Sometime this situation also pinpoints a method stub that can be safely removed. -If NotImplementedException is thrown from a method with significant logic, the severity is considered as Medium, because often the fix consists in throwing another exception type, like InvalidOperationException. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1312:DoImplementMethodsThatThrowNotImplementedException", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- • How to Fix Issues of this Rule: -Investigate why NotImplementedException is still thrown. -Such issue has a High severity if the method code consists only in throwing NotImplementedException. Such situation means either that the method should be implemented, either that what should be a compile time error is a run-time error by-design, and this is not good design. Sometime this situation also pinpoints a method stub that can be safely removed. -If NotImplementedException is thrown from a method with significant logic, the severity is considered as Medium, because often the fix consists in throwing another exception type, like InvalidOperationException. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1312:DoImplementMethodsThatThrowNotImplementedException", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
1 method matched -
-
- Formatting: bold means added, underlined means code was changed,
strike-boldmeans removed (since baseline) -
| 1 method | # lines of code (LOC) | Debt | Severity | Full Name |
|---|---|---|---|---|
| RunQuery(String) | 4 | 3min 0s | Medium | FlightSystem.Api.Src.Integration.Neo4J .Neo4JContext.RunQuery(String) |
| Visibility 910 |
|
| Rule Violated: Fields should be declared as private |
• Rule Description:
-This rule matches non-private and mutable fields. Mutable means that the field value can be modified. Typically mutable fields are non-constant, non-readonly fields.
-Fields should be considered as implementation details and as a consequence they should be declared as private.
-If something goes wrong with a non-private field, the culprit can be anywhere, and so in order to track down the bug, you may have to look at quite a lot of code.
-A private field, by contrast, can only be assigned from inside the same class, so if something goes wrong with that, there is usually only one source file to look at.
-Issues of this rule are fast to get fixed, and they have a debt proportional to the number of methods assigning the field.
-
-
- • How to Fix Issues of this Rule: -Declare a matched mutable field as private, or declare it as readonly. -If code outside the type needs to access the field you can encapsulate the field accesses in a read-write property. At least with a read-write property you can set a debug breakpoint on the property setter, which makes easier to track write-accesses in case of problem. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1805:FieldsShouldBeDeclaredAsPrivate", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- • How to Fix Issues of this Rule: -Declare a matched mutable field as private, or declare it as readonly. -If code outside the type needs to access the field you can encapsulate the field accesses in a read-write property. At least with a read-write property you can set a debug breakpoint on the property setter, which makes easier to track write-accesses in case of problem. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1805:FieldsShouldBeDeclaredAsPrivate", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
13 fields matched -
-
- Formatting: bold means added, underlined means code was changed,
strike-boldmeans removed (since baseline) -
| 13 fields | Visibility | outsideMethodsAssigningMe | Debt | Annual Interest | Full Name |
|---|---|---|---|---|---|
| LocationMan | Public | no method | 1min 0s | 6min | FlightSystem.Api.Src.Integration .Controllers.AllLocationsController .LocationMan |
| responseHeader | Public | no method | 1min 0s | 6min | FlightSystem.Api.Src.Integration.Common .Response.responseHeader |
| responseBody | Public | no method | 1min 0s | 6min | FlightSystem.Api.Src.Integration.Common .Response.responseBody |
| entities | Public | no method | 1min 0s | 6min | FlightSystem.Api.Src.Integration.Common .ResponseBody.entities |
| responseError | Public | no method | 1min 0s | 6min | FlightSystem.Api.Src.Integration.Common .ResponseHeader.responseError |
| Driver | Public | no method | 1min 0s | 6min | FlightSystem.Api.Src.Integration.Neo4J .Neo4JContext.Driver |
| trips | Public | no method | 1min 0s | 6min | FlightSystem.Api.Src.Domain.Entities .Journey.trips |
| price | Public | 1 method | 1min 20s | 6min | FlightSystem.Api.Src.Domain.Entities .Route.price |
| timeSpan | Public | 1 method | 1min 20s | 6min | FlightSystem.Api.Src.Domain.Entities .Route.timeSpan |
| flights | Public | no method | 1min 0s | 6min | FlightSystem.Api.Src.Domain.Entities .Route.flights |
| tripParams | Public | no method | 1min 0s | 6min | FlightSystem.Api.Src.Domain.Entities .Trip.tripParams |
| numOfRoutes | Public | 1 method | 1min 20s | 6min | FlightSystem.Api.Src.Domain.Entities .Trip.numOfRoutes |
| routes | Public | 1 method | 1min 20s | 6min | FlightSystem.Api.Src.Domain.Entities .Trip.routes |
| Immutability 731 |
|
| Rule Violated: Fields should be marked as ReadOnly when possible |
• Rule Description:
-This rule warns about instance and static fields that can be declared as readonly.
-This source code of this rule is based on the conditon IField.IsImmutable. https://www.ndepend.com/api/webframe.html?NDepend.API~NDepend.CodeModel.IField~IsImmutable.html
-A field that matches the condition IsImmutable is a field that is assigned only by constructors of its class.
-For an instance field, this means its value will remain constant through the lifetime of the object.
-For a static field, this means its value will remain constant through the lifetime of the program.
-
-
- • How to Fix Issues of this Rule: -Declare the field with the C# readonly keyword (ReadOnly in VB.NET). This way the intention that the field value shouldn't change is made explicit. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1900:FieldsShouldBeMarkedAsReadOnlyWhenPossible", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- • How to Fix Issues of this Rule: -Declare the field with the C# readonly keyword (ReadOnly in VB.NET). This way the intention that the field value shouldn't change is made explicit. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1900:FieldsShouldBeMarkedAsReadOnlyWhenPossible", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
13 fields matched -
-
- Formatting: bold means added, underlined means code was changed,
strike-boldmeans removed (since baseline) -
| 13 fields | MethodsReadingMeButNotAssigningMe | MethodsAssigningMe | Debt | Severity | Full Name |
|---|---|---|---|---|---|
| flight | 2 methods | no method | 5min | Medium | FlightSystem.Api.Src.Integration .Controllers.AllFlightsController.flight |
| flight | 2 methods | no method | 5min | Medium | FlightSystem.Api.Src.Integration .Controllers.FlightController.flight |
| journeyMan | 2 methods | no method | 5min | Medium | FlightSystem.Api.Src.Integration .Controllers.JourneyController .journeyMan |
| flightParser | 2 methods | no method | 5min | Medium | FlightSystem.Api.Src.Integration.Neo4J .Data.FlightData.flightParser |
| flightParser | 3 methods | no method | 5min | Medium | FlightSystem.Api.Src.Integration.Neo4J .Data.RouteData.flightParser |
| AirportData | 2 methods | no method | 5min | Medium | FlightSystem.Api.Src.Application .AirportInfo.LocationManager.AirportData |
| CountryData | 2 methods | no method | 5min | Medium | FlightSystem.Api.Src.Application .AirportInfo.LocationManager.CountryData |
| flightMan | 2 methods | no method | 5min | Medium | FlightSystem.Api.Src.Application .JourneyInfo.RouteManager.flightMan |
| routeData | 3 methods | no method | 5min | Medium | FlightSystem.Api.Src.Application .JourneyInfo.RouteManager.routeData |
| maxRoutesFromDb | 2 methods | no method | 5min | Medium | FlightSystem.Api.Src.Application .JourneyInfo.RouteManager .maxRoutesFromDb |
| maxRoutesReturn | 1 method | no method | 5min | Medium | FlightSystem.Api.Src.Application .JourneyInfo.RouteManager .maxRoutesReturn |
| routeMan | 2 methods | no method | 5min | Medium | FlightSystem.Api.Src.Application .RouteInfo.JourneyManager.routeMan |
| FlightData | 4 methods | no method | 5min | Medium | FlightSystem.Api.Src.Application .FlightInfo.FlightManager.FlightData |
| Critical Rule Violated: Avoid non-readonly static fields |
• Rule Description:
-This rule warns about static fields that are not declared as read-only.
-In Object-Oriented-Programming the natural artifact to hold states that can be modified is instance fields. Such mutable static fields create confusion about the expected state at runtime and impairs the code testability since the same mutable state is re-used for each test.
-More discussion on the topic can be found here: http://codebetter.com/patricksmacchia/2011/05/04/back-to-basics-usage-of-static-members/
-
-
- • How to Fix Issues of this Rule: -If the static field is just assigned once in the program lifetime, make sure to declare it as readonly and assign it inline, or from the static constructor. -Else if methods other than the static constructor need to assign the state hold by the static field, refactoring must occur to ensure that this state is hold through an instance field. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1901:AvoidNonReadOnlyStaticFields", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- • How to Fix Issues of this Rule: -If the static field is just assigned once in the program lifetime, make sure to declare it as readonly and assign it inline, or from the static constructor. -Else if methods other than the static constructor need to assign the state hold by the static field, refactoring must occur to ensure that this state is hold through an instance field. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1901:AvoidNonReadOnlyStaticFields", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
1 field matched -
-
- Formatting: bold means added, underlined means code was changed,
strike-boldmeans removed (since baseline) -
| 1 field | methodAssigningField | Debt | Severity | Full Name |
|---|---|---|---|---|
| Driver | no method | 2min 0s | High | FlightSystem.Api.Src.Integration.Neo4J .Neo4JContext.Driver |
Statistics
| Stat | methodAssigningField | Debt | Severity |
|---|---|---|---|
| Sum: | 0 | 2min 0s | - |
| Average: | 0 | 2min 0s | - |
| Minimum: | 0 | 2min 0s | - |
| Maximum: | 0 | 2min 0s | - |
| Standard deviation: | 0 | 0min 0s | - |
| Variance: | 0 | 0min 0s | - |
| Rule Violated: A field must not be assigned from outside its parent hierarchy types |
• Rule Description:
-This rule is related to the rule Fields should be declared as private. It matches any public or internal, mutable field that is assigned from outside its parent class and subclasses.
-Fields should be considered as implementation details and as a consequence they should be declared as private.
-If something goes wrong with a non-private field, the culprit can be anywhere, and so in order to track down the bug, you may have to look at quite a lot of code.
-A private field, by contrast, can only be assigned from inside the same class, so if something goes wrong with that, there is usually only one source file to look at.
-
-
- • How to Fix Issues of this Rule: -Matched fields must be declared as protected and even better as private. -Alternatively, if the field can reference immutable states, it can remain visible from the outside, but then must be declared as readonly. -The estimated Debt, which means the effort to fix such issue, is equal to 5 minutes per method outside the parent hierarchy that assigns the matched field. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1905:AFieldMustNotBeAssignedFromOutsideItsParentHierarchyTypes", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- • How to Fix Issues of this Rule: -Matched fields must be declared as protected and even better as private. -Alternatively, if the field can reference immutable states, it can remain visible from the outside, but then must be declared as readonly. -The estimated Debt, which means the effort to fix such issue, is equal to 5 minutes per method outside the parent hierarchy that assigns the matched field. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1905:AFieldMustNotBeAssignedFromOutsideItsParentHierarchyTypes", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
4 fields matched -
-
- Formatting: bold means added, underlined means code was changed,
strike-boldmeans removed (since baseline) -
| 4 fields | methodsAssignerOutsideOfMyType | Debt | Severity | Full Name |
|---|---|---|---|---|
| price | 1 method | 5min | High | FlightSystem.Api.Src.Domain.Entities .Route.price |
| timeSpan | 1 method | 5min | High | FlightSystem.Api.Src.Domain.Entities .Route.timeSpan |
| numOfRoutes | 1 method | 5min | High | FlightSystem.Api.Src.Domain.Entities .Trip.numOfRoutes |
| routes | 1 method | 5min | High | FlightSystem.Api.Src.Domain.Entities .Trip.routes |
| Rule Violated: Don't assign a field from many methods |
• Rule Description:
-A field assigned from many methods is a symptom of bug-prone code. Notice that:
-• For an instance field, constructor(s) of its class that assign the field are not counted.
-• For a static field, the class constructor that assigns the field is not counted.
-The default threshold for instance fields is equal to 4 or more than 4 methods assigning the instance field. Such situation makes harder to anticipate the field state at runtime. The code is then complicated to read, hard to debug and hard to maintain. Hard-to-solve bugs due to corrupted state are often the consequence of fields anarchically assigned.
-The situation is even more complicated if the field is static. Indeed, such situation potentially involves global random accesses from various parts of the application. This is why this rule provides a lower threshold equals to 2 or more than 2 methods assigning the static field.
-If the object containing such field is meant to be used from multiple threads, there are alarming chances that the code is unmaintainable and bugged. When multiple threads are involved, the rule of thumb is to use immutable objects.
-If the field type is a reference type (interfaces, classes, strings, delegates) corrupted state might result in a NullReferenceException. If the field type is a value type (number, boolean, structure) corrupted state might result in wrong result not even signaled by an exception thrown.
-
-
- • How to Fix Issues of this Rule: -There is no straight advice to refactor the number of methods responsible for assigning a field. Sometime the situation is simple enough, like when a field that hold an indentation state is assigned by many writer methods. Such situation only requires to define two methods IndentPlus()/IndentMinus() that assign the field, called from all writers methods. -Sometime the solution involves rethinking and then rewriting a complex algorithm. Such field can sometime become just a variable accessed locally by a method or a closure. Sometime, just rethinking the life-time and the role of the parent object allows the field to become immutable (i.e assigned only by the constructor). -The estimated Debt, which means the effort to fix such issue, is equal to 4 minutes plus 5 minutes per method assigning the instance field or 10 minutes per method assigning the static field. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1906:DontAssignAFieldFromManyMethods", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- • How to Fix Issues of this Rule: -There is no straight advice to refactor the number of methods responsible for assigning a field. Sometime the situation is simple enough, like when a field that hold an indentation state is assigned by many writer methods. Such situation only requires to define two methods IndentPlus()/IndentMinus() that assign the field, called from all writers methods. -Sometime the solution involves rethinking and then rewriting a complex algorithm. Such field can sometime become just a variable accessed locally by a method or a closure. Sometime, just rethinking the life-time and the role of the parent object allows the field to become immutable (i.e assigned only by the constructor). -The estimated Debt, which means the effort to fix such issue, is equal to 4 minutes plus 5 minutes per method assigning the instance field or 10 minutes per method assigning the static field. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1906:DontAssignAFieldFromManyMethods", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
1 field matched -
-
- Formatting: bold means added, underlined means code was changed,
strike-boldmeans removed (since baseline) -
| 1 field | methodsAssigningMe | MethodsReadingMeButNotAssigningMe | MethodsUsingMe | Debt | Severity | Full Name |
|---|---|---|---|---|---|---|
| numOfRoutes | 4 methods | no method | 4 methods | 9min | High | FlightSystem.Api.Src.Application .JourneyInfo.RouteManager.numOfRoutes |
| Naming Conventions 1730 |
| Rule Violated: Instance fields naming convention |
• Rule Description:
-By default the presents rule supports the 3 most used naming conventions for instance fields:
-• Instance field name starting with a lower-case letter
-• Instance field name starting with "_" followed with a lower-case letter
-• Instance field name starting with "m_" followed with an upper-case letter
-The rule can be easily adapted to your own company naming convention.
-In terms of behavior, a static field is something completely different than an instance field, so it is interesting to differentiate them at a glance through a naming convetion.
-This is why it is advised to use a specific naming convention for instance field like name that starts with m_.
-Related discussion: http://codebetter.com/patricksmacchia/2013/09/04/on-hungarian-notation-for-instance-vs-static-fields-naming/
-
-
- • How to Fix Issues of this Rule: -Once the rule has been adapted to your own naming convention make sure to name all matched instance fields adequately. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND2000:InstanceFieldsNamingConvention", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- • How to Fix Issues of this Rule: -Once the rule has been adapted to your own naming convention make sure to name all matched instance fields adequately. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND2000:InstanceFieldsNamingConvention", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
4 fields matched -
-
- Formatting: bold means added, underlined means code was changed,
strike-boldmeans removed (since baseline) -
| 4 fields | Size of instance | Debt | Severity | Full Name |
|---|---|---|---|---|
| LocationMan | 4 | 3min 0s | Medium | FlightSystem.Api.Src.Integration .Controllers.AllLocationsController .LocationMan |
| AirportData | 4 | 3min 0s | Medium | FlightSystem.Api.Src.Application .AirportInfo.LocationManager.AirportData |
| CountryData | 4 | 3min 0s | Medium | FlightSystem.Api.Src.Application .AirportInfo.LocationManager.CountryData |
| FlightData | 4 | 3min 0s | Medium | FlightSystem.Api.Src.Application .FlightInfo.FlightManager.FlightData |
| Rule Violated: Abstract base class should be suffixed with 'Base' |
• Rule Description:
-This rule warns about abstract classes whose names are not suffixed with Base. It is a common practice in the .NET world to suffix base classes names with Base.
-Notice that this rule doesn't match abstract classes that are in a middle of a hierarchy chain. In other words, only base classes that derive directly from System.Object are matched.
-
-
- • How to Fix Issues of this Rule: -Suffix the names of matched base classes with Base. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND2003:AbstractBaseClassShouldBeSuffixedWithBase", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- • How to Fix Issues of this Rule: -Suffix the names of matched base classes with Base. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND2003:AbstractBaseClassShouldBeSuffixedWithBase", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
1 type matched -
-
- Formatting: bold means added, underlined means code was changed,
strike-boldmeans removed (since baseline) -
| 1 type | Debt | Severity | Full Name |
|---|---|---|---|
| Entity | 5min | Medium | FlightSystem.Api.Src.Domain.Common .Entity |
| Rule Violated: Avoid prefixing type name with parent namespace name |
• Rule Description:
-This rule warns about situations where the parent namespace name is used as the prefix of a contained type.
-For example a type named "RuntimeEnvironment" declared in a namespace named "Foo.Runtime" should be named "Environment".
-Such situation creates naming redundancy with no readability gain.
-
-
- • How to Fix Issues of this Rule: -To fix a violation of this rule, remove the prefix from the type name. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND2013:AvoidPrefixingTypeNameWithParentNamespaceName", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- • How to Fix Issues of this Rule: -To fix a violation of this rule, remove the prefix from the type name. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND2013:AvoidPrefixingTypeNameWithParentNamespaceName", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
1 type matched -
-
- Formatting: bold means added, underlined means code was changed,
strike-boldmeans removed (since baseline) -
| 1 type | namespaceName | Debt | Severity | Full Name |
|---|---|---|---|---|
| Neo4JContext | Neo4J | 10min | Medium | FlightSystem.Api.Src.Integration.Neo4J .Neo4JContext |
| Source Files Organization 420 |
| Rule Violated: Namespace name should correspond to file location |
• Rule Description:
-For a solid code structure and organization, do mirror the namespaces hierarchy and the directories hierarchy containing source files.
-Doing so is a widely accepted convention, and not respecting this convention will lead to less maintainable and less browsable source code.
-This rule matches all types in such source file, whose location doesn't correspond to the type parent namespace. If a source file contains several such types (that are not necessarily in the same namespace) each type will result in a violation.
-If a type is declared in several such source files, the value for the column nbSourceDeclConcerned in the result, is greater than 1. The technical-debt per issue is proportional to nbSourceDeclConcerned.
-Notice that namespaces and directories names comparison is case-sensitive. A boolean justACaseSensitiveIssue indicates if it is just a case-sensitive issue, in which case the technical-debt is divided by two.
-
-
- • How to Fix Issues of this Rule: -To fix a violation of this rule, make sure that the type parent namespace and the directory sub-paths that contains the type source file, are mirrored. -Make sure to first check the boolean justACaseSensitiveIssue, in which case the issue is easier to fix. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND2103:NamespaceNameShouldCorrespondToFileLocation", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- • How to Fix Issues of this Rule: -To fix a violation of this rule, make sure that the type parent namespace and the directory sub-paths that contains the type source file, are mirrored. -Make sure to first check the boolean justACaseSensitiveIssue, in which case the issue is easier to fix. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND2103:NamespaceNameShouldCorrespondToFileLocation", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
2 types matched -
-
- Formatting: bold means added, underlined means code was changed,
strike-boldmeans removed (since baseline) -
| 2 types | dirShouldContain | sourceFilePath | nbSourceDeclConcerned | justACaseSensitiveIssue | Debt | Severity | Full Name |
|---|---|---|---|---|---|---|---|
| LocationManager | Src Application AirportInfo | C:\Users\Paulius\source\repos\FlightSystem2\FlightSystem2\Src\Application\LocationInfo\LocationManager.cs | 1 | False | 3min 0s | Medium | FlightSystem.Api.Src.Application .AirportInfo.LocationManager |
| JourneyManager | Src Application RouteInfo | C:\Users\Paulius\source\repos\FlightSystem2\FlightSystem2\Src\Application\JourneyInfo\JourneyManager.cs | 1 | False | 3min 0s | Medium | FlightSystem.Api.Src.Application .RouteInfo.JourneyManager |
| Rule Violated: Types with source files stored in the same directory, should be declared in the same namespace |
• Rule Description:
-For a solid code structure and organization, do mirror the namespaces hierarchy and the directories hierarchy containing source files.
-Doing so is a widely accepted convention, and not respecting this convention will lead to less maintainable and less browsable code.
-Respecting this convention means that types with source files stored in the same directory, should be declared in the same namespace.
-For each directory that contains several source files, where most types are declared in a namespace (what we call the main namespace) and a few types are declared out of the main namespace, this code rule matches:
-• The main namespace
-• typesOutOfMainNamespace: Types declared in source files in the main namespace's directory but that are not in the main namespace.
-• typesInMainNamespace: And for informational purposes, types declared in source files in the main namespace's directory, and that are in the main namespace.
-
-
- • How to Fix Issues of this Rule: -Violations of this rule are types in the typesOutOfMainNamespace column. Typically such type … -• … is contained in the wrong namespace but its source file is stored in the right directory. In such situation the type should be contained in main namespace. -• … is contained in the right namespace but its source file is stored in the wrong directory In such situation the source file of the type must be moved to the proper parent namespace directory. -• … is declared in multiple source files, stored in different directories. In such situation it is preferable that all source files are stored in a single directory. -The estimated Debt, which means the effort to fix such issue, is equal to 2 minutes plus 5 minutes per type in typesOutOfMainNamespace. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND2104:TypesWithSourceFilesStoredInTheSameDirectoryShouldBeDeclaredInTheSameNamespace", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- • How to Fix Issues of this Rule: -Violations of this rule are types in the typesOutOfMainNamespace column. Typically such type … -• … is contained in the wrong namespace but its source file is stored in the right directory. In such situation the type should be contained in main namespace. -• … is contained in the right namespace but its source file is stored in the wrong directory In such situation the source file of the type must be moved to the proper parent namespace directory. -• … is declared in multiple source files, stored in different directories. In such situation it is preferable that all source files are stored in a single directory. -The estimated Debt, which means the effort to fix such issue, is equal to 2 minutes plus 5 minutes per type in typesOutOfMainNamespace. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND2104:TypesWithSourceFilesStoredInTheSameDirectoryShouldBeDeclaredInTheSameNamespace", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
2 namespaces matched -
-
- Formatting: bold means added, underlined means code was changed,
strike-boldmeans removed (since baseline) -
| 2 namespaces | typesOutOfMainNamespace | typesInMainNamespace | Debt | Severity | Full Name |
|---|---|---|---|---|---|
| FlightSystem.Api.Domain.Entities | 4 types | 4 types | 22min | High | FlightSystem.Api.Domain.Entities |
| FlightSystem.Api.Src.Application .JourneyInfo | 1 type | 1 type | 7min | High | FlightSystem.Api.Src.Application .JourneyInfo |
Hot Spots
 | Code Query: Types Hot Spots |
• Query Description:
-This query lists types with most Debt, or in other words, types with issues that would need the largest effort to get fixed.
-Both issues on the type and its members are taken account.
-Since untested code often generates a lot of Debt, the type size and percentage coverage is shown (just uncomment t.PercentageCoverage in the query source code once you've imported the coverage data).
-The Debt Rating and Debt Ratio are also shown for informational purpose.
---
-The amount of Debt is not a measure to prioritize the effort to fix issues, it is an estimation of how far the team is from clean code that abides by the rules set.
-For each issue the Annual Interest estimates the annual cost to leave the issues unfixed. The Severity of an issue is estimated through thresholds from the Annual Interest.
-The Debt Breaking Point represents the duration from now when the estimated cost to leave the issue unfixed costs as much as the estimated effort to fix it.
-Hence the shorter the Debt Breaking Point the largest the Return on Investment for fixing the issue. The Breaking Point is the right metric to prioritize issues fix.
23 types matched -
| 23 types | Debt | Issues | Annual Interest | Breaking Point | # lines of code (LOC) | DebtRating | DebtRatio | Full Name |
|---|---|---|---|---|---|---|---|---|
| JourneyManager | 2h 26min | 4 issues | 15min | 3 521d | 18 | E | 67.68 | FlightSystem.Api.Src.Application .RouteInfo.JourneyManager |
| FlightParser | 1h 17min | 3 issues | 7min | 3 714d | 1 | E | 223.06 | FlightSystem.Api.Src.Integration.Neo4J .Data.FlightParser |
| JourneyController | 1h 14min | 2 issues | 7min | 3 569d | 9 | E | 61.25 | FlightSystem.Api.Src.Integration .Controllers.JourneyController |
| IJourney | 1h 9min | 1 issue | 5min | 4 522d | N/A | E | 399.83 | FlightSystem.Api.Src.Application.Common .IJourney |
| RouteManager | 32min | 7 issues | 32min | 365d | 45 | B | 6.28 | FlightSystem.Api.Src.Application .JourneyInfo.RouteManager |
| LocationManager | 19min | 5 issues | 10min | 693d | 7 | C | 16.92 | FlightSystem.Api.Src.Application .AirportInfo.LocationManager |
| Neo4JContext | 16min | 4 issues | 30min | 194d | 6 | C | 16.84 | FlightSystem.Api.Src.Integration.Neo4J .Neo4JContext |
| Route | 13min | 5 issues | 58min | 86d | 11 | B | 8.79 | FlightSystem.Api.Src.Domain.Entities .Route |
| Trip | 13min | 5 issues | 58min | 86d | 2 | D | 22.6 | FlightSystem.Api.Src.Domain.Entities .Trip |
| RouteData | 10min | 3 issues | 34min | 110d | 68 | A | 1.59 | FlightSystem.Api.Src.Integration.Neo4J .Data.RouteData |
| FlightManager | 8min | 2 issues | 4min 0s | 730d | 4 | B | 9.26 | FlightSystem.Api.Src.Application .FlightInfo.FlightManager |
| AllFlightsController | 5min | 1 issue | 2min 0s | 912d | 9 | A | 4.13 | FlightSystem.Api.Src.Integration .Controllers.AllFlightsController |
| FlightController | 5min | 1 issue | 2min 0s | 912d | 9 | A | 4.13 | FlightSystem.Api.Src.Integration .Controllers.FlightController |
| FlightData | 5min | 1 issue | 2min 0s | 912d | 33 | A | 1.45 | FlightSystem.Api.Src.Integration.Neo4J .Data.FlightData |
| Entity | 5min | 1 issue | 2min 0s | 912d | 0 | D | 28.94 | FlightSystem.Api.Src.Domain.Common .Entity |
| AllLocationsController | 4min 0s | 2 issues | 8min | 182d | 10 | A | 3.09 | FlightSystem.Api.Src.Integration .Controllers.AllLocationsController |
| FlagImageData | 3min 0s | 2 issues | 2min 0s | 547d | 10 | A | 2.48 | FlightSystem.Api.Src.Integration .FileSystem.FlagImageData |
| Response | 2min 0s | 2 issues | 12min | 60d | 2 | A | 3.86 | FlightSystem.Api.Src.Integration.Common .Response |
| ResponseBody | 1min 0s | 1 issue | 6min | 60d | 1 | A | 2.89 | FlightSystem.Api.Src.Integration.Common .ResponseBody |
| ResponseHeader | 1min 0s | 1 issue | 6min | 60d | 1 | A | 2.89 | FlightSystem.Api.Src.Integration.Common .ResponseHeader |
| AirportData | 1min 0s | 1 issue | 2min 0s | 182d | 10 | A | 0.83 | FlightSystem.Api.Src.Integration.Neo4J .Data.AirportData |
| CountryData | 1min 0s | 1 issue | 2min 0s | 182d | 10 | A | 0.83 | FlightSystem.Api.Src.Integration.Neo4J .Data.CountryData |
| Journey | 1min 0s | 1 issue | 6min | 60d | 6 | A | 0.89 | FlightSystem.Api.Src.Domain.Entities .Journey |
Statistics
| Stat | Debt | Issues | Annual Interest | Breaking Point | # lines of code (LOC) | DebtRating | DebtRatio |
|---|---|---|---|---|---|---|---|
| Sum: | 1d 0h | 56 | 5h 13min | 22 582d | 272 | - | 890.49 |
| Average: | 22min | 2.43 | 13min | 981d | 12.36 | - | 38.72 |
| Minimum: | 1min 0s | 1 | 2min 0s | 60d | 0 | - | 0.83 |
| Maximum: | 2h 26min | 7 | 58min | 4 522d | 68 | - | 399.83 |
| Standard deviation: | 35min | 1.72 | 16min | 1 354d | 15.97 | - | 89.85 |
| Variance: | 154d | 2.94 | 34d | overflow | 255.05 | - | 8 073 |
| Code Query: Types to Fix Priority |
• Query Description:
-This query lists types per increasing Debt Breaking Point.
-For each issue the Debt estimates the effort to fix the issue, and the Annual Interest estimates the annual cost to leave the issue unfixed. The Severity of an issue is estimated through thresholds from the Annual Interest of the issue.
-The Debt Breaking Point represents the duration from now when the estimated cost to leave the issue unfixed costs as much as the estimated effort to fix it.
-Hence the shorter the Debt Breaking Point the largest the Return on Investment for fixing the issues.
-Often new and refactored types since baseline will be listed first, because issues on these types get a higher Annual Interest because it is important to focus first on new issues.
---
-Both issues on the type and its members are taken account.
-Only types with at least 30 minutes of Debt are listed to avoid parasiting the list with the numerous types with small Debt, on which the Breaking Point value makes less sense.
-The Annual Interest estimates the cost per year in man-days to leave these issues unfixed.
-Since untested code often generates a lot of Debt, the type size and percentage coverage is shown (just uncomment t.PercentageCoverage in the query source code once you've imported the coverage data).
-The Debt Rating and Debt Ratio are also shown for informational purpose.
5 types matched -
| 5 types | Breaking Point | Debt | Annual Interest | Issues | # lines of code (LOC) | DebtRating | DebtRatio | Full Name |
|---|---|---|---|---|---|---|---|---|
| RouteManager | 365d | 32min | 32min | 7 issues | 45 | B | 6.28 | FlightSystem.Api.Src.Application .JourneyInfo.RouteManager |
| JourneyManager | 3 521d | 2h 26min | 15min | 4 issues | 18 | E | 67.68 | FlightSystem.Api.Src.Application .RouteInfo.JourneyManager |
| JourneyController | 3 569d | 1h 14min | 7min | 2 issues | 9 | E | 61.25 | FlightSystem.Api.Src.Integration .Controllers.JourneyController |
| FlightParser | 3 714d | 1h 17min | 7min | 3 issues | 1 | E | 223.06 | FlightSystem.Api.Src.Integration.Neo4J .Data.FlightParser |
| IJourney | 4 522d | 1h 9min | 5min | 1 issue | N/A | E | 399.83 | FlightSystem.Api.Src.Application.Common .IJourney |
Statistics
| Stat | Breaking Point | Debt | Annual Interest | Issues | # lines of code (LOC) | DebtRating | DebtRatio |
|---|---|---|---|---|---|---|---|
| Sum: | 15 693d | 6h 38min | 1h 7min | 17 | 73 | - | 758.1 |
| Average: | 3 138d | 1h 19min | 13min | 3.4 | 18.25 | - | 151.62 |
| Minimum: | 365d | 32min | 5min | 1 | 1 | - | 6.28 |
| Maximum: | 4 522d | 2h 26min | 32min | 7 | 45 | - | 399.83 |
| Standard deviation: | 1 433d | 37min | 9min | 2.06 | 16.57 | - | 143.56 |
| Variance: | overflow | 171d | 11d 7h | 4.24 | 274.69 | - | 20 610 |
| Code Query: Issues to Fix Priority |
• Query Description:
-This query lists issues per increasing Debt Breaking Point.
-Double-click an issue to edit its rule and select the issue in the rule result. This way you can view all information concerning the issue.
-For each issue the Debt estimates the effort to fix the issue, and the Annual Interest estimates the annual cost to leave the issue unfixed. The Severity of an issue is estimated through thresholds from the Annual Interest of the issue.
-The Debt Breaking Point represents the duration from now when the estimated cost to leave the issue unfixed costs as much as the estimated effort to fix it.
-Hence the shorter the Debt Breaking Point the largest the Return on Investment for fixing the issue.
-Often issues on new and refactored code elements since baseline will be listed first, because such issues get a higher Annual Interest because it is important to focus first on new issues on recent code.
-More documentation: https://www.ndepend.com/docs/technical-debt
67 issues matched -
| 67 issues | Debt | Annual Interest | Breaking Point | CodeElement | Full Name |
|---|---|---|---|---|---|
| High issue on: FlightSystem.Api.Src .Integration.Neo4J.Neo4JContext.Driver | 2min 0s | 20min | 36d | Driver | Rule violated: Avoid non-readonly static fields |
| Medium issue on: FlightSystem.Api.Src .Integration.Neo4J.Data.RouteData .FillRouteData(IRecord) | 2min 12s | 16min | 50d | FillRouteData(IRecord) | Rule violated: Avoid methods potentially poorly commented |
| Medium issue on: FlightSystem.Api.Src .Integration.Controllers .AllLocationsController.LocationMan | 1min 0s | 6min | 60d | LocationMan | Rule violated: Fields should be declared as private |
| Medium issue on: FlightSystem.Api.Src .Integration.Common.Response .responseHeader | 1min 0s | 6min | 60d | responseHeader | Rule violated: Fields should be declared as private |
| Medium issue on: FlightSystem.Api.Src .Integration.Common.Response .responseBody | 1min 0s | 6min | 60d | responseBody | Rule violated: Fields should be declared as private |
| Medium issue on: FlightSystem.Api.Src .Integration.Common.ResponseBody .entities | 1min 0s | 6min | 60d | entities | Rule violated: Fields should be declared as private |
| Medium issue on: FlightSystem.Api.Src .Integration.Common.ResponseHeader .responseError | 1min 0s | 6min | 60d | responseError | Rule violated: Fields should be declared as private |
| Medium issue on: FlightSystem.Api.Src .Integration.Neo4J.Neo4JContext.Driver | 1min 0s | 6min | 60d | Driver | Rule violated: Fields should be declared as private |
| Medium issue on: FlightSystem.Api.Src .Domain.Entities.Journey.trips | 1min 0s | 6min | 60d | trips | Rule violated: Fields should be declared as private |
| Medium issue on: FlightSystem.Api.Src .Domain.Entities.Route.flights | 1min 0s | 6min | 60d | flights | Rule violated: Fields should be declared as private |
| Medium issue on: FlightSystem.Api.Src .Domain.Entities.Trip.tripParams | 1min 0s | 6min | 60d | tripParams | Rule violated: Fields should be declared as private |
| Medium issue on: FlightSystem.Api.Src .Integration.Neo4J.Data.RouteData .FillRoute2Data(IRecord) | 3min 6s | 16min | 70d | FillRoute2Data(IRecord) | Rule violated: Avoid methods potentially poorly commented |
| Medium issue on: FlightSystem.Api.Src .Domain.Entities.Route.price | 1min 20s | 6min | 81d | price | Rule violated: Fields should be declared as private |
| Medium issue on: FlightSystem.Api.Src .Domain.Entities.Route.timeSpan | 1min 20s | 6min | 81d | timeSpan | Rule violated: Fields should be declared as private |
| Medium issue on: FlightSystem.Api.Src .Domain.Entities.Trip.numOfRoutes | 1min 20s | 6min | 81d | numOfRoutes | Rule violated: Fields should be declared as private |
| Medium issue on: FlightSystem.Api.Src .Domain.Entities.Trip.routes | 1min 20s | 6min | 81d | routes | Rule violated: Fields should be declared as private |
| High issue on: FlightSystem.Api.Src .Domain.Entities.Route.price | 5min | 20min | 91d | price | Rule violated: A field must not be assigned from outside its parent hierarchy types |
| High issue on: FlightSystem.Api.Src .Domain.Entities.Route.timeSpan | 5min | 20min | 91d | timeSpan | Rule violated: A field must not be assigned from outside its parent hierarchy types |
| High issue on: FlightSystem.Api.Src .Domain.Entities.Trip.numOfRoutes | 5min | 20min | 91d | numOfRoutes | Rule violated: A field must not be assigned from outside its parent hierarchy types |
| High issue on: FlightSystem.Api.Src .Domain.Entities.Trip.routes | 5min | 20min | 91d | routes | Rule violated: A field must not be assigned from outside its parent hierarchy types |
| High issue on: FlightSystem.Api.Src .Application.JourneyInfo | 7min | 20min | 127d | FlightSystem.Api.Src.Application.JourneyInfo | Rule violated: Types with source files stored in the same directory, should be declared in the same namespace |
| High issue on: FlightSystem.Api.Src .Application.JourneyInfo.RouteManager .numOfRoutes | 9min | 20min | 164d | numOfRoutes | Rule violated: Don't assign a field from many methods |
| Medium issue on: FlightSystem.Api.Src .Integration.FileSystem.FlagImageData .GetFlagImageString(String) | 1min 0s | 2min 0s | 182d | GetFlagImageString(String) | Rule violated: Methods should be declared static if possible |
| Medium issue on: FlightSystem.Api.Src .Integration.Neo4J.Data.AirportData .GetAirportFromResult(INode) | 1min 0s | 2min 0s | 182d | GetAirportFromResult(INode) | Rule violated: Methods should be declared static if possible |
| Medium issue on: FlightSystem.Api.Src .Integration.Neo4J.Data.CountryData .GetCountryFromResult(INode) | 1min 0s | 2min 0s | 182d | GetCountryFromResult(INode) | Rule violated: Methods should be declared static if possible |
| Medium issue on: FlightSystem.Api.Src .Application.JourneyInfo.RouteManager .SortAndCutRoutes(List<Route>) | 1min 0s | 2min 0s | 182d | SortAndCutRoutes(List<Route>) | Rule violated: Methods should be declared static if possible |
| Medium issue on: FlightSystem.Api.Src .Integration.Neo4J.Data.FlightParser .GetFlight(String,INode,String,String ,String,String,INode,INode) | 2min 0s | 2min 0s | 365d | GetFlight(String,INode,String,String,String,String,INode,INode) | Rule violated: Methods should be declared static if possible |
| Medium issue on: FlightSystem.Api.Src .Application.JourneyInfo.RouteManager .AddRouteInfo(List<Route>) | 2min 0s | 2min 0s | 365d | AddRouteInfo(List<Route>) | Rule violated: Methods should be declared static if possible |
| High issue on: FlightSystem.Api.Domain.Entities | 22min | 20min | 401d | FlightSystem.Api.Domain.Entities | Rule violated: Types with source files stored in the same directory, should be declared in the same namespace |
| Medium issue on: FlightSystem.Api.Src .Integration.Neo4J.Neo4JContext.RunQuery (String) | 3min 0s | 2min 0s | 547d | RunQuery(String) | Rule violated: Do implement methods that throw NotImplementedException |
| Medium issue on: FlightSystem.Api.Src .Integration.Controllers .AllLocationsController.LocationMan | 3min 0s | 2min 0s | 547d | LocationMan | Rule violated: Instance fields naming convention |
| Medium issue on: FlightSystem.Api.Src .Application.AirportInfo.LocationManager .AirportData | 3min 0s | 2min 0s | 547d | AirportData | Rule violated: Instance fields naming convention |
| Medium issue on: FlightSystem.Api.Src .Application.AirportInfo.LocationManager .CountryData | 3min 0s | 2min 0s | 547d | CountryData | Rule violated: Instance fields naming convention |
| Medium issue on: FlightSystem.Api.Src .Application.FlightInfo.FlightManager .FlightData | 3min 0s | 2min 0s | 547d | FlightData | Rule violated: Instance fields naming convention |
| Medium issue on: FlightSystem.Api.Src .Application.AirportInfo.LocationManager | 3min 0s | 2min 0s | 547d | LocationManager | Rule violated: Namespace name should correspond to file location |
| Medium issue on: FlightSystem.Api.Src .Application.RouteInfo.JourneyManager | 3min 0s | 2min 0s | 547d | JourneyManager | Rule violated: Namespace name should correspond to file location |
| Medium issue on: FlightSystem.Api.Src .Integration.Controllers .AllFlightsController.flight | 5min | 2min 0s | 912d | flight | Rule violated: Fields should be marked as ReadOnly when possible |
| Medium issue on: FlightSystem.Api.Src .Integration.Controllers .FlightController.flight | 5min | 2min 0s | 912d | flight | Rule violated: Fields should be marked as ReadOnly when possible |
| Medium issue on: FlightSystem.Api.Src .Integration.Controllers .JourneyController.journeyMan | 5min | 2min 0s | 912d | journeyMan | Rule violated: Fields should be marked as ReadOnly when possible |
| Medium issue on: FlightSystem.Api.Src .Integration.Neo4J.Data.FlightData .flightParser | 5min | 2min 0s | 912d | flightParser | Rule violated: Fields should be marked as ReadOnly when possible |
| Medium issue on: FlightSystem.Api.Src .Integration.Neo4J.Data.RouteData .flightParser | 5min | 2min 0s | 912d | flightParser | Rule violated: Fields should be marked as ReadOnly when possible |
| Medium issue on: FlightSystem.Api.Src .Application.AirportInfo.LocationManager .AirportData | 5min | 2min 0s | 912d | AirportData | Rule violated: Fields should be marked as ReadOnly when possible |
| Medium issue on: FlightSystem.Api.Src .Application.AirportInfo.LocationManager .CountryData | 5min | 2min 0s | 912d | CountryData | Rule violated: Fields should be marked as ReadOnly when possible |
| Medium issue on: FlightSystem.Api.Src .Application.JourneyInfo.RouteManager .flightMan | 5min | 2min 0s | 912d | flightMan | Rule violated: Fields should be marked as ReadOnly when possible |
| Medium issue on: FlightSystem.Api.Src .Application.JourneyInfo.RouteManager .routeData | 5min | 2min 0s | 912d | routeData | Rule violated: Fields should be marked as ReadOnly when possible |
| Medium issue on: FlightSystem.Api.Src .Application.JourneyInfo.RouteManager .maxRoutesFromDb | 5min | 2min 0s | 912d | maxRoutesFromDb | Rule violated: Fields should be marked as ReadOnly when possible |
| Medium issue on: FlightSystem.Api.Src .Application.JourneyInfo.RouteManager .maxRoutesReturn | 5min | 2min 0s | 912d | maxRoutesReturn | Rule violated: Fields should be marked as ReadOnly when possible |
| Medium issue on: FlightSystem.Api.Src .Application.RouteInfo.JourneyManager .routeMan | 5min | 2min 0s | 912d | routeMan | Rule violated: Fields should be marked as ReadOnly when possible |
| Medium issue on: FlightSystem.Api.Src .Application.FlightInfo.FlightManager .FlightData | 5min | 2min 0s | 912d | FlightData | Rule violated: Fields should be marked as ReadOnly when possible |
| Medium issue on: FlightSystem.Api.Src .Domain.Common.Entity | 5min | 2min 0s | 912d | Entity | Rule violated: Abstract base class should be suffixed with 'Base' |
| Medium issue on: FlightSystem.Api.Src .Integration.Neo4J.Neo4JContext | 10min | 2min 0s | 1 825d | Neo4JContext | Rule violated: Avoid prefixing type name with parent namespace name |
| Medium issue on: FlightSystem.Api.Src .Integration.Controllers .JourneyController.Get(Boolean,String ,String,String,String,Boolean,Int32 ,String) | 1h 9min | 5min | 4 522d | Get(Boolean,String,String,String,String,Boolean,Int32,String) | Rule violated: Avoid methods with too many parameters |
| Medium issue on: FlightSystem.Api.Src .Integration.Neo4J.Data.FlightParser .GetFlight(String,INode,String,String ,String,String,INode,INode) | 1h 9min | 5min | 4 522d | GetFlight(String,INode,String,String,String,String,INode,INode) | Rule violated: Avoid methods with too many parameters |
| Medium issue on: FlightSystem.Api.Src .Application.RouteInfo.JourneyManager .GetJourney(Boolean,String,String,String ,String,Boolean,Int32,String) | 1h 9min | 5min | 4 522d | GetJourney(Boolean,String,String,String,String,Boolean,Int32,String) | Rule violated: Avoid methods with too many parameters |
| Medium issue on: FlightSystem.Api.Src .Application.RouteInfo.JourneyManager .FormSearchRequest(Boolean,String,String ,String,String,Boolean,Int32,String) | 1h 9min | 5min | 4 522d | FormSearchRequest(Boolean,String,String,String,String,Boolean,Int32,String) | Rule violated: Avoid methods with too many parameters |
| Medium issue on: FlightSystem.Api.Src .Application.Common.IJourney.GetJourney (Boolean,String,String,String,String ,Boolean,Int32,String) | 1h 9min | 5min | 4 522d | GetJourney(Boolean,String,String,String,String,Boolean,Int32,String) | Rule violated: Avoid methods with too many parameters |
| Low issue on: FlightSystem.Api.Src .Integration.FileSystem.FlagImageData | 2min 0s | 0min 0s | 00:00:00 | FlagImageData | Rule violated: A stateless class or structure might be turned into a static type |
| Low issue on: FlightSystem.Api.Src .Integration.Neo4J.Data.FlightParser | 6min | 0min 0s | 00:00:00 | FlightParser | Rule violated: A stateless class or structure might be turned into a static type |
| Low issue on: FlightSystem.Api.Src.Common | 5min | 0min 0s | 00:00:00 | FlightSystem.Api.Src.Common | Rule violated: Avoid namespaces with few types |
| Low issue on: FlightSystem.Api.Src .Integration.FileSystem | 5min | 0min 0s | 00:00:00 | FlightSystem.Api.Src.Integration.FileSystem | Rule violated: Avoid namespaces with few types |
| Low issue on: FlightSystem.Api.Src.Integration.Neo4J | 5min | 0min 0s | 00:00:00 | FlightSystem.Api.Src.Integration.Neo4J | Rule violated: Avoid namespaces with few types |
| Low issue on: FlightSystem.Api.Src.Domain.Common | 5min | 0min 0s | 00:00:00 | FlightSystem.Api.Src.Domain.Common | Rule violated: Avoid namespaces with few types |
| Low issue on: FlightSystem.Api.Src .Application.AirportInfo | 5min | 0min 0s | 00:00:00 | FlightSystem.Api.Src.Application.AirportInfo | Rule violated: Avoid namespaces with few types |
| Low issue on: FlightSystem.Api.Src .Application.JourneyInfo | 5min | 0min 0s | 00:00:00 | FlightSystem.Api.Src.Application.JourneyInfo | Rule violated: Avoid namespaces with few types |
| Low issue on: FlightSystem.Api.Src .Application.RouteInfo | 5min | 0min 0s | 00:00:00 | FlightSystem.Api.Src.Application.RouteInfo | Rule violated: Avoid namespaces with few types |
| Low issue on: FlightSystem.Api.Src .Application.FlightInfo | 5min | 0min 0s | 00:00:00 | FlightSystem.Api.Src.Application.FlightInfo | Rule violated: Avoid namespaces with few types |
| Low issue on: FlightSystem.Api.Src.Application.Common | 5min | 0min 0s | 00:00:00 | FlightSystem.Api.Src.Application.Common | Rule violated: Avoid namespaces with few types |
Statistics
| Stat | Debt | Annual Interest | Breaking Point | CodeElement |
|---|---|---|---|---|
| Sum: | 1d 1h | 5h 53min | 44 594d | - |
| Average: | 8min | 5min | 665d | - |
| Minimum: | 1min 0s | 0min 0s | 00:00:00 | - |
| Maximum: | 1h 9min | 20min | 4 522d | - |
| Standard deviation: | 17min | 6min | 1 161d | - |
| Variance: | 37d | 4d 6h | overflow | - |
| Code Query: Debt and Issues per Rule |
• Query Description:
-This query lists violated rules with most Debt first.
-A rule violated has issues. For each issue the Debt estimates the effort to fix the issue.
---
-The amount of Debt is not a measure to prioritize the effort to fix issues, it is an estimation of how far the team is from clean code that abides by the rules set.
-For each issue the Annual Interest estimates the annual cost to leave the issues unfixed. The Severity of an issue is estimated through thresholds from the Annual Interest.
-The Debt Breaking Point represents the duration from now when the estimated cost to leave the issue unfixed costs as much as the estimated effort to fix it.
-Hence the shorter the Debt Breaking Point the largest the Return on Investment for fixing the issue. The Breaking Point is the right metric to prioritize issues fix.
---
-Notice that rules can be grouped in Rule Category. This way you'll see categories that generate most Debt.
-Typically the rules that generate most Debt are the ones related to Code Coverage by Tests, Architecture and Code Smells.
-More documentation: https://www.ndepend.com/docs/technical-debt
16 rules matched -
| 16 rules | Issues | Debt | Annual Interest | Breaking Point | Category | Full Name |
|---|---|---|---|---|---|---|
| Avoid methods with too many parameters | 5 issues | 5h 45min | 27min | 4 522d | Project Rules \ Code Smells | Rule |
| Fields should be marked as ReadOnly when possible | 13 issues | 1h 5min | 26min | 912d | Project Rules \ Immutability | Rule |
| Avoid namespaces with few types | 9 issues | 45min | 0min 0s | 00:00:00 | Project Rules \ Design | Rule |
| Types with source files stored in the same directory, should be declared in the same namespace | 2 issues | 29min | 40min | 264d | Project Rules \ Source Files Organization | Rule |
| A field must not be assigned from outside its parent hierarchy types | 4 issues | 20min | 1h 20min | 91d | Project Rules \ Immutability | Rule |
| Fields should be declared as private | 13 issues | 14min | 1h 18min | 67d | Project Rules \ Visibility | Rule |
| Instance fields naming convention | 4 issues | 12min | 8min | 547d | Project Rules \ Naming Conventions | Rule |
| Avoid prefixing type name with parent namespace name | 1 issue | 10min | 2min 0s | 1 825d | Project Rules \ Naming Conventions | Rule |
| Don't assign a field from many methods | 1 issue | 9min | 20min | 164d | Project Rules \ Immutability | Rule |
| A stateless class or structure might be turned into a static type | 2 issues | 8min | 0min 0s | 00:00:00 | Project Rules \ Object Oriented Design | Rule |
| Methods should be declared static if possible | 6 issues | 8min | 12min | 243d | Project Rules \ Object Oriented Design | Rule |
| Namespace name should correspond to file location | 2 issues | 6min | 4min 0s | 547d | Project Rules \ Source Files Organization | Rule |
| Avoid methods potentially poorly commented | 2 issues | 5min | 32min | 60d | Project Rules \ Code Smells | Rule |
| Abstract base class should be suffixed with 'Base' | 1 issue | 5min | 2min 0s | 912d | Project Rules \ Naming Conventions | Rule |
| Do implement methods that throw NotImplementedException | 1 issue | 3min 0s | 2min 0s | 547d | Project Rules \ Design | Rule |
| Avoid non-readonly static fields | 1 issue | 2min 0s | 20min | 36d | Project Rules \ Immutability | Rule |
Statistics
| Stat | Issues | Debt | Annual Interest | Breaking Point | Category |
|---|---|---|---|---|---|
| Sum: | 67 | 1d 1h | 5h 53min | 10 742d | - |
| Average: | 4.19 | 36min | 22min | 671d | - |
| Minimum: | 1 | 2min 0s | 0min 0s | 00:00:00 | - |
| Maximum: | 13 | 5h 45min | 1h 20min | 4 522d | - |
| Standard deviation: | 3.97 | 1h 21min | 24min | 1 098d | - |
| Variance: | 15.78 | 828d | 76d | overflow | - |
| Code Query: New Debt and Issues per Rule |
• Query Description:
-This query lists violated rules that have new issues since baseline, with most new Debt first.
-A rule violated has issues. For each issue the Debt estimates the effort to fix the issue.
---
-New issues since the baseline are consequence of recent code refactoring sessions. They represent good opportunities of fix because the code recently refactored is fresh in the developers mind, which means fixing now costs less than fixing later.
-Fixing issues on recently touched code is also a good way to foster practices that will lead to higher code quality and maintainability, including writing unit-tests and avoiding unnecessary complex code.
---
-Notice that rules can be grouped in Rule Category. This way you'll see categories that generate most Debt.
-Typically the rules that generate most Debt are the ones related to Code Coverage by Tests, Architecture and Code Smells.
-More documentation: https://www.ndepend.com/docs/technical-debt
- No rule matched -
| Code Query: Debt and Issues per Code Element |
• Query Description:
-This query lists code elements that have issues, with most Debt first.
-For each code element the Debt estimates the effort to fix the element issues.
-The amount of Debt is not a measure to prioritize the effort to fix issues, it is an estimation of how far the team is from clean code that abides by the rules set.
-For each element the Annual Interest estimates the annual cost to leave the elements issues unfixed. The Severity of an issue is estimated through thresholds from the Annual Interest of the issue.
-The Debt Breaking Point represents the duration from now when the estimated cost to leave the issues unfixed costs as much as the estimated effort to fix it.
-Hence the shorter the Debt Breaking Point the largest the Return on Investment for fixing the issue. The Breaking Point is the right metric to prioritize issues fix.
56 code elements matched -
| 56 code elements | Issues | Debt | Annual Interest | Breaking Point | Full Name |
|---|---|---|---|---|---|
| GetFlight(String,INode,String,String ,String,String,INode,INode) | 2 issues | 1h 11min | 7min | 3 425d | FlightSystem.Api.Src.Integration.Neo4J .Data.FlightParser.GetFlight(String ,INode,String,String,String,String,INode ,INode) |
| Get(Boolean,String,String,String,String ,Boolean,Int32,String) | 1 issue | 1h 9min | 5min | 4 522d | FlightSystem.Api.Src.Integration .Controllers.JourneyController.Get (Boolean,String,String,String,String ,Boolean,Int32,String) |
| GetJourney(Boolean,String,String,String ,String,Boolean,Int32,String) | 1 issue | 1h 9min | 5min | 4 522d | FlightSystem.Api.Src.Application .RouteInfo.JourneyManager.GetJourney (Boolean,String,String,String,String ,Boolean,Int32,String) |
| FormSearchRequest(Boolean,String,String ,String,String,Boolean,Int32,String) | 1 issue | 1h 9min | 5min | 4 522d | FlightSystem.Api.Src.Application .RouteInfo.JourneyManager .FormSearchRequest(Boolean,String,String ,String,String,Boolean,Int32,String) |
| GetJourney(Boolean,String,String,String ,String,Boolean,Int32,String) | 1 issue | 1h 9min | 5min | 4 522d | FlightSystem.Api.Src.Application.Common .IJourney.GetJourney(Boolean,String ,String,String,String,Boolean,Int32 ,String) |
| FlightSystem.Api.Domain.Entities | 1 issue | 22min | 20min | 401d | FlightSystem.Api.Domain.Entities |
| FlightSystem.Api.Src.Application .JourneyInfo | 2 issues | 12min | 20min | 219d | FlightSystem.Api.Src.Application .JourneyInfo |
| Neo4JContext | 1 issue | 10min | 2min 0s | 1 825d | FlightSystem.Api.Src.Integration.Neo4J .Neo4JContext |
| numOfRoutes | 1 issue | 9min | 20min | 164d | FlightSystem.Api.Src.Application .JourneyInfo.RouteManager.numOfRoutes |
| AirportData | 2 issues | 8min | 4min 0s | 730d | FlightSystem.Api.Src.Application .AirportInfo.LocationManager.AirportData |
| CountryData | 2 issues | 8min | 4min 0s | 730d | FlightSystem.Api.Src.Application .AirportInfo.LocationManager.CountryData |
| FlightData | 2 issues | 8min | 4min 0s | 730d | FlightSystem.Api.Src.Application .FlightInfo.FlightManager.FlightData |
| price | 2 issues | 6min | 26min | 88d | FlightSystem.Api.Src.Domain.Entities .Route.price |
| timeSpan | 2 issues | 6min | 26min | 88d | FlightSystem.Api.Src.Domain.Entities .Route.timeSpan |
| numOfRoutes | 2 issues | 6min | 26min | 88d | FlightSystem.Api.Src.Domain.Entities .Trip.numOfRoutes |
| routes | 2 issues | 6min | 26min | 88d | FlightSystem.Api.Src.Domain.Entities .Trip.routes |
| FlightParser | 1 issue | 6min | 0min 0s | 00:00:00 | FlightSystem.Api.Src.Integration.Neo4J .Data.FlightParser |
| FlightSystem.Api.Src.Common | 1 issue | 5min | 0min 0s | 00:00:00 | FlightSystem.Api.Src.Common |
| FlightSystem.Api.Src.Integration .FileSystem | 1 issue | 5min | 0min 0s | 00:00:00 | FlightSystem.Api.Src.Integration .FileSystem |
| flight | 1 issue | 5min | 2min 0s | 912d | FlightSystem.Api.Src.Integration .Controllers.AllFlightsController.flight |
| flight | 1 issue | 5min | 2min 0s | 912d | FlightSystem.Api.Src.Integration .Controllers.FlightController.flight |
| journeyMan | 1 issue | 5min | 2min 0s | 912d | FlightSystem.Api.Src.Integration .Controllers.JourneyController .journeyMan |
| FlightSystem.Api.Src.Integration.Neo4J | 1 issue | 5min | 0min 0s | 00:00:00 | FlightSystem.Api.Src.Integration.Neo4J |
| flightParser | 1 issue | 5min | 2min 0s | 912d | FlightSystem.Api.Src.Integration.Neo4J .Data.FlightData.flightParser |
| flightParser | 1 issue | 5min | 2min 0s | 912d | FlightSystem.Api.Src.Integration.Neo4J .Data.RouteData.flightParser |
| FlightSystem.Api.Src.Domain.Common | 1 issue | 5min | 0min 0s | 00:00:00 | FlightSystem.Api.Src.Domain.Common |
| Entity | 1 issue | 5min | 2min 0s | 912d | FlightSystem.Api.Src.Domain.Common .Entity |
| FlightSystem.Api.Src.Application .AirportInfo | 1 issue | 5min | 0min 0s | 00:00:00 | FlightSystem.Api.Src.Application .AirportInfo |
| flightMan | 1 issue | 5min | 2min 0s | 912d | FlightSystem.Api.Src.Application .JourneyInfo.RouteManager.flightMan |
| routeData | 1 issue | 5min | 2min 0s | 912d | FlightSystem.Api.Src.Application .JourneyInfo.RouteManager.routeData |
| maxRoutesFromDb | 1 issue | 5min | 2min 0s | 912d | FlightSystem.Api.Src.Application .JourneyInfo.RouteManager .maxRoutesFromDb |
| maxRoutesReturn | 1 issue | 5min | 2min 0s | 912d | FlightSystem.Api.Src.Application .JourneyInfo.RouteManager .maxRoutesReturn |
| FlightSystem.Api.Src.Application .RouteInfo | 1 issue | 5min | 0min 0s | 00:00:00 | FlightSystem.Api.Src.Application .RouteInfo |
| routeMan | 1 issue | 5min | 2min 0s | 912d | FlightSystem.Api.Src.Application .RouteInfo.JourneyManager.routeMan |
| FlightSystem.Api.Src.Application .FlightInfo | 1 issue | 5min | 0min 0s | 00:00:00 | FlightSystem.Api.Src.Application .FlightInfo |
| FlightSystem.Api.Src.Application.Common | 1 issue | 5min | 0min 0s | 00:00:00 | FlightSystem.Api.Src.Application.Common |
| LocationMan | 2 issues | 4min 0s | 8min | 182d | FlightSystem.Api.Src.Integration .Controllers.AllLocationsController .LocationMan |
| FillRoute2Data(IRecord) | 1 issue | 3min 6s | 16min | 70d | FlightSystem.Api.Src.Integration.Neo4J .Data.RouteData.FillRoute2Data(IRecord) |
| RunQuery(String) | 1 issue | 3min 0s | 2min 0s | 547d | FlightSystem.Api.Src.Integration.Neo4J .Neo4JContext.RunQuery(String) |
| Driver | 2 issues | 3min 0s | 26min | 42d | FlightSystem.Api.Src.Integration.Neo4J .Neo4JContext.Driver |
| LocationManager | 1 issue | 3min 0s | 2min 0s | 547d | FlightSystem.Api.Src.Application .AirportInfo.LocationManager |
| JourneyManager | 1 issue | 3min 0s | 2min 0s | 547d | FlightSystem.Api.Src.Application .RouteInfo.JourneyManager |
| FillRouteData(IRecord) | 1 issue | 2min 12s | 16min | 50d | FlightSystem.Api.Src.Integration.Neo4J .Data.RouteData.FillRouteData(IRecord) |
| FlagImageData | 1 issue | 2min 0s | 0min 0s | 00:00:00 | FlightSystem.Api.Src.Integration .FileSystem.FlagImageData |
| AddRouteInfo(List<Route>) | 1 issue | 2min 0s | 2min 0s | 365d | FlightSystem.Api.Src.Application .JourneyInfo.RouteManager.AddRouteInfo (List<Route>) |
| GetFlagImageString(String) | 1 issue | 1min 0s | 2min 0s | 182d | FlightSystem.Api.Src.Integration .FileSystem.FlagImageData .GetFlagImageString(String) |
| responseHeader | 1 issue | 1min 0s | 6min | 60d | FlightSystem.Api.Src.Integration.Common .Response.responseHeader |
| responseBody | 1 issue | 1min 0s | 6min | 60d | FlightSystem.Api.Src.Integration.Common .Response.responseBody |
| entities | 1 issue | 1min 0s | 6min | 60d | FlightSystem.Api.Src.Integration.Common .ResponseBody.entities |
| responseError | 1 issue | 1min 0s | 6min | 60d | FlightSystem.Api.Src.Integration.Common .ResponseHeader.responseError |
| GetAirportFromResult(INode) | 1 issue | 1min 0s | 2min 0s | 182d | FlightSystem.Api.Src.Integration.Neo4J .Data.AirportData.GetAirportFromResult (INode) |
| GetCountryFromResult(INode) | 1 issue | 1min 0s | 2min 0s | 182d | FlightSystem.Api.Src.Integration.Neo4J .Data.CountryData.GetCountryFromResult (INode) |
| trips | 1 issue | 1min 0s | 6min | 60d | FlightSystem.Api.Src.Domain.Entities .Journey.trips |
| flights | 1 issue | 1min 0s | 6min | 60d | FlightSystem.Api.Src.Domain.Entities .Route.flights |
| tripParams | 1 issue | 1min 0s | 6min | 60d | FlightSystem.Api.Src.Domain.Entities .Trip.tripParams |
| SortAndCutRoutes(List<Route>) | 1 issue | 1min 0s | 2min 0s | 182d | FlightSystem.Api.Src.Application .JourneyInfo.RouteManager .SortAndCutRoutes(List<Route>) |
Statistics
| Stat | Issues | Debt | Annual Interest | Breaking Point |
|---|---|---|---|---|
| Sum: | 67 | 1d 1h | 5h 53min | 40 218d |
| Average: | 1.2 | 10min | 6min | 718d |
| Minimum: | 1 | 1min 0s | 0min 0s | 00:00:00 |
| Maximum: | 2 | 1h 11min | 26min | 4 522d |
| Standard deviation: | 0.4 | 18min | 7min | 1 197d |
| Variance: | 0.16 | 44d | 7d 6h | overflow |
| Code Query: New Debt and Issues per Code Element |
• Query Description:
-This query lists code elements that have new issues since baseline, with most new Debt first.
-For each code element the Debt estimates the effort to fix the element issues.
-New issues since the baseline are consequence of recent code refactoring sessions. They represent good opportunities of fix because the code recently refactored is fresh in the developers mind, which means fixing now costs less than fixing later.
-Fixing issues on recently touched code is also a good way to foster practices that will lead to higher code quality and maintainability, including writing unit-tests and avoiding unnecessary complex code.
- No code element matched -
Object Oriented Design
|
| Validated Rule: Avoid interfaces too big |
• Rule Description:
-This rule matches interfaces with more than 10 methods. Interfaces are abstractions and are meant to simplify the code structure. An interface should represent a single responsibility. Making an interface too large, too complex, necessarily means that the interface has too many responsibilities.
-A property with getter or setter or both count as one method. An event count as one method.
-
-
- • How to Fix Issues of this Rule: -Typically to fix such issue, the interface must be refactored in a grape of smaller single-responsibility interfaces. -A classic example is a ISession large interface, responsible for holding states, run commands and offer various accesses and facilities. -The classic problem for a large public interface is that it has many clients that consume it. As a consequence splitting it in smaller interfaces has an important impact and it is not always feasible. -The estimated Debt, which means the effort to fix such issue, varies linearly from 20 minutes for an interface with 10 methods, up to 7 hours for an interface with 100 or more methods. The Debt is divided by two if the interface is not publicly visible, because in such situation only the current project is impacted by the refactoring. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1200:AvoidInterfacesTooBig", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- • How to Fix Issues of this Rule: -Typically to fix such issue, the interface must be refactored in a grape of smaller single-responsibility interfaces. -A classic example is a ISession large interface, responsible for holding states, run commands and offer various accesses and facilities. -The classic problem for a large public interface is that it has many clients that consume it. As a consequence splitting it in smaller interfaces has an important impact and it is not always feasible. -The estimated Debt, which means the effort to fix such issue, varies linearly from 20 minutes for an interface with 10 methods, up to 7 hours for an interface with 100 or more methods. The Debt is divided by two if the interface is not publicly visible, because in such situation only the current project is impacted by the refactoring. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1200:AvoidInterfacesTooBig", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- No type matched -
| Validated Rule: Base class should not use derivatives |
• Rule Description:
-In Object-Oriented Programming, the open/closed principle states: software entities (components, classes, methods, etc.) should be open for extension, but closed for modification. http://en.wikipedia.org/wiki/Open/closed_principle
-Hence a base class should be designed properly to make it easy to derive from, this is extension. But creating a new derived class, or modifying an existing one, shouldn't provoke any modification in the base class. And if a base class is using some derivative classes somehow, there are good chances that such modification will be needed.
-Extending the base class is not anymore a simple operation, this is not good design.
-Note that this rule doesn't warn when a base class is using a derived class that is nested in the base class and declared as private. In such situation we consider that the derived class is an encapsulated implementation detail of the base class.
-
-
- • How to Fix Issues of this Rule: -Understand the need for using derivatives, then imagine a new design, and then refactor. -Typically an algorithm in the base class needs to access something from derived classes. You can try to encapsulate this access behind an abstract or a virtual method. -If you see in the base class some conditions on typeof(DerivedClass) not only urgent refactoring is needed. Such condition can easily be replaced through an abstract or a virtual method. -Sometime you'll see a base class that creates instance of some derived classes. In such situation, certainly using the factory method pattern http://en.wikipedia.org/wiki/Factory_method_pattern or the abstract factory pattern http://en.wikipedia.org/wiki/Abstract_factory_pattern will improve the design. -The estimated Debt, which means the effort to fix such issue, is equal to 3 minutes per derived class used by the base class + 3 minutes per member of a derived class used by the base class. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1201:BaseClassShouldNotUseDerivatives", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- • How to Fix Issues of this Rule: -Understand the need for using derivatives, then imagine a new design, and then refactor. -Typically an algorithm in the base class needs to access something from derived classes. You can try to encapsulate this access behind an abstract or a virtual method. -If you see in the base class some conditions on typeof(DerivedClass) not only urgent refactoring is needed. Such condition can easily be replaced through an abstract or a virtual method. -Sometime you'll see a base class that creates instance of some derived classes. In such situation, certainly using the factory method pattern http://en.wikipedia.org/wiki/Factory_method_pattern or the abstract factory pattern http://en.wikipedia.org/wiki/Abstract_factory_pattern will improve the design. -The estimated Debt, which means the effort to fix such issue, is equal to 3 minutes per derived class used by the base class + 3 minutes per member of a derived class used by the base class. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1201:BaseClassShouldNotUseDerivatives", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- No type matched -
| Validated Rule: Class shouldn't be too deep in inheritance tree |
• Rule Description:
-This rule warns about classes having 3 or more base classes. Notice that third-party base classes are not counted because this rule is about your code design, not third-party libraries consumed design.
-In theory, there is nothing wrong having a long inheritance chain, if the modelization has been well thought out, if each base class is a well-designed refinement of the domain.
-In practice, modeling properly a domain demands a lot of effort and experience and more often than not, a long inheritance chain is a sign of confused design, that will be hard to work with and maintain.
-
-
- • How to Fix Issues of this Rule: -In Object-Oriented Programming, a well-known motto is Favor Composition over Inheritance. -This is because inheritance comes with pitfalls. In general, the implementation of a derived class is very bound up with the base class implementation. Also a base class exposes implementation details to its derived classes, that's why it's often said that inheritance breaks encapsulation. -On the other hands, Composition favors binding with interfaces over binding with implementations. Hence, not only the encapsulation is preserved, but the design is clearer, because interfaces make it explicit and less coupled. -Hence, to break a long inheritance chain, Composition is often a powerful way to enhance the design of the refactored underlying logic. -You can also read: http://en.wikipedia.org/wiki/Composition_over_inheritance and http://stackoverflow.com/questions/49002/prefer-composition-over-inheritance -The estimated Debt, which means the effort to fix such issue, depends linearly upon the depth of inheritance. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1202:ClassShouldntBeTooDeepInInheritanceTree", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- • How to Fix Issues of this Rule: -In Object-Oriented Programming, a well-known motto is Favor Composition over Inheritance. -This is because inheritance comes with pitfalls. In general, the implementation of a derived class is very bound up with the base class implementation. Also a base class exposes implementation details to its derived classes, that's why it's often said that inheritance breaks encapsulation. -On the other hands, Composition favors binding with interfaces over binding with implementations. Hence, not only the encapsulation is preserved, but the design is clearer, because interfaces make it explicit and less coupled. -Hence, to break a long inheritance chain, Composition is often a powerful way to enhance the design of the refactored underlying logic. -You can also read: http://en.wikipedia.org/wiki/Composition_over_inheritance and http://stackoverflow.com/questions/49002/prefer-composition-over-inheritance -The estimated Debt, which means the effort to fix such issue, depends linearly upon the depth of inheritance. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1202:ClassShouldntBeTooDeepInInheritanceTree", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- No type matched -
| Validated Rule: Class with no descendant should be sealed if possible |
• Rule Description:
-If a non-static class isn't declared with the keyword sealed, it means that it can be subclassed everywhere the non-sealed class is visible.
-Making a class a base class requires significant design effort. Subclassing a non-sealed class, not initially designed to be subclassed, will lead to unanticipated design issue.
-Most classes are non-sealed because developers don't care about the keyword sealed, not because the primary intention was to write a class that can be subclassed.
-There are minor performance gain in declaring a class as sealed. But the real benefit of doing so, is actually to express the intention: this class has not be designed to be a base class, hence it is not allowed to subclass it.
-Notice that by default this rule doesn't match public class to avoid matching classes that are intended to be sub-classed by third-party code using your library. If you are developing an application and not a library, just uncomment the clause !t.IsPubliclyVisible.
-
-
- • How to Fix Issues of this Rule: -For each matched class, take the time to assess if it is really meant to be subclassed. Certainly most matched class will end up being declared as sealed. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1203:ClassWithNoDescendantShouldBeSealedIfPossible", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- • How to Fix Issues of this Rule: -For each matched class, take the time to assess if it is really meant to be subclassed. Certainly most matched class will end up being declared as sealed. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1203:ClassWithNoDescendantShouldBeSealedIfPossible", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- No type matched -
| Validated Rule: Overrides of Method() should call base.Method() |
• Rule Description:
-Typically overrides of a base method, should refine or complete the behavior of the base method. If the base method is not called, the base behavior is not refined but it is replaced.
-Violations of this rule are a sign of design flaw, especially if the actual design provides valid reasons that advocates that the base behavior must be replaced and not refined.
-
-
- • How to Fix Issues of this Rule: -You should investigate if inheritance is the right choice to bind the base class implementation with the derived classes implementations. Does presenting the method with polymorphic behavior through an interface, would be a better design choice? -In such situation, often using the design pattern template method http://en.wikipedia.org/wiki/Template_method_pattern might help improving the design. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1204:OverridesOfMethodShouldCallBaseMethod", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- • How to Fix Issues of this Rule: -You should investigate if inheritance is the right choice to bind the base class implementation with the derived classes implementations. Does presenting the method with polymorphic behavior through an interface, would be a better design choice? -In such situation, often using the design pattern template method http://en.wikipedia.org/wiki/Template_method_pattern might help improving the design. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1204:OverridesOfMethodShouldCallBaseMethod", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- No method matched -
| Validated Rule: Do not hide base class methods |
• Rule Description:
-Method hiding is when a base class has a non-virtual method M(), and a derived class has also a method M() with the same signature. In such situation, calling base.M() does something different than calling derived.M().
-Notice that this is not polymorphic behavior. With polymorphic behavior, calling both base.M() and derived.M() on an instance object of derived, invoke the same implementation.
-This situation should be avoided because it obviously leads to confusion. This rule warns about all method hiding cases in the code base.
-
-
- • How to Fix Issues of this Rule: -To fix a violation of this rule, remove or rename the method, or change the parameter signature so that the method does not hide the base method. -However method hiding is for those times when you need to have two things to have the same name but different behavior. This is a very rare situations, described here: http://blogs.msdn.com/b/ericlippert/archive/2008/05/21/method-hiding-apologia.aspx - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1205:DoNotHideBaseClassMethods", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- • How to Fix Issues of this Rule: -To fix a violation of this rule, remove or rename the method, or change the parameter signature so that the method does not hide the base method. -However method hiding is for those times when you need to have two things to have the same name but different behavior. This is a very rare situations, described here: http://blogs.msdn.com/b/ericlippert/archive/2008/05/21/method-hiding-apologia.aspx - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1205:DoNotHideBaseClassMethods", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- No method matched -
| Rule Violated: A stateless class or structure might be turned into a static type |
• Rule Description:
-This rule matches classes and structures that are not static, nor generic, that doesn't have any instance fields, that doesn't implement any interface nor has a base class (different than System.Object).
-Such class or structure is a stateless collection of pure functions, that doesn't act on any this object data. Such collection of pure functions is better hosted in a static class. Doing so simplifies the client code that doesn't have to create an object anymore to invoke the pure functions.
-
-
- • How to Fix Issues of this Rule: -Declare all methods as static and transform the class or structure into a static class. -By default issues of this rule have a Low severity because they reflect more an advice than a problem. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1206:AStatelessClassOrStructureMightBeTurnedIntoAStaticType", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- • How to Fix Issues of this Rule: -Declare all methods as static and transform the class or structure into a static class. -By default issues of this rule have a Low severity because they reflect more an advice than a problem. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1206:AStatelessClassOrStructureMightBeTurnedIntoAStaticType", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
2 types matched -
-
- Formatting: bold means added, underlined means code was changed,
strike-boldmeans removed (since baseline) -
| 2 types | methodsUsingMe | Debt | Severity | Full Name |
|---|---|---|---|---|
| FlagImageData | 1 method | 2min 0s | Low | FlightSystem.Api.Src.Integration .FileSystem.FlagImageData |
| FlightParser | 5 methods | 6min | Low | FlightSystem.Api.Src.Integration.Neo4J .Data.FlightParser |
| Validated Rule: Non-static classes should be instantiated or turned to static |
• Rule Description:
-If the constructors of a class are never called, the class is never instantiated, and should be defined as a static class.
-However this rule doesn't match instantiation through reflection. As a consequence, plug-in root classes, instantiated through reflection via IoC frameworks, can be false positives for this rule.
-This rule doesn't match also classes instantiated by the ASP.NET infrastructure, ASP.NET view model classes and Entity Framework ModelSnapshot, DbContext and Migration classes.
-Notice that by default this rule matches also public class. If you are developing a framework with classes that are intended to be instantiated by your clients, just uncomment the line !t.IsPublic.
-
-
- • How to Fix Issues of this Rule: -First it is important to investigate why the class is never instantiated. If the reason is the class hosts only static methods then the class can be safely declared as static. -Others reasons like, the class is meant to be instantiated via reflection, or is meant to be instantiated only by client code should lead to adapt this rule code to avoid these matches. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1207:NonStaticClassesShouldBeInstantiatedOrTurnedToStatic", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- • How to Fix Issues of this Rule: -First it is important to investigate why the class is never instantiated. If the reason is the class hosts only static methods then the class can be safely declared as static. -Others reasons like, the class is meant to be instantiated via reflection, or is meant to be instantiated only by client code should lead to adapt this rule code to avoid these matches. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1207:NonStaticClassesShouldBeInstantiatedOrTurnedToStatic", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- No type matched -
| Rule Violated: Methods should be declared static if possible |
• Rule Description:
-When an instance method can be safely declared as static you should declare it as static.
-Whenever you write a method, you fulfill a contract in a given scope. The narrower the scope is, the smaller the chance is that you write a bug.
-When a method is static, you can't access non-static members; hence, your scope is narrower. So, if you don't need and will never need (even in subclasses) instance fields to fulfill your contract, why give access to these fields to your method? Declaring the method static in this case will let the compiler check that you don't use members that you do not intend to use.
-Declaring a method as static if possible is also good practice because clients can tell from the method signature that calling the method can't alter the object's state.
-Doing so, is also a micro performance optimization, since a static method is a bit cheaper to invoke than an instance method, because the this reference* doesn't need anymore to be passed.
-Notice that if a matched method is a handler, bound to an event through code generated by a designer, declaring it as static might break the designer generated code, if the generated code use the this invocation syntax, (like this.Method()).
-
-
- • How to Fix Issues of this Rule: -Declare matched methods as static. -Since such method doesn't use any instance fields and methods of its type and base-types, you should consider if it makes sense, to move such a method to a static utility class. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1208:MethodsShouldBeDeclaredStaticIfPossible", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- • How to Fix Issues of this Rule: -Declare matched methods as static. -Since such method doesn't use any instance fields and methods of its type and base-types, you should consider if it makes sense, to move such a method to a static utility class. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1208:MethodsShouldBeDeclaredStaticIfPossible", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
6 methods matched -
-
- Formatting: bold means added, underlined means code was changed,
strike-boldmeans removed (since baseline) -
| 6 methods | staticFieldsUsed | methodsCallingMe | Debt | Severity | Full Name |
|---|---|---|---|---|---|
| GetFlagImageString(String) | no field | 1 method | 1min 0s | Medium | FlightSystem.Api.Src.Integration .FileSystem.FlagImageData .GetFlagImageString(String) |
| GetAirportFromResult(INode) | no field | 1 method | 1min 0s | Medium | FlightSystem.Api.Src.Integration.Neo4J .Data.AirportData.GetAirportFromResult (INode) |
| GetCountryFromResult(INode) | no field | 1 method | 1min 0s | Medium | FlightSystem.Api.Src.Integration.Neo4J .Data.CountryData.GetCountryFromResult (INode) |
| GetFlight(String,INode,String,String ,String,String,INode,INode) | no field | 3 methods | 2min 0s | Medium | FlightSystem.Api.Src.Integration.Neo4J .Data.FlightParser.GetFlight(String ,INode,String,String,String,String,INode ,INode) |
| AddRouteInfo(List<Route>) | no field | 3 methods | 2min 0s | Medium | FlightSystem.Api.Src.Application .JourneyInfo.RouteManager.AddRouteInfo (List<Route>) |
| SortAndCutRoutes(List<Route>) | no field | 1 method | 1min 0s | Medium | FlightSystem.Api.Src.Application .JourneyInfo.RouteManager .SortAndCutRoutes(List<Route>) |
| Validated Rule: Constructor should not call a virtual method |
• Rule Description:
-This rule matches constructors of a non-sealed class that call one or several virtual methods.
-When an object written in C# is constructed, what happens is that constructors run in order from the base class to the most derived class.
-Also objects do not change type as they are constructed, but start out as the most derived type, with the method table being for the most derived type. This means that virtual method calls always run on the most derived type, even when calls are made from the constructor.
-When you combine these two facts you are left with the problem that if you make a virtual method call in a constructor, and it is not the most derived type in its inheritance hierarchy, then it will be called on a class whose constructor has not been run, and therefore may not be in a suitable state to have that method called.
-Hence this situation makes the class fragile to derive from.
-
-
- • How to Fix Issues of this Rule: -Violations reported can be solved by re-designing object initialisation or by declaring the parent class as sealed, if possible. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1209:ConstructorShouldNotCallAVirtualMethod", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- • How to Fix Issues of this Rule: -Violations reported can be solved by re-designing object initialisation or by declaring the parent class as sealed, if possible. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1209:ConstructorShouldNotCallAVirtualMethod", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- No method matched -
| Validated Rule: Avoid the Singleton pattern |
• Rule Description:
-The singleton pattern consists in enforcing that a class has just a single instance: http://en.wikipedia.org/wiki/Singleton_pattern At first glance, this pattern looks appealing, it is simple to implement, it adresses a common situation, and as a consequence it is widely used.
-However, we discourage you from using singleton classes because experience shows that singleton often results in less testable and less maintainable code. Singleton is by-design, not testable. Each unit test should use their own objects while singleton forces multiple unit-tests to use the same instance object.
-Also the singleton static GetInstance() method allows magic access to that single object and its state from wherever developers want! This potentially attractive facility unfortunatly ends up into unorganized/messy code that will require effort to be refactored.
-Notice that this rule matches only singleton types with mutable instance fields because singleton pitfalls result from anarchical access and modification of instance data.
-More details available in these discussions: http://codebetter.com/patricksmacchia/2011/05/04/back-to-basics-usage-of-static-members/ http://adamschepis.com/blog/2011/05/02/im-adam-and-im-a-recovering-singleton-addict/
-
-
- • How to Fix Issues of this Rule: -This rule matches the classic syntax of singletons, where one static field hold the single instance of the parent class. We underline that the problem is this particular syntax, that plays against testability. The problem is not the fact that a single instance of the class lives at runtime. -Hence to fix matches fo this rule, creates the single instance at the startup of the program, and pass it to all classes and methods that need to access it. -If multiple singletons are identified, they actually form together a program execution context. Such context can be unified in a unique singleton context. Doing so will make it easier to propagate the context across the various program units. -The estimated Debt, which means the effort to fix such issue, is equal to 3 minutes per method relying on the singleton. It is not rare that hundreds of methods rely on the singleton and that it takes hours to get rid of a singleton, refactoring the way just explained above. -The severity of each singleton issue is Critical because as explained, using a the singleton pattern can really prevent the whole program to be testable. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1210:AvoidTheSingletonPattern", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- • How to Fix Issues of this Rule: -This rule matches the classic syntax of singletons, where one static field hold the single instance of the parent class. We underline that the problem is this particular syntax, that plays against testability. The problem is not the fact that a single instance of the class lives at runtime. -Hence to fix matches fo this rule, creates the single instance at the startup of the program, and pass it to all classes and methods that need to access it. -If multiple singletons are identified, they actually form together a program execution context. Such context can be unified in a unique singleton context. Doing so will make it easier to propagate the context across the various program units. -The estimated Debt, which means the effort to fix such issue, is equal to 3 minutes per method relying on the singleton. It is not rare that hundreds of methods rely on the singleton and that it takes hours to get rid of a singleton, refactoring the way just explained above. -The severity of each singleton issue is Critical because as explained, using a the singleton pattern can really prevent the whole program to be testable. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1210:AvoidTheSingletonPattern", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- No type matched -
| Validated Rule: Don't assign static fields from instance methods |
• Rule Description:
-Assigning static fields from instance methods leads to poorly maintainable and non-thread-safe code.
-More discussion on the topic can be found here: http://codebetter.com/patricksmacchia/2011/05/04/back-to-basics-usage-of-static-members/
-
-
- • How to Fix Issues of this Rule: -If the static field is just assigned once in the program lifetime, make sure to declare it as readonly and assign it inline, or from the static constructor. -In Object-Oriented-Programming the natural artifact to hold states that can be modified is instance fields. -Hence to fix violations of this rule, make sure to hold assignable states through instance fields, not through static fields. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1211:DontAssignStaticFieldsFromInstanceMethods", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- • How to Fix Issues of this Rule: -If the static field is just assigned once in the program lifetime, make sure to declare it as readonly and assign it inline, or from the static constructor. -In Object-Oriented-Programming the natural artifact to hold states that can be modified is instance fields. -Hence to fix violations of this rule, make sure to hold assignable states through instance fields, not through static fields. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1211:DontAssignStaticFieldsFromInstanceMethods", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- No field matched -
| Validated Rule: Avoid empty interfaces |
• Rule Description:
-Interfaces define members that provide a behavior or usage contract. The functionality that is described by the interface can be adopted by any type, regardless of where the type appears in the inheritance hierarchy. A type implements an interface by providing implementations for the members of the interface. An empty interface does not define any members. Therefore, it does not define a contract that can be implemented.
-If your design includes empty interfaces that types are expected to implement, you are probably using an interface as a marker or a way to identify a group of types. If this identification will occur at run time, the correct way to accomplish this is to use a custom attribute. Use the presence or absence of the attribute, or the properties of the attribute, to identify the target types. If the identification must occur at compile time, then it is acceptable to use an empty interface.
-Note that if an interface is empty but implements at least one other interface, it won't be matched by this rule. Such interface can be considered as not empty, since implementing it means that sub-interfaces members must be implemented.
-
-
- • How to Fix Issues of this Rule: -Remove the interface or add members to it. If the empty interface is being used to label a set of types, replace the interface with a custom attribute. -The estimated Debt, which means the effort to fix such issue, is equal to 10 minutes to discard an empty interface plus 3 minutes per type implementing an empty interface. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1212:AvoidEmptyInterfaces", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- • How to Fix Issues of this Rule: -Remove the interface or add members to it. If the empty interface is being used to label a set of types, replace the interface with a custom attribute. -The estimated Debt, which means the effort to fix such issue, is equal to 10 minutes to discard an empty interface plus 3 minutes per type implementing an empty interface. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1212:AvoidEmptyInterfaces", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- No type matched -
| Validated Rule: Avoid types initialization cycles |
• Rule Description:
-The class constructor (also called static constructor, and named cctor in IL code) of a type, if any, is executed by the CLR at runtime, the first time the type is used. A cctor doesn't need to be explicitly declared in C# or VB.NET, to exist in compiled IL code. Having a static field inline initialization is enough to have the cctor implicitly declared in the parent class or structure.
-If the cctor of a type t1 is using the type t2 and if the cctor of t2 is using t1, some type initialization unexpected and hard-to-diagnose buggy behavior can occur. Such a cyclic chain of initialization is not necessarily limited to two types and can embrace N types in the general case. More information on types initialization cycles can be found here: http://codeblog.jonskeet.uk/2012/04/07/type-initializer-circular-dependencies/
-The present code rule enumerates types initialization cycles. Some false positives can appear if some lambda expressions are defined in cctors or in methods called by cctors. In such situation, this rule considers these lambda expressions as executed at type initialization time, while it is not necessarily the case.
-
-
- • How to Fix Issues of this Rule: -Types initialization cycles create confusion and unexpected behaviors. If several states hold by several classes must be initialized during the first access of any of those classes, a better design option is to create a dedicated class whose responsibility is to initialize and hold all these states. -The estimated Debt, which means the effort to fix such issue, is equal to 20 minutes per cycle plus 10 minutes per type class constructor involved in the cycle. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1213:AvoidTypesInitializationCycles", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- • How to Fix Issues of this Rule: -Types initialization cycles create confusion and unexpected behaviors. If several states hold by several classes must be initialized during the first access of any of those classes, a better design option is to create a dedicated class whose responsibility is to initialize and hold all these states. -The estimated Debt, which means the effort to fix such issue, is equal to 20 minutes per cycle plus 10 minutes per type class constructor involved in the cycle. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1213:AvoidTypesInitializationCycles", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- No method matched -
API Breaking Changes
| Validated Rule: API Breaking Changes: Types |
• Rule Description:
-This rule is executed only if a baseline for comparison is defined (diff mode).
-This rule warns if a type publicly visible in the baseline, is not publicly visible anymore or if it has been removed. Clients code using such type will be broken.
-
-
- • How to Fix Issues of this Rule: -Make sure that public types that used to be presented to clients, still remain public now, and in the future. -If a public type must really be removed, you can tag it with System.ObsoleteAttribute with a workaround message during a few public releases, until it gets removed definitely. Notice that this rule doesn't match types removed that were tagged as obsolete. -Issues of this rule have a severity equal to High because an API Breaking change can provoque significant friction with consumers of the API. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1500:APIBreakingChangesTypes", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- • How to Fix Issues of this Rule: -Make sure that public types that used to be presented to clients, still remain public now, and in the future. -If a public type must really be removed, you can tag it with System.ObsoleteAttribute with a workaround message during a few public releases, until it gets removed definitely. Notice that this rule doesn't match types removed that were tagged as obsolete. -Issues of this rule have a severity equal to High because an API Breaking change can provoque significant friction with consumers of the API. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1500:APIBreakingChangesTypes", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- No type matched -
| Validated Rule: API Breaking Changes: Methods |
• Rule Description:
-This rule is executed only if a baseline for comparison is defined (diff mode).
-This rule warns if a method publicly visible in the baseline, is not publicly visible anymore or if it has been removed. Clients code using such method will be broken.
-
-
- • How to Fix Issues of this Rule: -Make sure that public methods that used to be presented to clients, still remain public now, and in the future. -If a public method must really be removed, you can tag it with System.ObsoleteAttribute with a workaround message during a few public releases, until it gets removed definitely. Notice that this rule doesn't match methods removed that were tagged as obsolete. -Issues of this rule have a severity equal to High because an API Breaking change can provoque significant friction with consumers of the API. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1501:APIBreakingChangesMethods", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- • How to Fix Issues of this Rule: -Make sure that public methods that used to be presented to clients, still remain public now, and in the future. -If a public method must really be removed, you can tag it with System.ObsoleteAttribute with a workaround message during a few public releases, until it gets removed definitely. Notice that this rule doesn't match methods removed that were tagged as obsolete. -Issues of this rule have a severity equal to High because an API Breaking change can provoque significant friction with consumers of the API. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1501:APIBreakingChangesMethods", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- No method matched -
| Validated Rule: API Breaking Changes: Fields |
• Rule Description:
-This rule is executed only if a baseline for comparison is defined (diff mode).
-This rule warns if a field publicly visible in the baseline, is not publicly visible anymore or if it has been removed. Clients code using such field will be broken.
-
-
- • How to Fix Issues of this Rule: -Make sure that public fields that used to be presented to clients, still remain public now, and in the future. -If a public field must really be removed, you can tag it with System.ObsoleteAttribute with a workaround message during a few public releases, until it gets removed definitely. Notice that this rule doesn't match fields removed that were tagged as obsolete. -Issues of this rule have a severity equal to High because an API Breaking change can provoque significant friction with consumers of the API. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1502:APIBreakingChangesFields", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- • How to Fix Issues of this Rule: -Make sure that public fields that used to be presented to clients, still remain public now, and in the future. -If a public field must really be removed, you can tag it with System.ObsoleteAttribute with a workaround message during a few public releases, until it gets removed definitely. Notice that this rule doesn't match fields removed that were tagged as obsolete. -Issues of this rule have a severity equal to High because an API Breaking change can provoque significant friction with consumers of the API. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1502:APIBreakingChangesFields", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- No field matched -
| Validated Rule: API Breaking Changes: Interfaces and Abstract Classes |
• Rule Description:
-This rule is executed only if a baseline for comparison is defined (diff mode).
-This rule warns if a publicly visible interface or abstract class has been changed and contains new abstract methods or if some abstract methods have been removed.
-Clients code that implement such interface or derive from such abstract class will be broken.
-
-
- • How to Fix Issues of this Rule: -Make sure that the public contracts of interfaces and abstract classes that used to be presented to clients, remain stable now, and in the future. -If a public contract must really be changed, you can tag abstract methods that will be removed with System.ObsoleteAttribute with a workaround message during a few public releases, until it gets removed definitely. -Issues of this rule have a severity equal to High because an API Breaking change can provoque significant friction with consummers of the API. The severity is not set to Critical because an interface is not necessarily meant to be implemented by the consummer of the API. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1503:APIBreakingChangesInterfacesAndAbstractClasses", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- • How to Fix Issues of this Rule: -Make sure that the public contracts of interfaces and abstract classes that used to be presented to clients, remain stable now, and in the future. -If a public contract must really be changed, you can tag abstract methods that will be removed with System.ObsoleteAttribute with a workaround message during a few public releases, until it gets removed definitely. -Issues of this rule have a severity equal to High because an API Breaking change can provoque significant friction with consummers of the API. The severity is not set to Critical because an interface is not necessarily meant to be implemented by the consummer of the API. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1503:APIBreakingChangesInterfacesAndAbstractClasses", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- No type matched -
| Validated Rule: Broken serializable types |
• Rule Description:
-This rule is executed only if a baseline for comparison is defined (diff mode).
-This rule warns about breaking changes in types tagged with SerializableAttribute.
-To do so, this rule searches for serializable type with serializable instance fields added or removed. Notice that it doesn't take account of fields tagged with NonSerializedAttribute.
-From http://msdn.microsoft.com/library/system.serializableattribute.aspx : "All the public and private fields in a type that are marked by the SerializableAttribute are serialized by default, unless the type implements the ISerializable interface to override the serialization process. The default serialization process excludes fields that are marked with the NonSerializedAttribute attribute."
-
-
- • How to Fix Issues of this Rule: -Make sure that the serialization process of serializable types remains stable now, and in the future. -Else you'll have to deal with Version Tolerant Serialization that is explained here: https://msdn.microsoft.com/en-us/library/ms229752(v=vs.110).aspx -Issues of this rule have a severity equal to High because an API Breaking change can provoque significant friction with consummers of the API. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1504:BrokenSerializableTypes", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- • How to Fix Issues of this Rule: -Make sure that the serialization process of serializable types remains stable now, and in the future. -Else you'll have to deal with Version Tolerant Serialization that is explained here: https://msdn.microsoft.com/en-us/library/ms229752(v=vs.110).aspx -Issues of this rule have a severity equal to High because an API Breaking change can provoque significant friction with consummers of the API. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1504:BrokenSerializableTypes", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- No type matched -
| Validated Rule: Avoid changing enumerations Flags status |
• Rule Description:
-This rule is executed only if a baseline for comparison is defined (diff mode).
-This rule matches enumeration types that used to be tagged with FlagsAttribute in the baseline, and not anymore. It also matches the opposite, enumeration types that are now tagged with FlagsAttribute, and were not tagged in the baseline.
-Being tagged with FlagsAttribute is a strong property for an enumeration. Not so much in terms of behavior (only the enum.ToString() method behavior changes when an enumeration is tagged with FlagsAttribute) but in terms of meaning: is the enumeration a range of values or a range of flags?
-As a consequence, changing the FlagsAttributes status of an enumeration can have significant impact for its clients.
-
-
- • How to Fix Issues of this Rule: -Make sure the FlagsAttribute status of each enumeration remains stable now, and in the future. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1505:AvoidChangingEnumerationsFlagsStatus", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- • How to Fix Issues of this Rule: -Make sure the FlagsAttribute status of each enumeration remains stable now, and in the future. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1505:AvoidChangingEnumerationsFlagsStatus", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- No type matched -
Code Coverage
|
| Validated Rule: Code should be tested |
• Rule Description:
-This rule lists methods not covered at all by test or partially covered by tests.
-For each match, the rules estimates the technical debt, i.e the effort to write unit and integration tests for the method. The estimation is based on the effort to develop the code element multiplied by factors in the range ]0,1.3] based on
-• the method code size and complexity
-• the actual percentage coverage
-• the abstractness of types used, because relying on classes instead of interfaces makes the code more difficult to test
-• the method visibility because testing private or protected methods is more difficult than testing public and internal ones
-• the fields used by the method, because is is more complicated to write tests for methods that read mutable static fields whose changing state is shared across tests executions.
-• whether the method is considered JustMyCode or not because NotMyCode is often generated easier to get tested since tests can be generated as well.
-This rule is necessarily a large source of technical debt, since the code left untested is by definition part of the technical debt.
-This rule also estimates the annual interest, i.e the annual cost to let the code uncovered, based on the effort to develop the code element, multiplied by factors based on usage of the code element.
-
-
- • How to Fix Issues of this Rule: -Write unit tests to test and cover the methods and their parent classes matched by this rule. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1600:CodeShouldBeTested", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- • How to Fix Issues of this Rule: -Write unit tests to test and cover the methods and their parent classes matched by this rule. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1600:CodeShouldBeTested", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- No method matched -
| Validated Rule: New Methods should be tested |
• Rule Description:
-This rule is executed only if a baseline for comparison is defined (diff mode). This rule operates only on methods added or refactored since the baseline.
-This rule is executed only if some code coverage data is imported from some code coverage files.
-It is important to write code mostly covered by tests to achieve maintainable and non-error-prone code.
-In real-world, many code bases are poorly covered by tests. However it is not practicable to stop the development for months to refactor and write tests to achieve high code coverage ratio.
-Hence it is recommended that each time a method (or a type) gets added, the developer takes the time to write associated unit-tests to cover it.
-Doing so will help to increase significantly the maintainability of the code base. You'll notice that quickly, refactoring will also be driven by testability, and as a consequence, the overall code structure and design will increase as well.
-Issues of this rule have a High severity because they reflect an actual trend to not care about writing tests on refactored code.
-
-
- • How to Fix Issues of this Rule: -Write unit-tests to cover the code of most methods and classes added. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1601:NewMethodsShouldBeTested", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- • How to Fix Issues of this Rule: -Write unit-tests to cover the code of most methods and classes added. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1601:NewMethodsShouldBeTested", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- No method matched -
| Validated Rule: Methods refactored should be tested |
• Rule Description:
-This rule is executed only if a baseline for comparison is defined (diff mode). This rule operates only on methods added or refactored since the baseline.
-This rule is executed only if some code coverage data is imported from some code coverage files.
-It is important to write code mostly covered by tests to achieve maintainable and non-error-prone code.
-In real-world, many code bases are poorly covered by tests. However it is not practicable to stop the development for months to refactor and write tests to achieve high code coverage ratio.
-Hence it is recommended that each time a method (or a type) gets refactored, the developer takes the time to write associated unit-tests to cover it.
-Doing so will help to increase significantly the maintainability of the code base. You'll notice that quickly, refactoring will also be driven by testability, and as a consequence, the overall code structure and design will increase as well.
-Issues of this rule have a High severity because they reflect an actual trend to not care about writing tests on refactored code.
-
-
- • How to Fix Issues of this Rule: -Write unit-tests to cover the code of most methods and classes refactored. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1602:MethodsRefactoredShouldBeTested", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- • How to Fix Issues of this Rule: -Write unit-tests to cover the code of most methods and classes refactored. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1602:MethodsRefactoredShouldBeTested", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- No method matched -
| Validated Rule: Assemblies Namespaces and Types should be tested |
• Rule Description:
-This rule lists assemblies, namespaces and types that are not covered at all by unit tests.
-If a parent is matched its children are not matched. For example if a namespace is matched, its child types are not matched.
-This rule goal is not to collide with the Code should be tested rule that lists uncovered code for each method and infer the effort to write unit tests (the Debt) and the annual cost to let the code untested (the Annual Interest).
-This rule goal is to inform of large code elements left untested. As a consequence the Debt per issue is only 4 minutes and the severity of the issues is Low.
-
-
- • How to Fix Issues of this Rule: -Write unit and integration tests to cover, even partially, code elements matched by this rule. -Then use issues of the rules Code should be tested, New Methods should be tested and Methods refactored should be tested to write more tests where it matters most, and eventually refactor some code to make it more testable. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1603:AssembliesNamespacesAndTypesShouldBeTested", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- • How to Fix Issues of this Rule: -Write unit and integration tests to cover, even partially, code elements matched by this rule. -Then use issues of the rules Code should be tested, New Methods should be tested and Methods refactored should be tested to write more tests where it matters most, and eventually refactor some code to make it more testable. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1603:AssembliesNamespacesAndTypesShouldBeTested", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- No code element parent matched -
| Validated Rule: Types almost 100% tested should be 100% tested |
• Rule Description:
-This rule is executed only if some code coverage data is imported from some code coverage files.
-Often covering the few percents of remaining uncovered code of a class, requires as much work as covering the first 90%. For this reason, often teams estimate that 90% coverage is enough. However untestable code usually means poorly written code which usually leads to error prone code. So it might be worth refactoring and making sure to cover the few uncovered lines of code because most tricky bugs might come from this small portion of hard-to-test code.
-Not all classes should be 100% covered by tests (like UI code can be hard to test) but you should make sure that most of the logic of your application is defined in some easy-to-test classes, 100% covered by tests.
-Issues of this rule have a High severity because as explained, such situation is bug-prone.
-
-
- • How to Fix Issues of this Rule: -Write more unit-tests dedicated to cover code not covered yet. If you find some hard-to-test code, it is certainly a sign that this code is not well designed and hence, needs refactoring. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1604:TypesAlmost100PercentTestedShouldBe100PercentTested", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- • How to Fix Issues of this Rule: -Write more unit-tests dedicated to cover code not covered yet. If you find some hard-to-test code, it is certainly a sign that this code is not well designed and hence, needs refactoring. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1604:TypesAlmost100PercentTestedShouldBe100PercentTested", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- No type matched -
| Validated Rule: Namespaces almost 100% tested should be 100% tested |
• Rule Description:
-This rule is executed only if some code coverage data is imported from some code coverage files.
-Often covering the few percents of remaining uncovered code of one or several classes in a namespace requires as much work as covering the first 90%. For this reason, often teams estimate that 90% coverage is enough. However untestable code usually means poorly written code which usually leads to error prone code. So it might be worth refactoring and making sure to cover the few uncovered lines of code because most tricky bugs might come from this small portion of hard-to-test code.
-Not all classes should be 100% covered by tests (like UI code can be hard to test) but you should make sure that most of the logic of your application is defined in some easy-to-test classes, 100% covered by tests.
-Issues of this rule have a High severity because as explained, such situation is bug-prone.
-
-
- • How to Fix Issues of this Rule: -Write more unit-tests dedicated to cover code not covered yet in the namespace. If you find some hard-to-test code, it is certainly a sign that this code is not well designed and hence, needs refactoring. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1605:NamespacesAlmost100PercentTestedShouldBe100PercentTested", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- • How to Fix Issues of this Rule: -Write more unit-tests dedicated to cover code not covered yet in the namespace. If you find some hard-to-test code, it is certainly a sign that this code is not well designed and hence, needs refactoring. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1605:NamespacesAlmost100PercentTestedShouldBe100PercentTested", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- No namespace matched -
| Validated Rule: Types that used to be 100% covered by tests should still be 100% covered |
• Rule Description:
-This rule is executed only if a baseline for comparison is defined (diff mode).
-This rule is executed only if some code coverage data is imported from some code coverage files.
-Often covering 10% of remaining uncovered code of a class, requires as much work as covering the first 90%. For this reason, typically teams estimate that 90% coverage is enough. However untestable code usually means poorly written code which usually leads to error prone code. So it might be worth refactoring and making sure to cover the 10% remaining code because most tricky bugs might come from this small portion of hard-to-test code.
-Not all classes should be 100% covered by tests (like UI code can be hard to test) but you should make sure that most of the logic of your application is defined in some easy-to-test classes, 100% covered by tests.
-In this context, this rule warns when a type fully covered by tests is now only partially covered.
-Issues of this rule have a High severity because often, a type that used to be 100% and is not covered anymore is a bug-prone situation that should be carefully handled.
-
-
- • How to Fix Issues of this Rule: -Write more unit-tests dedicated to cover code not covered anymore. If you find some hard-to-test code, it is certainly a sign that this code is not well designed and hence, needs refactoring. -You'll find code impossible to cover by unit-tests, like calls to MessageBox.Show(). An infrastructure must be defined to be able to mock such code at test-time. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1606:TypesThatUsedToBe100PercentCoveredByTestsShouldStillBe100PercentCovered", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- • How to Fix Issues of this Rule: -Write more unit-tests dedicated to cover code not covered anymore. If you find some hard-to-test code, it is certainly a sign that this code is not well designed and hence, needs refactoring. -You'll find code impossible to cover by unit-tests, like calls to MessageBox.Show(). An infrastructure must be defined to be able to mock such code at test-time. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1606:TypesThatUsedToBe100PercentCoveredByTestsShouldStillBe100PercentCovered", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- No method matched -
| Validated Rule: Types tagged with FullCoveredAttribute should be 100% covered |
• Rule Description:
-This rule lists methods partially covered by tests, of types tagged with FullCoveredAttribute.
-This rule is executed only if some code coverage data is imported from some code coverage files.
-By using a FullCoveredAttribute, you can express in source code the intention that a class is 100% covered by tests, and should remain 100% covered in the future. If you don't want to link NDepend.API.dll, you can use your own attribute and adapt the source code of this rule.
-Benefits of using a FullCoveredAttribute are twofold: Not only the intention is expressed in source code, but it is also continuously checked by the present rule.
-Often covering 10% of remaining uncovered code of a class, requires as much work as covering the first 90%. For this reason, often teams estimate that 90% coverage is enough. However untestable code usually means poorly written code which usually means error prone code. So it might be worth refactoring and making sure to cover the 10% remaining code because most tricky bugs might come from this small portion of hard-to-test code.
-Not all classes should be 100% covered by tests (like UI code can be hard to test) but you should make sure that most of the logic of your application is defined in some easy-to-test classes, 100% covered by tests.
-Issues of this rule have a High severity because often, a type that used to be 100% and is not covered anymore is a bug-prone situation that should be carefully handled.
-
-
- • How to Fix Issues of this Rule: -Write more unit-tests dedicated to cover code of matched classes not covered yet. If you find some hard-to-test code, it is certainly a sign that this code is not well designed and hence, needs refactoring. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1607:TypesTaggedWithFullCoveredAttributeShouldBe100PercentCovered", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- • How to Fix Issues of this Rule: -Write more unit-tests dedicated to cover code of matched classes not covered yet. If you find some hard-to-test code, it is certainly a sign that this code is not well designed and hence, needs refactoring. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1607:TypesTaggedWithFullCoveredAttributeShouldBe100PercentCovered", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- No method matched -
| Validated Rule: Types 100% covered should be tagged with FullCoveredAttribute |
• Rule Description:
-This rule is executed only if some code coverage data is imported from some code coverage files.
-By using a FullCoveredAttribute, you can express in source code the intention that a class is 100% covered by tests, and should remain 100% covered in the future.
-Benefits of using a FullCoveredAttribute are twofold: Not only the intention is expressed in source code, but it is also continuously checked by the present rule.
-Issues of this rule have an Low severity because they don't reflect a problem, but provide an advice for potential improvement.
-
-
- • How to Fix Issues of this Rule: -Just tag types 100% covered by tests with the FullCoveredAttribute that can be found in NDepend.API.dll, or by an attribute of yours defined in your own code (in which case this rule must be adapted). - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1608:Types100PercentCoveredShouldBeTaggedWithFullCoveredAttribute", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- • How to Fix Issues of this Rule: -Just tag types 100% covered by tests with the FullCoveredAttribute that can be found in NDepend.API.dll, or by an attribute of yours defined in your own code (in which case this rule must be adapted). - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1608:Types100PercentCoveredShouldBeTaggedWithFullCoveredAttribute", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- No type matched -
| Validated Rule: Methods should have a low C.R.A.P score |
• Rule Description:
-This rule is executed only if some code coverage data is imported from some code coverage files.
-So far this rule is disabled because other code coverage rules assess properly code coverage issues.
-Change Risk Analyzer and Predictor (i.e. CRAP) is a code metric that helps in pinpointing overly both complex and untested code. Is has been first defined here: http://www.artima.com/weblogs/viewpost.jsp?thread=215899
-The Formula is: CRAP(m) = CC(m)^2 * (1 – cov(m)/100)^3 + CC(m)
-• where CC(m) is the cyclomatic complexity of the method m
-• and cov(m) is the percentage coverage by tests of the method m
-Matched methods cumulates two highly error prone code smells:
-• A complex method, difficult to develop and maintain.
-• Non 100% covered code, difficult to refactor without introducing any regression bug.
-The higher the CRAP score, the more painful to maintain and error prone is the method.
-An arbitrary threshold of 30 is fixed for this code rule as suggested by inventors.
-Notice that no amount of testing will keep methods with a Cyclomatic Complexity higher than 30, out of CRAP territory.
-Notice that this rule doesn't match too short method with less than 10 lines of code.
-
-
- • How to Fix Issues of this Rule: -In such situation, it is recommended to both refactor the complex method logic into several smaller and less complex methods (that might belong to some new types especially created), and also write unit-tests to full cover the refactored logic. -You'll find code impossible to cover by unit-tests, like calls to MessageBox.Show(). An infrastructure must be defined to be able to mock such code at test-time. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1609:MethodsShouldHaveALowCRAPScore", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- • How to Fix Issues of this Rule: -In such situation, it is recommended to both refactor the complex method logic into several smaller and less complex methods (that might belong to some new types especially created), and also write unit-tests to full cover the refactored logic. -You'll find code impossible to cover by unit-tests, like calls to MessageBox.Show(). An infrastructure must be defined to be able to mock such code at test-time. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1609:MethodsShouldHaveALowCRAPScore", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- No method matched -
Dead Code
| Validated Rule: Potentially Dead Types |
• Rule Description:
-This rule lists potentially dead types. A dead type is a type that can be removed because it is never used by the program.
-This rule lists not only types not used anywhere in code, but also types used only by types not used anywhere in code. This is why this rule comes with a column TypesusingMe and this is why there is a code metric named depth:
-• A depth value of 0 means the type is not used.
-• A depth value of 1 means the type is used only by types not used.
-• etc…
-By reading the source code of this rule, you'll see that by default, public types are not matched, because such type might not be used by the analyzed code, but still be used by client code, not analyzed by NDepend. This default behavior can be easily changed.
-Note that this rule doesn't match Entity Framework ModelSnapshot classes that are used ony by the EF infrastructure.
-
-
- • How to Fix Issues of this Rule: -Static analysis cannot provide an exact list of dead types, because there are several ways to use a type dynamically (like through reflection). -For each type matched by this query, first investigate if the type is used somehow (like through reflection). If the type is really never used, it is important to remove it to avoid maintaining useless code. If you estimate the code of the type might be used in the future, at least comment it, and provide an explanatory comment about the future intentions. -If a type is used somehow, but still is matched by this rule, you can tag it with the attribute IsNotDeadCodeAttribute found in NDepend.API.dll to avoid matching the type again. You can also provide your own attribute for this need, but then you'll need to adapt this code rule. -Issues of this rule have a Debt equal to 15 minutes because it only takes a short while to investigate if a type can be safely discarded. The Annual Interest of issues of this rule, the annual cost to not fix such issue, is proportional to the type #lines of code, because the bigger the type is, the more it slows down maintenance. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1700:PotentiallyDeadTypes", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- • How to Fix Issues of this Rule: -Static analysis cannot provide an exact list of dead types, because there are several ways to use a type dynamically (like through reflection). -For each type matched by this query, first investigate if the type is used somehow (like through reflection). If the type is really never used, it is important to remove it to avoid maintaining useless code. If you estimate the code of the type might be used in the future, at least comment it, and provide an explanatory comment about the future intentions. -If a type is used somehow, but still is matched by this rule, you can tag it with the attribute IsNotDeadCodeAttribute found in NDepend.API.dll to avoid matching the type again. You can also provide your own attribute for this need, but then you'll need to adapt this code rule. -Issues of this rule have a Debt equal to 15 minutes because it only takes a short while to investigate if a type can be safely discarded. The Annual Interest of issues of this rule, the annual cost to not fix such issue, is proportional to the type #lines of code, because the bigger the type is, the more it slows down maintenance. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1700:PotentiallyDeadTypes", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- No type matched -
| Validated Rule: Potentially Dead Methods |
• Rule Description:
-This rule lists potentially dead methods. A dead method is a method that can be removed because it is never called by the program.
-This rule lists not only methods not called anywhere in code, but also methods called only by methods not called anywhere in code. This is why this rule comes with a column MethodsCallingMe and this is why there is a code metric named depth:
-• A depth value of 0 means the method is not called.
-• A depth value of 1 means the method is called only by methods not called.
-• etc…
-By reading the source code of this rule, you'll see that by default, public methods are not matched, because such method might not be called by the analyzed code, but still be called by client code, not analyzed by NDepend. This default behavior can be easily changed.
-
-
- • How to Fix Issues of this Rule: -Static analysis cannot provide an exact list of dead methods, because there are several ways to invoke a method dynamically (like through reflection). -For each method matched by this query, first investigate if the method is invoked somehow (like through reflection). If the method is really never invoked, it is important to remove it to avoid maintaining useless code. If you estimate the code of the method might be used in the future, at least comment it, and provide an explanatory comment about the future intentions. -If a method is invoked somehow, but still is matched by this rule, you can tag it with the attribute IsNotDeadCodeAttribute found in NDepend.API.dll to avoid matching the method again. You can also provide your own attribute for this need, but then you'll need to adapt this code rule. -Issues of this rule have a Debt equal to 10 minutes because it only takes a short while to investigate if a method can be safely discarded. On top of these 10 minutes, the depth of usage of such method adds up 3 minutes per unity because dead method only called by dead code takes a bit more time to be investigated. -The Annual Interest of issues of this rule, the annual cost to not fix such issue, is proportional to the type #lines of code, because the bigger the method is, the more it slows down maintenance. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1701:PotentiallyDeadMethods", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- • How to Fix Issues of this Rule: -Static analysis cannot provide an exact list of dead methods, because there are several ways to invoke a method dynamically (like through reflection). -For each method matched by this query, first investigate if the method is invoked somehow (like through reflection). If the method is really never invoked, it is important to remove it to avoid maintaining useless code. If you estimate the code of the method might be used in the future, at least comment it, and provide an explanatory comment about the future intentions. -If a method is invoked somehow, but still is matched by this rule, you can tag it with the attribute IsNotDeadCodeAttribute found in NDepend.API.dll to avoid matching the method again. You can also provide your own attribute for this need, but then you'll need to adapt this code rule. -Issues of this rule have a Debt equal to 10 minutes because it only takes a short while to investigate if a method can be safely discarded. On top of these 10 minutes, the depth of usage of such method adds up 3 minutes per unity because dead method only called by dead code takes a bit more time to be investigated. -The Annual Interest of issues of this rule, the annual cost to not fix such issue, is proportional to the type #lines of code, because the bigger the method is, the more it slows down maintenance. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1701:PotentiallyDeadMethods", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- No method matched -
| Validated Rule: Potentially Dead Fields |
• Rule Description:
-This rule lists potentially dead fields. A dead field is a field that can be removed because it is never used by the program.
-By reading the source code of this rule, you'll see that by default, public fields are not matched, because such field might not be used by the analyzed code, but still be used by client code, not analyzed by NDepend. This default behavior can be easily changed. Some others default rules in the Visibility group, warn about public fields.
-More restrictions are applied by this rule because of some by-design limitations. NDepend mostly analyzes compiled IL code, and the information that an enumeration value or a literal constant (which are fields) is used is lost in IL code. Hence by default this rule won't match such field.
-
-
- • How to Fix Issues of this Rule: -Static analysis cannot provide an exact list of dead fields, because there are several ways to assign or read a field dynamically (like through reflection). -For each field matched by this query, first investigate if the field is used somehow (like through reflection). If the field is really never used, it is important to remove it to avoid maintaining a useless code element. -If a field is used somehow, but still is matched by this rule, you can tag it with the attribute IsNotDeadCodeAttribute found in NDepend.API.dll to avoid matching the field again. You can also provide your own attribute for this need, but then you'll need to adapt this code rule. -Issues of this rule have a Debt equal to 10 minutes because it only takes a short while to investigate if a method can be safely discarded. The Annual Interest of issues of this rule, the annual cost to not fix such issue, is set by default to 8 minutes per unused field matched. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1702:PotentiallyDeadFields", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- • How to Fix Issues of this Rule: -Static analysis cannot provide an exact list of dead fields, because there are several ways to assign or read a field dynamically (like through reflection). -For each field matched by this query, first investigate if the field is used somehow (like through reflection). If the field is really never used, it is important to remove it to avoid maintaining a useless code element. -If a field is used somehow, but still is matched by this rule, you can tag it with the attribute IsNotDeadCodeAttribute found in NDepend.API.dll to avoid matching the field again. You can also provide your own attribute for this need, but then you'll need to adapt this code rule. -Issues of this rule have a Debt equal to 10 minutes because it only takes a short while to investigate if a method can be safely discarded. The Annual Interest of issues of this rule, the annual cost to not fix such issue, is set by default to 8 minutes per unused field matched. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1702:PotentiallyDeadFields", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- No field matched -
| Validated Rule: Wrong usage of IsNotDeadCodeAttribute |
• Rule Description:
-The attribute NDepend.Attributes.IsNotDeadCodeAttribute is defined in NDepend.API.dll. This attribute is used to mean that a code element is not used directly, but is used somehow, like through reflection.
-This attribute is used in the dead code rules, Potentially dead Types, Potentially dead Methods and Potentially dead Fields. If you don't want to link NDepend.API.dll, you can use your own IsNotDeadCodeAttribute and adapt the source code of this rule, and the source code of the dead code rules.
-In this context, this code rule matches code elements (types, methods, fields) that are tagged with this attribute, but still used directly somewhere in the code.
-
-
- • How to Fix Issues of this Rule: -Just remove IsNotDeadCodeAttribute tagging of types, methods and fields matched by this rule because this tag is not useful anymore. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1703:WrongUsageOfIsNotDeadCodeAttribute", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- • How to Fix Issues of this Rule: -Just remove IsNotDeadCodeAttribute tagging of types, methods and fields matched by this rule because this tag is not useful anymore. - -
- • How to Suppress an Issue of this Rule: -In source code, tag the concerned code element with this attribute: -[SuppressMessage("NDepend", "ND1703:WrongUsageOfIsNotDeadCodeAttribute", Justification="...")] -This attribute requires the compilation symbol CODE_ANALYSIS to be set on each Visual Studio project relying on it. Without CODE_ANALYSIS symbol defined, the attribute is not compiled and the issues are not suppressed.
- No member matched -
Code Diff Summary
|
- » Baseline for comparison : Baseline is same code base snapshot. |
|
| Code Query: New assemblies |
• Query Description:
-This query is executed only if a baseline for comparison is defined (diff mode).
-This code query lists assemblies that have been added since the baseline.
- No assembly matched -
| Code Query: Assemblies removed |
• Query Description:
-This query is executed only if a baseline for comparison is defined (diff mode).
-This code query lists assemblies that have been removed since the baseline.
- No assembly matched -
| Code Query: Assemblies where code was changed |
• Query Description:
-This query is executed only if a baseline for comparison is defined (diff mode).
-This code query lists assemblies in which, code has been changed since the baseline.
- No assembly matched -
| Code Query: New namespaces |
• Query Description:
-This query is executed only if a baseline for comparison is defined (diff mode).
-This code query lists namespaces that have been added since the baseline.
- No namespace matched -
| Code Query: Namespaces removed |
• Query Description:
-This query is executed only if a baseline for comparison is defined (diff mode).
-This code query lists namespaces that have been removed since the baseline.
- No namespace matched -
| Code Query: Namespaces where code was changed |
• Query Description:
-This query is executed only if a baseline for comparison is defined (diff mode).
-This code query lists namespaces in which, code has been changed since the baseline.
- No namespace matched -
| Code Query: New types |
• Query Description:
-This query is executed only if a baseline for comparison is defined (diff mode).
-This code query lists types that have been added since the baseline.
- No type matched -
| Code Query: Types removed |
• Query Description:
-This query is executed only if a baseline for comparison is defined (diff mode).
-This code query lists types that have been removed since the baseline.
- No type matched -
| Code Query: Types where code was changed |
• Query Description:
-This query is executed only if a baseline for comparison is defined (diff mode).
-This code query lists types in which, code has been changed since the baseline.
-To visualize changes in code, right-click a matched type and select:
-• Compare older and newer versions of source file
-• Compare older and newer versions disassembled with Reflector
- No type matched -
| Code Query: Heuristic to find types moved from one namespace or assembly to another |
• Query Description:
-This query is executed only if a baseline for comparison is defined (diff mode).
-This code query lists types moved from one namespace or assembly to another. The heuristic implemented consists in making a join LINQ query on type name (without namespace prefix), applied to the two sets of types added and types removed.
- No type matched -
| Code Query: Types directly using one or several types changed |
• Query Description:
-This query is executed only if a baseline for comparison is defined (diff mode).
-This code query lists types unchanged since the baseline but that use directly some types where code has been changed since the baseline.
-For such matched type, the code hasen't been changed, but still the overall behavior might have been changed.
-The query result includes types changed directly used,
- No type matched -
| Code Query: Types indirectly using one or several types changed |
• Query Description:
-This query is executed only if a baseline for comparison is defined (diff mode).
-This code query lists types unchanged since the baseline but that use directly or indirectly some types where code has been changed since the baseline.
-For such matched type, the code hasen't been changed, but still the overall behavior might have been changed.
-The query result includes types changed directly used, and the depth of usage of types indirectly used, depth of usage as defined in the documentation of DepthOfIsUsingAny() NDepend API method: https://www.ndepend.com/api/webframe.html?NDepend.API~NDepend.CodeModel.ExtensionMethodsSequenceUsage~DepthOfIsUsingAny.html
- No type matched -
| Code Query: New methods |
• Query Description:
-This query is executed only if a baseline for comparison is defined (diff mode).
-This code query lists methods that have been added since the baseline.
- No method matched -
| Code Query: Methods removed |
• Query Description:
-This query is executed only if a baseline for comparison is defined (diff mode).
-This code query lists methods that have been removed since the baseline.
- No method matched -
| Code Query: Methods where code was changed |
• Query Description:
-This query is executed only if a baseline for comparison is defined (diff mode).
-This code query lists methods in which, code has been changed since the baseline.
-To visualize changes in code, right-click a matched method and select:
-• Compare older and newer versions of source file
-• Compare older and newer versions disassembled with Reflector
- No method matched -
| Code Query: Methods directly calling one or several methods changed |
• Query Description:
-This query is executed only if a baseline for comparison is defined (diff mode).
-This code query lists methods unchanged since the baseline but that call directly some methods where code has been changed since the baseline.
-For such matched method, the code hasen't been changed, but still the overall behavior might have been changed.
-The query result includes methods changed directly used,
- No method matched -
| Code Query: Methods indirectly calling one or several methods changed |
• Query Description:
-This query is executed only if a baseline for comparison is defined (diff mode).
-This code query lists methods unchanged since the baseline but that use directly or indirectly some methods where code has been changed since the baseline.
-For such matched method, the code hasen't been changed, but still the overall behavior might have been changed.
-The query result includes methods changed directly used, and the depth of usage of methods indirectly used, depth of usage as defined in the documentation of DepthOfIsUsingAny() NDepend API method: https://www.ndepend.com/api/webframe.html?NDepend.API~NDepend.CodeModel.ExtensionMethodsSequenceUsage~DepthOfIsUsingAny.html
- No method matched -
| Code Query: New fields |
• Query Description:
-This query is executed only if a baseline for comparison is defined (diff mode).
-This code query lists fields that have been added since the baseline.
- No field matched -
| Code Query: Fields removed |
• Query Description:
-This query is executed only if a baseline for comparison is defined (diff mode).
-This code query lists fields that have been removed since the baseline.
- No field matched -
| Code Query: Third party types that were not used and that are now used |
• Query Description:
-This query is executed only if a baseline for comparison is defined (diff mode).
-This code query lists types defined in third-party assemblies, that were not used at baseline time, and that are now used.
- No type matched -
| Code Query: Third party types that were used and that are not used anymore |
• Query Description:
-This query is executed only if a baseline for comparison is defined (diff mode).
-This code query lists types defined in third-party assemblies, that were used at baseline time, and that are not used anymore.
- No type matched -
| Code Query: Third party methods that were not used and that are now used |
• Query Description:
-This query is executed only if a baseline for comparison is defined (diff mode).
-This code query lists methods defined in third-party assemblies, that were not used at baseline time, and that are now used.
- No method matched -
| Code Query: Third party methods that were used and that are not used anymore |
• Query Description:
-This query is executed only if a baseline for comparison is defined (diff mode).
-This code query lists methods defined in third-party assemblies, that were used at baseline time, and that are not used anymore.
- No method matched -
| Code Query: Third party fields that were not used and that are now used |
• Query Description:
-This query is executed only if a baseline for comparison is defined (diff mode).
-This code query lists fields defined in third-party assemblies, that were not used at baseline time, and that are now used.
- No field matched -
| Code Query: Third party fields that were used and that are not used anymore |
• Query Description:
-This query is executed only if a baseline for comparison is defined (diff mode).
-This code query lists fields defined in third-party assemblies, that were used at baseline time, and that are not used anymore.
- No field matched -
Trend Charts
- --
-
-Size
--
-
-% Coverage and % Debt
--
-
-Issues
--
-
-Rules
--
-
-Quality Gates
--
-
-
-
-
-
-
-
-
-
-Debt
-Assemblies Dependencies
| - Assembly - | - Depends on - | - Is referenced by - |
|---|---|---|
| FlightSystem.Api v1.0.0.0 | System.Runtime v4.2.1.0 ; - mscorlib v4.0.0.0 ; - Microsoft.Extensions.Hosting .Abstractions v3.0.0.0 ; - Microsoft.Extensions.DependencyInjection .Abstractions v3.0.0.0 ; - System.ComponentModel v4.0.3.0 ; - Neo4j.Driver v1.7.226.2 ; - Microsoft.Extensions.Hosting v3.0.0.0 ; - Microsoft.AspNetCore.Hosting .Abstractions v2.1.1.0 ; - Microsoft.AspNetCore.Hosting v2.1.1.0 ; - Microsoft.Extensions.Configuration .Abstractions v3.0.0.0 ; - Microsoft.AspNetCore.Mvc.Core v2.1.1.0 ; - Microsoft.AspNetCore.Mvc v2.1.1.0 ; - Microsoft.AspNetCore.Http.Abstractions v2.1.1.0 ; - Microsoft.AspNetCore.Diagnostics v2.1.1.0 ; - Microsoft.AspNetCore.HttpsPolicy v2.1.1.0 ; - System.Diagnostics.Debug v4.1.1.0 ; - Newtonsoft.Json v12.0.0.0 ; - System.Collections v4.1.1.0 ; - System.Drawing.Common v4.0.2.0 ; - System.Console v4.1.1.0 ; - Microsoft.Extensions.Logging .Abstractions v3.0.0.0 ; - System.Runtime.Extensions v4.2.1.0 ; - System.Linq v4.2.1.0 ; - System.IO.FileSystem v4.1.1.0 ; - | - |
Assemblies Build Order
- FlightSystem.Api
Assemblies Build Order
- FlightSystem.Api
Analysis Log : Information and Warnings
- Here are Logs emitted during NDepend analysis.
- The Warnings can reveal potential flaws concerning the health of the build process.
- A particular warn can be disabled through the NDepend interactive UI, panel Error List, tick the checkbox Disabled corresponding to the warn to disable. -
- The Warnings can reveal potential flaws concerning the health of the build process.
- A particular warn can be disabled through the NDepend interactive UI, panel Error List, tick the checkbox Disabled corresponding to the warn to disable. -
| - Message - | |
|---|---|
 | Begin full analysis with NDepend v2019.3.0 |
| Visual Studio solution file resolved to absolute file path: from {.\FlightSystem2.sln} to {C:\Users\Paulius\source\repos\FlightSystem2\FlightSystem2.sln} |
| Output directory resolved to absolute directory path: C:\Users\Paulius\source\repos\FlightSystem2\NDependOut |
| .NET Assembly resolved from the Visual Studio solution file {C:\Users\Paulius\source\repos\FlightSystem2\FlightSystem2.sln} - C:\Users\Paulius\source\repos\FlightSystem2\FlightSystem2\bin\debug\netcoreapp3.0\FlightSystem.Api.dll |
| No .NET Assembly filtered out from the Visual Studio solution file {C:\Users\Paulius\source\repos\FlightSystem2\FlightSystem2.sln}. |
| Concurrent mode |
| .NET Assemblies loaded from {C:\Program Files\dotnet\shared\Microsoft.NETCore.App\3.0.0} - mscorlib.dll v4.0.0.0 - System.IO.FileSystem.dll v4.1.1.0 - System.Linq.dll v4.2.1.0 - System.Console.dll v4.1.1.0 - System.Runtime.Extensions.dll v4.2.1.0 - System.Collections.dll v4.1.1.0 - System.Diagnostics.Debug.dll v4.1.1.0 - System.ComponentModel.dll v4.0.3.0 - System.Runtime.dll v4.2.1.0 |
| .NET Assemblies loaded from {C:\Program Files\dotnet\sdk\NuGetFallbackFolder} - .\Microsoft.AspNetCore.Hosting\2.1.1\lib\netstandard2.0\Microsoft.AspNetCore.Hosting.dll v2.1.1.0 - .\Microsoft.AspNetCore.Authorization.Policy\2.1.1\lib\netstandard2.0\Microsoft.AspNetCore.Authorization.Policy.dll v2.1.1.0 - .\Microsoft.AspNetCore.HttpsPolicy\2.1.1\lib\netstandard2.0\Microsoft.AspNetCore.HttpsPolicy.dll v2.1.1.0 - .\Microsoft.AspNetCore.Diagnostics\2.1.1\lib\netstandard2.0\Microsoft.AspNetCore.Diagnostics.dll v2.1.1.0 - .\Microsoft.AspNetCore.Mvc\2.1.1\lib\netstandard2.0\Microsoft.AspNetCore.Mvc.dll v2.1.1.0 - .\Microsoft.AspNetCore\2.1.1\lib\netstandard2.0\Microsoft.AspNetCore.dll v2.1.1.0 - .\Microsoft.AspNetCore.Mvc.Core\2.1.1\lib\netstandard2.0\Microsoft.AspNetCore.Mvc.Core.dll v2.1.1.0 - .\Microsoft.AspNetCore.Routing\2.1.1\lib\netstandard2.0\Microsoft.AspNetCore.Routing.dll v2.1.1.0 - .\Microsoft.AspNetCore.Http.Abstractions\2.1.1\lib\netstandard2.0\Microsoft.AspNetCore.Http.Abstractions.dll v2.1.1.0 - .\Microsoft.AspNetCore.Hosting.Abstractions\2.1.1\lib\netstandard2.0\Microsoft.AspNetCore.Hosting.Abstractions.dll v2.1.1.0 |
| .NET Assemblies loaded from {C:\Users\Paulius\.nuget\packages} - .\Microsoft.Extensions.Hosting\3.0.0\lib\netcoreapp3.0\Microsoft.Extensions.Hosting.dll v3.0.0.0 - .\Microsoft.Extensions.Logging.Abstractions\3.0.0\lib\netstandard2.0\Microsoft.Extensions.Logging.Abstractions.dll v3.0.0.0 - .\System.Drawing.Common\4.7.0\ref\netcoreapp3.0\System.Drawing.Common.dll v4.0.2.0 - .\Microsoft.Extensions.Configuration.Abstractions\3.0.0\lib\netcoreapp3.0\Microsoft.Extensions.Configuration.Abstractions.dll v3.0.0.0 - .\Microsoft.Extensions.DependencyInjection.Abstractions\3.0.0\lib\netstandard2.0\Microsoft.Extensions.DependencyInjection.Abstractions.dll v3.0.0.0 - .\Microsoft.Extensions.Hosting.Abstractions\3.0.0\lib\netcoreapp3.0\Microsoft.Extensions.Hosting.Abstractions.dll v3.0.0.0 - .\Microsoft.Extensions.Configuration.UserSecrets\3.0.0\lib\netcoreapp3.0\Microsoft.Extensions.Configuration.UserSecrets.dll v3.0.0.0 |
 | The source file {C:\Users\Paulius\source\repos\FlightSystem2\FlightSystem2\Src\Application\LocationInfo\LocationManager.cs} (last modified 2019-12-10 23:51:44) and the PDB file of the assembly {FlightSystem.Api} (last modified 2019-12-10 23:18:10) are not in-sync. |
| 31 source files parsed ; all source files found ; 1 source file not in-sync with PDB |
| 0 code rule has been extracted from code. |
| No dependency cycle detected in assemblies referencement graph. |
| Do merge code generated by compiler into application code. |
| Analyse dependencies of your application. |
| No SuppressMessageAttribute found in the analyzed code base. Since NDepend v2018.2 SuppressMessageAttribute can be used to suppress NDepend issues. Don't forget to set in your projects the compilation symbol CODE_ANALYSIS to use this attribute to suppress NDepend issues. |
| Log trend metrics values. |
| Execute queries and rules. |
 | 2 quality gates fail: - - 'Critical Rules Violated' value 2 rules greater than fail threshold 0 rules - - 'Debt Rating per Namespace' value 4 namespaces greater than fail threshold 0 namespaces |
| Building the report (standard). |
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: -