NDepend Report

ndepend report summary application nameSqlWrangler-Review (v1.0.0.0)report build date07/21/2019 22:35:26analysis duration00:15ndepend version 2019.2.5 Professional Developer/Build-Machine Editionbaseline for comparisonCompare with analysis result obtained on 2019 July - 21 Sunday 06:51 (which is the analysis result with date closest to 30 days ago)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.

Diagrams

Dependency Graph

View as ?full scaled

Dependency Matrix

View as ?full scaled

Treemap Metric View

View as ?full scaled

Abstractness vs. Instability

View ?control image

Application Metrics

Note: Further Application Statistics are available.

# Lines of Code

1 523

-12

635 (NotMyCode)

no diff

Estimated Dev Effort 33d

-0.18d

# Types

2 Assemblies

no diff

4 Namespaces

106 Methods

83 Fields

23 Source Files

676 Third-Party Elements

Comment

23.08%

from 23.4%

457 Lines of Comment

-12

Debt

7.12%

from 6.82%

Rating

5h 35min effort to reach

Debt 2d 2h

+41min

The technical-debt is incomplete because no coverage data specified.

CoverageN/A because no coverage data specified

Method Complexity

10 Max

-1

2.25 Average

-0.023

Quality Gates

Fail

Warn

Pass

Rules

Critical

-3

Violated

-5

115

Issues

All

104

+19

-24

Blocker

Critical

High

-1

Medium

-23

Low

Suppressed

Quality Gates summary

721

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

Percentage Coverage

N/A because no coverage data

Project Rules \ Quality Gates

Percentage Coverage on New Code

N/A because no coverage data

Project Rules \ Quality Gates

Percentage Coverage on Refactored Code

N/A because no coverage data

Project Rules \ Quality Gates

Blocker Issues

0 issues

Project Rules \ Quality Gates

Critical Issues

0 issues

Project Rules \ Quality Gates

New Blocker / Critical / High Issues

9 issues

Project Rules \ Quality Gates

Percentage Debt

6.82 %

7.12 %

Project Rules \ Quality Gates

New Debt since Baseline

0.086 man-days

Project Rules \ Quality Gates

Debt Rating per Namespace

0 namespaces

Project Rules \ Quality Gates

New Annual Interest since Baseline

0.57 man-days

Project Rules \ Quality Gates

Rules summary

127211

Number of Rules or Queries with Error (syntax error, exception thrown, time-out): 0
Number of Rules violated: 22

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.

Name

# Issues

Added

Fixed

Elements

Group

Avoid types with too many methods

type

Project Rules \ Code Smells

Avoid methods potentially poorly commented

methods

Project Rules \ Code Smells

Avoid types with poor cohesion

types

Project Rules \ Code Smells

From now, all methods added should respect basic quality principles

methods

Project Rules \ Code Smells Regression

Avoid adding instance fields to a type that already had many instance fields

type

Project Rules \ Code Smells Regression

Class with no descendant should be sealed if possible

types

Project Rules \ Object Oriented Design

A stateless class or structure might be turned into a static type

types

Project Rules \ Object Oriented Design

Methods should be declared static if possible

methods

Project Rules \ Object Oriented Design

Don't use obsolete types, methods or fields

method

Project Rules \ Design

Avoid namespaces mutually dependent

members

Project Rules \ Architecture

Avoid namespaces dependency cycles

namespace

Project Rules \ Architecture

UI layer shouldn't use directly DB types

types

Project Rules \ Architecture

UI layer shouldn't use directly DAL layer

types

Project Rules \ Architecture

Methods that could have a lower visibility

methods

Project Rules \ Visibility

Types that could be declared as private, nested in a parent type

type

Project Rules \ Visibility

Avoid public methods not publicly visible

methods

Project Rules \ Visibility

Fields should be marked as ReadOnly when possible

fields

Project Rules \ Immutability

Methods name should begin with an Upper character

methods

Project Rules \ Naming Conventions

Avoid methods with name too long

method

Project Rules \ Naming Conventions

Avoid defining multiple types in a source file

types

Project Rules \ Source Files Organization

Do not raise too general exception types

method

Project Rules \ .NET Framework Usage \ System

Float and Date Parsing must be culture aware

method

Project Rules \ .NET Framework Usage \ System.Globalization

Application Statistics

Stat	# Occurences	Avg	StdDev	Max
Properties on interfaces	interfaces	0	0	-1 properties on
Methods on interfaces	interfaces	0	0	-1 methods on
Arguments on methods on interfaces	methods	0	0	-1 arguments on
Public properties on classes	17 Classes	1.24	2.44	9 public properties on SqlWrangler.FieldDefinition
Public methods on classes	17 classes	3.59	4.75	19 public methods on SqlWrangler.FieldDefinition
Arguments on public methods on classes	61 methods	0.64	0.91	5 arguments on SqlWrangler.Services.SnippetMenuBuilder.BuildSnippetMenu(List<TextSnippet>,ToolStripMenuItem,Keys,Scintilla,DataGridView)
IL instructions in non-abstract methods	178 methods	52.9	119.68	1256 IL instructions in SqlWrangler.SqlClient.InitializeComponent()
Cyclomatic complexity on non abstract Methods	178 Methods	3.08	3.88	CC = 18 for SqlWrangler.FrmExportSql.btnOk_Click(Object,EventArgs)

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.

Assemblies	# lines of code	# IL instruction	# Types	# Abstract Types	# lines of comment	% Comment	% Coverage	Afferent Coupling	Efferent Coupling	Relational Cohesion	Instability	Abstractness	Distance
SqliteTools v1.0.0.0	75	662	2	0	47	38.52	-	1	35	0.5	0.97	0	0.02
SqlWrangler v1.0.0.0	1448	8755	16	0	410	22.07	-	0	199	1.56	1	0	0

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
FrmLogin	1.95	205	1126	50	19.61	35	45	-	2	74	SqlWrangler
Resources	1.33	37	217	52	58.43	20	20	-	6	14	SqlWrangler.Properties
TextSnippet	0.76	4	18	0	0	4	5	-	3	5	SqlWrangler
FieldDefinition	0.56	18	67	0	0	18	19	-	1	7	SqlWrangler
MapperAttributeType	0.56	-	-	0	-	0	-	-	1	2	SqlWrangler
Settings	0.54	12	98	0	0	12	13	-	2	12	SqlWrangler.Properties
FrmNameInput	0.47	62	318	26	29.55	11	12	-	1	33	SqlWrangler
Table	0.37	74	585	29	28.16	31	46	-	1	34	SqliteTools
SqlClient	0.34	407	2556	104	20.35	81	119	-	1	120	SqlWrangler
FrmMain	0.32	110	637	37	25.17	26	35	-	1	59	SqlWrangler
RowComparerResult	0.3	4	18	0	0	4	5	-	1	7	SqlWrangler
ScintillaStyler	0.25	17	125	8	32	1	2	-	1	9	SqlWrangler.Services
SnippetMenuBuilder	0.25	44	342	0	0	14	26	-	1	35	SqlWrangler.Services
FrmExportSql	0.25	129	773	39	23.21	21	34	-	1	52	SqlWrangler
DataRowComparerViewer	0.25	227	1394	44	16.24	58	97	-	1	76	SqlWrangler
Wizard	0.25	169	1056	5	2.87	49	69	-	1	28	SqlWrangler
Program	0.15	3	10	3	50	1	1	-	0	7	SqlWrangler
SqliteTypes	0.15	1	77	1	50	1	1	-	0	18	SqliteTools

Types Metrics : Code Members and Inheritance

Type Name	# Instance Methods	Nb Static Methods	Nb Properties	# Fields	# Children Classes	Depth Of Inheritance Tree	Type Namespace
FrmLogin	11	0	0	12	0	7	SqlWrangler
Resources	1	18	17	2	0	1	SqlWrangler.Properties
TextSnippet	5	0	2	2	0	1	SqlWrangler
FieldDefinition	19	0	9	9	0	1	SqlWrangler
MapperAttributeType	-	-	-	-	-	-	SqlWrangler
Settings	11	2	6	1	0	3	SqlWrangler.Properties
FrmNameInput	8	0	1	6	0	7	SqlWrangler
Table	12	1	3	3	0	1	SqliteTools
SqlClient	29	0	2	33	0	7	SqlWrangler
FrmMain	16	0	2	11	0	7	SqlWrangler
RowComparerResult	5	0	2	2	0	1	SqlWrangler
ScintillaStyler	2	0	0	0	0	1	SqlWrangler.Services
SnippetMenuBuilder	3	0	0	0	0	1	SqlWrangler.Services
FrmExportSql	8	0	1	10	0	7	SqlWrangler
DataRowComparerViewer	15	0	0	14	0	7	SqlWrangler
Wizard	10	0	0	1	0	1	SqlWrangler
Program	0	1	0	0	0	1	SqlWrangler
SqliteTypes	0	1	0	1	0	1	SqliteTools

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
FrmLogin	0.82	0.9	116	SqlWrangler
Resources	0	0	5	SqlWrangler.Properties
TextSnippet	0	0	1	SqlWrangler
FieldDefinition	0	0	1	SqlWrangler
MapperAttributeType	-	-	0	SqlWrangler
Settings	0	0	4	SqlWrangler.Properties
FrmNameInput	0.73	0.88	42	SqlWrangler
Table	0	0	37	SqliteTools
SqlClient	0.92	0.96	208	SqlWrangler
FrmMain	0.88	0.96	80	SqlWrangler
RowComparerResult	0	0	1	SqlWrangler
ScintillaStyler	0	0	17	SqlWrangler.Services
SnippetMenuBuilder	0	0	51	SqlWrangler.Services
FrmExportSql	0.73	0.85	78	SqlWrangler
DataRowComparerViewer	0.8	0.86	134	SqlWrangler
Wizard	0.8	0.89	62	SqlWrangler
Program	0	0	4	SqlWrangler
SqliteTypes	0	0	3	SqliteTools

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.

Namespaces	# lines of code	# IL instruction	# Types	# lines of comment	% Comment	% Coverage	Afferent Coupling	Efferent Coupling
SqliteTools	75	662	2	30	28.57	-	1	9
SqlWrangler	1338	7973	12	308	18.71	-	1	33
SqlWrangler.Properties	49	315	2	59	54.63	-	1	10
SqlWrangler.Services	61	467	2	8	11.59	-	1	11

721
Project Rules

721
Quality Gates

1 Quality Gate(s) that Fail
- New Blocker / Critical / High Issues
2 Quality Gate(s) that Warn
- New Debt since Baseline
- New Annual Interest since Baseline
7 Quality Gate(s) that Pass

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 Fail: 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.

9 issues matched

9 issues	Severity	Debt	Annual Interest	Full Name
High issue on: SqlWrangler.SqlClient .ColorToolStripMenuItem_Click(Object ,EventArgs)	2High	65min	21h 0min	Rule violated: From now, all methods added should respect basic quality principles
High issue on: SqlWrangler.Services .SnippetMenuBuilder.BuildSnippetMenu (List<TextSnippet>,ToolStripMenuItem ,Keys,Scintilla,DataGridView)	3High	55min	11h 0min	Rule violated: From now, all methods added should respect basic quality principles
High issue on: SqlWrangler.Services .SnippetMenuBuilder.InsertFields (Scintilla,DataGridView)	0High	85min	01h 0min	Rule violated: From now, all methods added should respect basic quality principles
High issue on: SqlWrangler.SqlClient	1High	320min	520min	Rule violated: Avoid adding instance fields to a type that already had many instance fields
High issue on: SqliteTools.SqliteTypes..cctor()	4High	75min	620min	Rule violated: Don't use obsolete types, methods or fields
High issue on: SqlWrangler.SqlClient	7High	420min	341min	Rule violated: Avoid namespaces mutually dependent
High issue on: SqlWrangler.SqlClient. .ctor(List<TextSnippet>)	8High	230min	441min	Rule violated: Avoid namespaces mutually dependent
High issue on: SqlWrangler	5High	02h 0min	720min	Rule violated: Avoid namespaces dependency cycles
High issue on: SqlWrangler.Services.SnippetMenuBuilder	6High	136min	820min	Rule violated: UI layer shouldn't use directly DB types

Statistics

Stat	Severity	Debt	Annual Interest
Sum:	-	4h 6min	5h 43min
Average:	-	27min	38min
Minimum:	-	5min	20min
Maximum:	-	2h 0min	1h 0min
Standard deviation:	-	34min	17min
Variance:	-	149d	38d

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: 7.12 %

Quality Gate Warn: 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.086 man-days

Quality Gate Pass: Debt Rating per Namespace

• Quality Gate Description:

Forbid namespaces with a poor Debt Rating equals to E or D.

The Debt Rating for a code element is estimated by the value of the Debt Ratio and from the various rating thresholds defined in this project Debt Settings.

The Debt Ratio of a code element is a percentage of Debt Amount (in floating man-days) compared to the estimated effort to develop the code element (also in floating man-days).

The estimated effort to develop the code element is inferred from the code elements number of lines of code, and from the project Debt Settings parameters estimated number of man-days to develop 1000 logical lines of code.

The logical lines of code corresponds to the number of debug breakpoints in a method and doesn't depend on code formatting nor comments.

The Quality Gate can be modified to match assemblies, types or methods with a poor Debt Rating, instead of matching namespaces.

No namespace matched

Quality Gate Warn: 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.57 man-days

000
Rules extracted from Source Code

127211
Project Rules

530
Code Smells

3 Rule(s) violated

Rule Violated: Avoid types with too many methods

• Rule Description:

This rule matches types with more than 20 methods. Such type might be hard to understand and maintain.

Notice that methods like constructors or property and event accessors are not taken account.

Having many methods for a type might be a symptom of too many responsibilities implemented.

Maybe you are facing the God Class phenomenon: A God Class is a class that controls way too many other classes in the system and has grown beyond all logic to become The Class That Does Everything.

• How to Fix Issues of this Rule:

To refactor properly a God Class please read HowToFix advices from the default rule Types to Big. // The estimated Debt, which means the effort to fix such issue, varies linearly from 1 hour for a type with 20 methods, up to 10 hours for a type with 200 or more methods.

In Debt and Interest computation, this rule takes account of the fact that static types with no mutable fields are just a collection of static methods that can be easily splitted and moved from one type to another.

• How to Suppress an Issue of this Rule:

In source code, tag the concerned code element with this attribute:
[SuppressMessage("NDepend", "ND1001:AvoidTypesWithTooManyMethods", 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-bold~~ means removed (since baseline)

1 type	nbMethods	instanceMethods	staticMethods	# lines of code (LOC)	Debt	Annual Interest	Full Name
SqlClient	025	025 methods	0no method	0407	01h 15min	05min	SqlWrangler.SqlClient

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.

13 methods matched

Formatting: bold means added, underlined means code was changed, ~~strike-bold~~ means removed (since baseline)

13 methods	Percentage Comment	# lines of code (LOC)	# lines of comment	nbLinesOfCodeNotCommented	Debt	Annual Interest	Full Name
BuildSnippetMenu(List<TextSnippet> ,ToolStripMenuItem,Keys,Scintilla ,DataGridView)	080	0130	070	0130	013min 0s	0416min	SqlWrangler.Services.SnippetMenuBuilder .BuildSnippetMenu(List<TextSnippet> ,ToolStripMenuItem,Keys,Scintilla ,DataGridView)
CreateNhSessionFactory(String)	018.16	0045	004	0041	004min 6s	1110min	SqlWrangler.FrmLogin .CreateNhSessionFactory(String)
WriteCsWizard(DataTable,StreamWriter ,String,String)	070	0228	080	0228	022min 48s	0216min	SqlWrangler.Wizard.WriteCsWizard (DataTable,StreamWriter,String,String)
WriteMaterializer(DataTable,StreamWriter ,IEnumerable<FieldDefinition>)	053.57	0527	041	0426	042min 36s	0613min	SqlWrangler.Wizard.WriteMaterializer (DataTable,StreamWriter,IEnumerable <FieldDefinition>)
GetFields(DataTableReader)	063.57	0427	051	0326	032min 36s	0713min	SqlWrangler.Wizard.GetFields (DataTableReader)
Compare(DataRow,DataTable,String)	036.9	0327	022	0525	052min 30s	0911min	SqlWrangler.DataRowComparerViewer .Compare(DataRow,DataTable,String)
WriteModelClass(DataTable,StreamWriter ,IEnumerable<FieldDefinition> ,MapperAttributeType)	110	0625	110	0625	062min 30s	0316min	SqlWrangler.Wizard.WriteModelClass (DataTable,StreamWriter,IEnumerable <FieldDefinition>,MapperAttributeType)
ToggleMenuItems()	120	0924	120	0924	092min 24s	0016min	SqlWrangler.DataRowComparerViewer .ToggleMenuItems()
SaveExternalFile(Boolean)	090	1024	090	0824	082min 24s	0116min	SqlWrangler.SqlClient.SaveExternalFile (Boolean)
WriteMappings(DataTable,StreamWriter ,IEnumerable<FieldDefinition>)	043.85	0725	061	0724	072min 24s	0813min	SqlWrangler.Wizard.WriteMappings (DataTable,StreamWriter,IEnumerable <FieldDefinition>)
GenerateInsertSql(DataRow)	027.41	0825	032	1023	102min 18s	1010min	SqliteTools.Table.GenerateInsertSql (DataRow)
WizardToolStripMenuItem1_Click(Object ,EventArgs)	100	1222	100	1122	112min 12s	0516min	SqlWrangler.SqlClient .WizardToolStripMenuItem1_Click(Object ,EventArgs)
GetSnippets()	008.33	1122	012	1220	122min 0s	1210min	SqlWrangler.FrmMain.GetSnippets()

Rule Violated: Avoid types with poor cohesion

• Rule Description:

This rule is based on the LCOM code metric, LCOM stands for Lack Of Cohesion of Methods. See the definition of the LCOM metric here https://www.ndepend.com/docs/code-metrics#LCOM

The LCOM metric measures the fact that most methods are using most fields. A class is considered utterly cohesive (which is good) if all its methods use all its instance fields.

Only types with enough methods and fields are taken account to avoid bias. The LCOM takes its values in the range [0-1].

This rule matches types with LCOM higher than 0.8. Such value generally pinpoints a poorly cohesive class.

• How to Fix Issues of this Rule:

To refactor a poorly cohesive type and increase code quality and maintainability, certainly you'll have to split the type into several smaller and more cohesive types that together, implement the same logic.

The estimated Debt, which means the effort to fix such issue, varies linearly from 5 minutes for a type with a low poorCohesionScore, up to 4 hours for a type with high poorCohesionScore.

• How to Suppress an Issue of this Rule:

In source code, tag the concerned code element with this attribute:
[SuppressMessage("NDepend", "ND1007:AvoidTypesWithPoorCohesion", 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 types matched

Formatting: bold means added, underlined means code was changed, ~~strike-bold~~ means removed (since baseline)

4 types	Lack of Cohesion Of Methods (LCOM)	# Methods	# Fields	poorCohesionScore	Debt	Annual Interest	Full Name
DataRowComparerViewer	30.8	215	114	34.76	35min	32min 0s	SqlWrangler.DataRowComparerViewer
SqlClient	00.92	029	033	011.5	038min	013min	SqlWrangler.SqlClient
FrmMain	10.88	116	311	17.67	118min	16min	SqlWrangler.FrmMain
FrmLogin	20.82	311	212	25.21	26min	22min 22s	SqlWrangler.FrmLogin

720
Code Smells Regression

2 Rule(s) violated
- From now, all methods added should respect basic quality principles
- Avoid adding instance fields to a type that already had many instance fields

Rule Violated: From now, all methods added should respect basic quality principles

• 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 can be easily modified to also match methods refactored since baseline, that don't satisfy all quality criterions.

Methods matched by this rule not only have been recently added or refactored, but also somehow violate one or several basic quality principles, whether it is too large (too many lines of code), too complex (too many if, switch case, loops…) has too many variables, too many parameters or has too many overloads.

• How to Fix Issues of this Rule:

To refactor such method and increase code quality and maintainability, certainly you'll have to split the method into several smaller methods or even create one or several classes to implement the logic.

During this process it is important to question the scope of each variable local to the method. This can be an indication if such local variable will become an instance field of the newly created class(es).

Large switch…case structures might be refactored through the help of a set of types that implement a common interface, the interface polymorphism playing the role of the switch cases tests.

Unit Tests can help: write tests for each method before extracting it to ensure you don't break functionality.

Issues of this rule have a constant 5 minutes Debt, because the Debt, which means the effort to fix such issue, is already estimated for issues of rules in the category Code Smells.

However issues of this rule have a High severity, with even more interests for issues on new methods since baseline, because the proper time to increase the quality of these methods is now, before they get commited in the next production release.

• How to Suppress an Issue of this Rule:

In source code, tag the concerned code element with this attribute:
[SuppressMessage("NDepend", "ND1102:FromNowAllMethodsAddedShouldRespectBasicQualityPrinciples", 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.

3 methods matched

Formatting: bold means added, underlined means code was changed, ~~strike-bold~~ means removed (since baseline)

3 methods	# lines of code (LOC)	# IL instructions	Cyclomatic Complexity (CC)	IL Cyclomatic Complexity (ILCC)	IL Nesting Depth	# Parameters	# Variables	# Overloads	Debt	Annual Interest	Full Name
ColorToolStripMenuItem_Click(Object ,EventArgs)	115	273	17	28	06	12	22	01	05min	01h 0min	SqlWrangler.SqlClient .ColorToolStripMenuItem_Click(Object ,EventArgs)
BuildSnippetMenu(List<TextSnippet> ,ToolStripMenuItem,Keys,Scintilla ,DataGridView)	030	0244	09	015	21	05	15	11	15min	11h 0min	SqlWrangler.Services.SnippetMenuBuilder .BuildSnippetMenu(List<TextSnippet> ,ToolStripMenuItem,Keys,Scintilla ,DataGridView)
InsertFields(Scintilla,DataGridView)	214	194	25	110	13	22	09	21	25min	21h 0min	SqlWrangler.Services.SnippetMenuBuilder .InsertFields(Scintilla,DataGridView)

Rule Violated: Avoid adding instance fields to a type that already had many instance fields

• Rule Description:

This rule is executed only if a baseline for comparison is defined (diff mode).

Types where number of fields is greater than 15 might be hard to understand and maintain.

This rule lists types that already had more than 15 fields at the baseline time, and for which new fields have been added.

Having many fields for a type might be a symptom of too many responsibilities implemented.

Notice that constants fields and static-readonly fields are not taken account. Enumerations types are not taken account also.

• How to Fix Issues of this Rule:

To refactor such type and increase code quality and maintainability, certainly you'll have to group subsets of fields into smaller types and dispatch the logic implemented into the methods into these smaller types.

The estimated Debt, which means the effort to fix such issue, is equal to 10 minutes per field added.

Issues of this rule have a High severity, because it is important to focus on these issues now, before such code gets released in production.

• How to Suppress an Issue of this Rule:

In source code, tag the concerned code element with this attribute:
[SuppressMessage("NDepend", "ND1107:AvoidAddingInstanceFieldsToATypeThatAlreadyHadManyInstanceFields", 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-bold~~ means removed (since baseline)

1 type	nbOldFields	nbNewFields	addedFields	removedFields	Debt	Annual Interest	Full Name
SqlClient	029	031	02 fields	0no field	020min	020min	SqlWrangler.SqlClient

1130
Object Oriented Design

3 Rule(s) violated

Rule Violated: 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.

3 types matched

Formatting: bold means added, underlined means code was changed, ~~strike-bold~~ means removed (since baseline)

3 types	# lines of code (LOC)	Debt	Severity	Full Name
SnippetMenuBuilder	044	00min 30s	0Medium	SqlWrangler.Services.SnippetMenuBuilder
ScintillaStyler	217	10min 30s	1Medium	SqlWrangler.Services.ScintillaStyler
FieldDefinition	118	20min 30s	2Medium	SqlWrangler.FieldDefinition

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.

2 types matched

Formatting: bold means added, underlined means code was changed, ~~strike-bold~~ means removed (since baseline)

2 types	methodsUsingMe	Debt	Severity	Full Name
ScintillaStyler	01 method	02min 0s	0Low	SqlWrangler.Services.ScintillaStyler
SnippetMenuBuilder	11 method	12min 0s	1Low	SqlWrangler.Services.SnippetMenuBuilder

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.

9 methods matched

Formatting: bold means added, underlined means code was changed, ~~strike-bold~~ means removed (since baseline)

9 methods	staticFieldsUsed	methodsCallingMe	Debt	Severity	Full Name
StyleElement(Scintilla)	2no field	41 method	41min 0s	2Medium	SqlWrangler.Services.ScintillaStyler .StyleElement(Scintilla)
IsString(Type)	3no field	31 method	31min 0s	3Medium	SqliteTools.Table.IsString(Type)
IsDateTime(Type)	0no field	21 method	21min 0s	0Medium	SqliteTools.Table.IsDateTime(Type)
ExportSql(FileInfo,DataTable,String ,String,Boolean,Boolean)	1no field	51 method	51min 0s	1Medium	SqlWrangler.FrmExportSql.ExportSql (FileInfo,DataTable,String,String ,Boolean,Boolean)
CreateNhSessionFactory(String)	4no field	12 methods	11min 30s	4Medium	SqlWrangler.FrmLogin .CreateNhSessionFactory(String)
GetExcelConnectionString(String)	7no field	71 method	71min 0s	7Medium	SqlWrangler.FrmLogin .GetExcelConnectionString(String)
WriteLinq2DbField(StreamWriter ,FieldDefinition,String)	8no field	61 method	61min 0s	8Medium	SqlWrangler.Wizard.WriteLinq2DbField (StreamWriter,FieldDefinition,String)
WriteEntityFrameworkField(StreamWriter ,FieldDefinition,String)	5no field	81 method	81min 0s	5Medium	SqlWrangler.Wizard .WriteEntityFrameworkField(StreamWriter ,FieldDefinition,String)
GetFieldName(String)	6no field	04 methods	02min 30s	6Medium	SqlWrangler.Wizard.GetFieldName(String)

1110
Design

1 Rule(s) violated
- Don't use obsolete types, methods or fields

Rule Violated: Don't use obsolete types, methods or fields

• Rule Description:

The attribute System.ObsoleteAttribute is used to tag types, methods or fields of an API that clients shouldn't use because these code elements will be removed sooner or later.

This rule warns about methods that use a type, a method or a field, tagged with System.ObsoleteAttribute.

• How to Fix Issues of this Rule:

Typically when a code element is tagged with System.ObsoleteAttribute, a workaround message is provided to clients.

This workaround message will tell you what to do to avoid using the obsolete code element.

The estimated Debt, which means the effort to fix such issue, is 5 minutes per type, method or field used.

Issues of this rule have a severity High because it is important to not rely anymore on obsolete code.

• How to Suppress an Issue of this Rule:

In source code, tag the concerned code element with this attribute:
[SuppressMessage("NDepend", "ND1311:DontUseObsoleteTypesMethodsOrFields", 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-bold~~ means removed (since baseline)

1 method	obsoleteUsage	Debt	Severity	Full Name
.cctor()	01 type	05min	0High	SqliteTools.SqliteTypes..cctor()

431
Architecture

1 Critical Rule(s) violated
- Avoid namespaces mutually dependent
3 Rule(s) violated

Critical Rule Violated: Avoid namespaces mutually dependent

• Rule Description:

This rule lists types and methods from a low-level namespace that use types and methods from higher-level namespace.

The pair of low and high level namespaces is made of two namespaces that use each other.

For each pair of namespaces, to infer which one is low-level and which one is high-level, the rule computes the two coupling [from A to B] and [from B to A] in terms of number of types, methods and fields involved in the coupling. Typically the coupling from low-level to high-level namespace is significantly lower than the other legitimate coupling.

Following this rule is useful to avoid namespaces dependency cycles. This will get the code architecture close to a layered architecture, where low-level code is not allowed to use high-level code.

In other words, abiding by this rule will help significantly getting rid of what is often called spaghetti code: Entangled code that is not properly layered and structured.

More on this in our white books relative to partitioning code. https://www.ndepend.com/docs/white-books

• How to Fix Issues of this Rule:

Refactor the code to make sure that the low-level namespace doesn't use the high-level namespace.

The rule lists in detail which low-level types and methods shouldn't use which high-level types and methods. The refactoring patterns that help getting rid of each listed dependency include:

• Moving one or several types from the low-level namespaces to the high-level one, or do the opposite.

• Use Inversion of Control (IoC): http://en.wikipedia.org/wiki/Inversion_of_control This consists in creating new interfaces in the low-level namespace, implemented by classes in the high-level namespace. This way low-level code can consume high-level code through interfaces, without using directly high-level implementations. Interfaces can be passed to low-level code through the high-level namespace code, or through even higher-level code. In related documentations you can see these interfaces named as callbacks, and the overall pattern is also known as Dependency Injection (DI): http://en.wikipedia.org/wiki/Dependency_injection

That rule might not be applicable for frameworks that present public namespaces mutually dependent. In such situation the cost to break the API can be higher than the cost to let the code entangled.

-

The estimated Debt, which means the effort to fix such issue to make sure that the first namespace doesn't rely anymore on the second one, depends on the number of types and methods used.

Because both namespace are now forming a super-component that cannot be partitioned in smaller components, the cost to unfix each issue is proportional to the size of this super-component. As a consequence, the estimated Annual Interest, which means the annual cost to let both namespaces mutually dependend, is equal to an hour plus a number of minutes proportional to the size (in lines of code) of both namespaces. The obtained Annual Interest value is then divided by the number of detailled issues listed.

Often the estimated Annual Interest for each listed issue is higher than the Debt, which means that leaving such issue unfixed for a year costs more than taking the time to fix issue once.

--

To explore the coupling between the two namespaces mutually dependent:

1) from the becauseNamespace right-click menu choose Copy to Matrix Columns to export this low-level namespace to the horizontal header of the dependency matrix.

2) from the shouldntUseNamespace right-click menu choose Copy to Matrix Rows to export this high-level namespace to the vertical header of the dependency matrix.

3) double-click the black matrix cell (it is black because of the mutual dependency).

4) in the matrix command bar, click the button: Remove empty Row(s) and Column(s).

At this point, the dependency matrix shows types involved into the coupling.

• Blue cells represent types from low-level namespace using types from high-level namespace

• Green cells represent types from high-level namespace using types from low-level namespace

• Black cells represent types from low-level and high-level namespaces that use each other.

There are more green cells than blue and black cells because green cell represents correct coupling from high-level to low-level. The goal is to eliminate incorrect dependencies represented by blue and black cells.

• How to Suppress an Issue of this Rule:

In source code, tag the concerned code element with this attribute:
[SuppressMessage("NDepend", "ND1400:AvoidNamespacesMutuallyDependent", 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 members matched

Formatting: bold means added, underlined means code was changed, ~~strike-bold~~ means removed (since baseline)

2 types and methods	shouldntUse	becauseNamespace	shouldntUseNamespace	Debt	Annual Interest	Full Name
SqlClient	12 types	SqlWrangler	SqlWrangler.Services	120min	041min	SqlWrangler.SqlClient
.ctor(List<TextSnippet>)	04 methods	SqlWrangler	SqlWrangler.Services	030min	141min	SqlWrangler.SqlClient..ctor(List <TextSnippet>)

Rule Violated: Avoid namespaces dependency cycles

• Rule Description:

This rule lists all application namespace dependency cycles. Each row shows a different cycle, indexed with one of the namespace entangled in the cycle.

To browse a cycle on the dependency graph or the dependency matrix, right click a cycle cell and export the matched namespaces to the dependency graph or matrix.

In the matrix, dependency cycles are represented with red squares and black cells. To easily browse dependency cycles, the dependency matrix comes with an option: Display Direct and Indirect Dependencies

Read our white books relative to partitioning code, to know more about namespaces dependency cycles, and why avoiding them is a simple yet efficient solution to clean the architecture of a code base. https://www.ndepend.com/docs/white-books

• How to Fix Issues of this Rule:

Removing first pairs of mutually dependent namespaces will eliminate most namespaces dependency cycles. This is why it is recommended focusing on matches of the default rule Avoid namespaces mutually dependent before dealing with the present rule.

Once solving all mutually dependent namespaces, remaining cycles matched by the present rule necessarily involve 3 or more namespaces like in: A is using B is using C is using A. Such cycle can be broken by identifying which namespace should be at the lower-level. For example if B should be at the lower-level, then it means C should be at the higher-level and to break the cycle, you just have to remove the dependency from B to C, with a pattern described in the HowToFix section of the rule Avoid namespaces mutually dependent.

The estimated Debt, which means the effort to fix such issue, doesn't depend on the cycle length. First because fixing the rule Avoid namespaces mutually dependent will fix most cycle reported here, second because even a long cycle can be broken by removing a few dependency.

• How to Suppress an Issue of this Rule:

In source code, tag the concerned code element with this attribute:
[SuppressMessage("NDepend", "ND1401:AvoidNamespacesDependencyCycles", 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 namespace matched

Formatting: bold means added, underlined means code was changed, ~~strike-bold~~ means removed (since baseline)

1 namespace	cycle	Debt	Severity	Full Name
SqlWrangler	02 namespaces	02h 0min	0High	SqlWrangler

Rule Violated: UI layer shouldn't use directly DB types

• Rule Description:

This rule is more a sample rule to adapt to your need, than a rigid rule you should abide by. It shows how to define code layers in a rule and how to be warned about layers dependencies violations.

This rule first defines the UI layer and the DB framework layer. Second it checks if any UI layer type is using directly any DB framework layer type.

• The DB framework layer is defined as the set of third-party types in the framework ADO.NET, EntityFramework, NHibernate types, that the application is consuming. It is easy to append and suppress any DB framework.

• The UI layer (User Interface Layer) is defined as the set of types that use WPF, Windows Form, ASP.NET.

UI using directly DB frameworks is generally considered as poor design because DB frameworks accesses should be a concept hidden to UI, encapsulated into a dedicated Data Access Layer (DAL).

Notice that per defaut this rule estimates a technical debt proportional to the coupling between the UI and DB types.

• How to Fix Issues of this Rule:

This rule lists precisely which UI type uses which DB framework type. Instead of fixing matches one by one, first imagine how DB framework accesses could be encapsulated into a dedicated layer.

• How to Suppress an Issue of this Rule:

In source code, tag the concerned code element with this attribute:
[SuppressMessage("NDepend", "ND1403:UILayerShouldntUseDirectlyDBTypes", 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.

7 types matched

Formatting: bold means added, underlined means code was changed, ~~strike-bold~~ means removed (since baseline)

7 types	dbTypesAndMembersUsed	Debt	Severity	Full Name
SnippetMenuBuilder	34 types 2 methods	336min	2High	SqlWrangler.Services.SnippetMenuBuilder
DataRowComparerViewer	24 types 5 methods	21h 0min	1High	SqlWrangler.DataRowComparerViewer
FrmExportSql	62 types 1 method	624min	0High	SqlWrangler.FrmExportSql
FrmLogin	017 types 16 methods 1 field	02h 36min	3High	SqlWrangler.FrmLogin
FrmMain	51 type 2 methods	528min	6High	SqlWrangler.FrmMain
SqlClient	16 types 6 methods 1 field	11h 20min	5High	SqlWrangler.SqlClient
Wizard	44 types 2 methods	436min	4High	SqlWrangler.Wizard

Rule Violated: UI layer shouldn't use directly DAL layer

• Rule Description:

This rule is more a sample rule to adapt to your need, than a rigid rule you should abide by. It shows how to define code layers in a rule and how to be warned about layers dependencies violations.

This rule first defines the UI layer and the DAL layer. Second it checks if any UI layer type is using directly any DAL layer type.

• The DB layer (the DAL, Data Access Layer) is defined as the set of types of the application that use ADO.NET, EntityFramework, NHibernate types. It is easy to append and suppress any DB framework.

• The UI layer (User Interface Layer) is defined as the set of types that use WPF, Windows Form, ASP.NET.

UI using directly DAL is generally considered as poor design because DAL accesses should be a concept hidden to UI, encapsulated into an intermediary domain logic.

Notice that per defaut this rule estimates a technical debt proportional to the coupling between the UI with the DAL layer.

• How to Fix Issues of this Rule:

This rule lists precisely which UI type uses which DAL type.

More about this particular design topic here: http://www.kenneth-truyers.net/2013/05/12/the-n-layer-myth-and-basic-dependency-injection/

• How to Suppress an Issue of this Rule:

In source code, tag the concerned code element with this attribute:
[SuppressMessage("NDepend", "ND1404:UILayerShouldntUseDirectlyDALLayer", 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 types matched

Formatting: bold means added, underlined means code was changed, ~~strike-bold~~ means removed (since baseline)

5 types	dalTypesAndMembersUsed	Debt	Severity	Full Name
FrmExportSql	11 type 4 methods	232min	1High	SqlWrangler.FrmExportSql
FrmLogin	21 type 3 methods	132min	0High	SqlWrangler.FrmLogin
FrmMain	32 types 2 methods	328min	2High	SqlWrangler.FrmMain
SqlClient	04 types 6 methods	01h 0min	4High	SqlWrangler.SqlClient
Program	41 type 1 method	420min	3High	SqlWrangler.Program

730
Visibility

3 Rule(s) violated

Rule Violated: Methods that could have a lower visibility

• Rule Description:

This rule warns about methods that can be declared with a lower visibility without provoking any compilation error. For example private is a visibility lower than internal which is lower than public.

Narrowing visibility is a good practice because doing so promotes encapsulation. The scope from which methods can be called is then reduced to a minimum.

By default, this rule doesn't match publicly visible methods that could have a lower visibility because it cannot know if the developer left the method public intentionally or not. Public methods matched are declared in non-public types.

By default this rule doesn't match methods with the visibility public that could be internal, declared in a type that is not public (internal, or nested private for example) because this situation is caught by the rule Avoid public methods not publicly visible.

Notice that methods tagged with one of the attribute NDepend.Attributes.CannotDecreaseVisibilityAttribute or NDepend.Attributes.IsNotDeadCodeAttribute, found in NDepend.API.dll are not matched. If you don't want to link NDepend.API.dll but still wish to rely on this facility, you can declare these attributes in your code.

• How to Fix Issues of this Rule:

Declare each matched method with the specified optimal visibility in the CouldBeDeclared rule result column.

By default, this rule matches public methods. If you are publishing an API many public methods matched should remain public. In such situation, you can opt for the coarse solution to this problem by adding in the rule source code && !m.IsPubliclyVisible or you can prefer the finer solution by tagging each concerned method with CannotDecreaseVisibilityAttribute.

• How to Suppress an Issue of this Rule:

In source code, tag the concerned code element with this attribute:
[SuppressMessage("NDepend", "ND1800:MethodsThatCouldHaveALowerVisibility", 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.

3 methods matched

Formatting: bold means added, underlined means code was changed, ~~strike-bold~~ means removed (since baseline)

3 methods	Visibility	CouldBeDeclared	MethodsCallingMe	Debt	Severity	Full Name
get_TableName()	0Public	0Private	0no method	00min 30s	0Medium	SqlWrangler.FieldDefinition .get_TableName()
get_TableSchema()	1Public	1Private	1no method	10min 30s	1Medium	SqlWrangler.FieldDefinition .get_TableSchema()
get_ClassName()	2Public	2Private	2no method	20min 30s	2Medium	SqlWrangler.FieldDefinition .get_ClassName()

Rule Violated: Types that could be declared as private, nested in a parent type

• Rule Description:

This rule matches types that can be potentially nested and declared private into another type.

The conditions for a type to be potentially nested into a parent type are:

• the parent type is the only type consuming it,

• the type and the parent type are declared in the same namespace.

Declaring a type as private into a parent type promotes encapsulation. The scope from which the type can be consumed is then reduced to a minimum.

This rule doesn't match classes with extension methods because such class cannot be nested in another type.

• How to Fix Issues of this Rule:

Nest each matched type into the specified parent type and declare it as private.

However nested private types are hardly testable. Hence this rule might not be applied to types consumed directly by tests.

• How to Suppress an Issue of this Rule:

In source code, tag the concerned code element with this attribute:
[SuppressMessage("NDepend", "ND1803:TypesThatCouldBeDeclaredAsPrivateNestedInAParentType", 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-bold~~ means removed (since baseline)

1 type	couldBeNestedIn	Debt	Severity	Full Name
FieldDefinition	Wizard	03min 0s	0Low	SqlWrangler.FieldDefinition

Rule Violated: Avoid public methods not publicly visible

• Rule Description:

This rule warns about methods declared as public whose parent type is not declared as public.

In such situation public means, can be accessed from anywhere my parent type is visible. Some developers think this is an elegant language construct, some others find it misleading.

This rule can be deactivated if you don't agree with it. Read the whole debate here: http://ericlippert.com/2014/09/15/internal-or-public/

By default issues of this rule have a Low severity because they reflect more an advice than a problem.

• How to Fix Issues of this Rule:

Declare the method as internal if it is used outside of its type, else declare it as private.

• How to Suppress an Issue of this Rule:

In source code, tag the concerned code element with this attribute:
[SuppressMessage("NDepend", "ND1807:AvoidPublicMethodsNotPubliclyVisible", 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.

20 methods matched

Formatting: bold means added, underlined means code was changed, ~~strike-bold~~ means removed (since baseline)

20 methods	parentTypeVisibility	declareMethodAs	methodsCaller	Debt	Severity	Full Name
StyleElement(Scintilla)	06Internal	07Internal	061 method	060min 30s	06Low	SqlWrangler.Services.ScintillaStyler .StyleElement(Scintilla)
BuildSnippetMenu(List<TextSnippet> ,ToolStripMenuItem,Keys,Scintilla ,DataGridView)	05Internal	06Internal	081 method	050min 30s	05Low	SqlWrangler.Services.SnippetMenuBuilder .BuildSnippetMenu(List<TextSnippet> ,ToolStripMenuItem,Keys,Scintilla ,DataGridView)
get_TableName()	07Internal	00Private	19no method	070min 30s	07Low	SqlWrangler.FieldDefinition .get_TableName()
set_TableName(String)	09Internal	09Internal	071 method	090min 30s	09Low	SqlWrangler.FieldDefinition .set_TableName(String)
get_TableSchema()	08Internal	01Private	17no method	080min 30s	08Low	SqlWrangler.FieldDefinition .get_TableSchema()
set_TableSchema(String)	01Internal	08Internal	091 method	010min 30s	01Low	SqlWrangler.FieldDefinition .set_TableSchema(String)
get_ClassName()	00Internal	02Private	18no method	000min 30s	00Low	SqlWrangler.FieldDefinition .get_ClassName()
set_ClassName(String)	02Internal	03Internal	051 method	020min 30s	02Low	SqlWrangler.FieldDefinition .set_ClassName(String)
get_Name()	04Internal	04Internal	006 methods	040min 30s	04Low	SqlWrangler.FieldDefinition.get_Name()
set_Name(String)	03Internal	05Internal	101 method	030min 30s	03Low	SqlWrangler.FieldDefinition.set_Name (String)
get_DbFieldName()	16Internal	16Internal	016 methods	160min 30s	16Low	SqlWrangler.FieldDefinition .get_DbFieldName()
set_DbFieldName(String)	15Internal	15Internal	161 method	150min 30s	15Low	SqlWrangler.FieldDefinition .set_DbFieldName(String)
get_Length()	17Internal	17Internal	151 method	170min 30s	17Low	SqlWrangler.FieldDefinition.get_Length()
set_Length(Int32)	19Internal	19Internal	141 method	190min 30s	19Low	SqlWrangler.FieldDefinition.set_Length (Int32)
get_AllowsNull()	18Internal	18Internal	025 methods	180min 30s	18Low	SqlWrangler.FieldDefinition .get_AllowsNull()
set_AllowsNull(Boolean)	11Internal	11Internal	121 method	110min 30s	11Low	SqlWrangler.FieldDefinition .set_AllowsNull(Boolean)
get_Type()	10Internal	10Internal	033 methods	100min 30s	10Low	SqlWrangler.FieldDefinition.get_Type()
set_Type(String)	12Internal	12Internal	131 method	120min 30s	12Low	SqlWrangler.FieldDefinition.set_Type (String)
get_IsShortBool()	14Internal	14Internal	042 methods	140min 30s	14Low	SqlWrangler.FieldDefinition .get_IsShortBool()
set_IsShortBool(Boolean)	13Internal	13Internal	111 method	130min 30s	13Low	SqlWrangler.FieldDefinition .set_IsShortBool(Boolean)

1010
Immutability

1 Rule(s) violated
- Fields should be marked as ReadOnly when possible

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.

6 fields matched

Formatting: bold means added, underlined means code was changed, ~~strike-bold~~ means removed (since baseline)

6 fields	MethodsReadingMeButNotAssigningMe	MethodsAssigningMe	Debt	Severity	Full Name
components	22 methods	2no method	25min	2Medium	SqlWrangler.DataRowComparerViewer .components
components	12 methods	1no method	15min	1Medium	SqlWrangler.FrmExportSql.components
components	02 methods	0no method	05min	0Medium	SqlWrangler.FrmLogin.components
components	52 methods	5no method	55min	5Medium	SqlWrangler.FrmMain.components
components	42 methods	4no method	45min	4Medium	SqlWrangler.FrmNameInput.components
components	32 methods	3no method	35min	3Medium	SqlWrangler.SqlClient.components

1820
Naming Conventions

2 Rule(s) violated
- Methods name should begin with an Upper character
- Avoid methods with name too long

Rule Violated: Methods name should begin with an Upper character

• Rule Description:

This rule warns about methods whose names don't start with an Upper character. It is a common practice in the .NET world to use Pascal Casing Style to name methods.

Pascal Casing Style : The first letter in the identifier and the first letter of each subsequent concatenated word are capitalized. For example: ComputeSize

• How to Fix Issues of this Rule:

Pascal Case the names of matched methods.

• How to Suppress an Issue of this Rule:

In source code, tag the concerned code element with this attribute:
[SuppressMessage("NDepend", "ND2007:MethodsNameShouldBeginWithAnUpperCharacter", 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.

16 methods matched

Formatting: bold means added, underlined means code was changed, ~~strike-bold~~ means removed (since baseline)

16 methods	Debt	Severity	Full Name
btnCancel_Click(Object,EventArgs)	053min 0s	05Medium	SqlWrangler.FrmExportSql.btnCancel_Click (Object,EventArgs)
btnOk_Click(Object,EventArgs)	043min 0s	04Medium	SqlWrangler.FrmExportSql.btnOk_Click (Object,EventArgs)
button1_Click(Object,EventArgs)	073min 0s	07Medium	SqlWrangler.FrmLogin.button1_Click (Object,EventArgs)
button2_Click(Object,EventArgs)	063min 0s	06Medium	SqlWrangler.FrmLogin.button2_Click (Object,EventArgs)
frmLogin_Load(Object,EventArgs)	013min 0s	01Medium	SqlWrangler.FrmLogin.frmLogin_Load (Object,EventArgs)
comboBox1_SelectedIndexChanged(Object ,EventArgs)	003min 0s	00Medium	SqlWrangler.FrmLogin .comboBox1_SelectedIndexChanged(Object ,EventArgs)
txtPassword_KeyDown(Object,KeyEventArgs)	033min 0s	03Medium	SqlWrangler.FrmLogin.txtPassword_KeyDown (Object,KeyEventArgs)
button3_Click(Object,EventArgs)	023min 0s	02Medium	SqlWrangler.FrmLogin.button3_Click (Object,EventArgs)
newToolStripMenuItem_Click_1(Object ,EventArgs)	133min 0s	13Medium	SqlWrangler.FrmMain .newToolStripMenuItem_Click_1(Object ,EventArgs)
frmMain_FormClosed(Object ,FormClosedEventArgs)	123min 0s	12Medium	SqlWrangler.FrmMain.frmMain_FormClosed (Object,FormClosedEventArgs)
frmMain_DragDrop(Object,DragEventArgs)	153min 0s	15Medium	SqlWrangler.FrmMain.frmMain_DragDrop (Object,DragEventArgs)
helpToolStripMenuItem_Click(Object ,EventArgs)	143min 0s	14Medium	SqlWrangler.FrmMain .helpToolStripMenuItem_Click(Object ,EventArgs)
aboutToolStripMenuItem_Click(Object ,EventArgs)	093min 0s	09Medium	SqlWrangler.FrmMain .aboutToolStripMenuItem_Click(Object ,EventArgs)
button1_Click(Object,EventArgs)	083min 0s	08Medium	SqlWrangler.FrmNameInput.button1_Click (Object,EventArgs)
button2_Click(Object,EventArgs)	113min 0s	11Medium	SqlWrangler.FrmNameInput.button2_Click (Object,EventArgs)
txtName_KeyPress(Object ,KeyPressEventArgs)	103min 0s	10Medium	SqlWrangler.FrmNameInput .txtName_KeyPress(Object ,KeyPressEventArgs)

Rule Violated: Avoid methods with name too long

• Rule Description:

Methods with a name too long tend to decrease code readability. This might also be an indication that a method is doing too much.

This rule matches methods with names with more than 40 characters.

However it is considered as a good practice to name unit tests in such a way with a very expressive name, hence this rule doens't match methods tagged with FactAttribute, TestAttribute and TestCaseAttribute.

• How to Fix Issues of this Rule:

To fix a violation of this rule, rename the method with a shortest name that equally conveys the behavior of the method. Or eventually split the method into several smaller methods.

• How to Suppress an Issue of this Rule:

In source code, tag the concerned code element with this attribute:
[SuppressMessage("NDepend", "ND2010:AvoidMethodsWithNameTooLong", 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-bold~~ means removed (since baseline)

1 method	SimpleName	NameLength	Debt	Severity	Full Name
ClearAllCheckFieldsToolStripMenuItem_Cli ck(Object,EventArgs)	ClearAllCheckFieldsToolStripMenuItem_Click	042	03min 0s	0Medium	SqlWrangler.DataRowComparerViewer .ClearAllCheckFieldsToolStripMenuItem_Cl ick(Object,EventArgs)

510
Source Files Organization

1 Rule(s) violated
- Avoid defining multiple types in a source file

Rule Violated: Avoid defining multiple types in a source file

• Rule Description:

Defining multiple types in a single source file decreases code readability, because developers are used to see all types in a namespace, when expanding a folder in the Visual Studio Solution Explorer. Also doing so, leads to source files with too many lines.

Each match of this rule is a source file that contains several types definitions, indexed by one of those types, preferably the one with the same name than the source file name without file extension, if any.

• How to Fix Issues of this Rule:

To fix a violation of this rule, create a source file for each type.

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", "ND2102:AvoidDefiningMultipleTypesInASourceFile", 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.

3 types matched

Formatting: bold means added, underlined means code was changed, ~~strike-bold~~ means removed (since baseline)

3 types	TypesInSourceFile	SourceFilePathString	Debt	Severity	Full Name
DataRowComparerViewer	02 types	D:\src\SqlWrangler\SqlWrangler\SqlWrangler\DataRowComparerViewer.cs	03min 0s	0Low	SqlWrangler.DataRowComparerViewer
SqlClient	12 types	D:\src\SqlWrangler\SqlWrangler\SqlWrangler\SqlClient.cs	13min 0s	1Low	SqlWrangler.SqlClient
Wizard	22 types	D:\src\SqlWrangler\SqlWrangler\SqlWrangler\Wizard.cs	23min 0s	2Low	SqlWrangler.Wizard

2320
.NET Framework Usage

910
System

1 Rule(s) violated
- Do not raise too general exception types

Rule Violated: Do not raise too general exception types

• Rule Description:

The following exception types are too general to provide sufficient information to the user:

• System.Exception

• System.ApplicationException

• System.SystemException

If you throw such a general exception type in a library or framework, it forces consumers to catch all exceptions, including unknown exceptions that they do not know how to handle.

This rule matches methods that create an instance of such general exception class.

• How to Fix Issues of this Rule:

To fix a violation of this rule, change the type of the thrown exception to either a more derived type that already exists in the framework, or create your own type that derives from System.Exception.

The estimated Debt, which means the effort to fix such issue, is equal to 15 minutes per method matched, plus 5 minutes per too general exception types instantiated by the method.

• How to Suppress an Issue of this Rule:

In source code, tag the concerned code element with this attribute:
[SuppressMessage("NDepend", "ND2207:DoNotRaiseTooGeneralExceptionTypes", 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-bold~~ means removed (since baseline)

1 method	exceptionsCreated	Debt	Severity	Full Name
GenerateInsertSql(DataRow)	01 type	020min	0High	SqliteTools.Table.GenerateInsertSql (DataRow)

010
System.Globalization

1 Rule(s) violated
- Float and Date Parsing must be culture aware

Rule Violated: Float and Date Parsing must be culture aware

• Rule Description:

Globalization is the design and development of applications that support localized user interfaces and regional data for users in multiple cultures.

This rule warns about the usage of non-globalized overloads of the methods Parse(), TryParse() and ToString(), of the types DateTime, float, double and decimal. This is the symptom that your application is at least partially not globalized.

Non-globalized overloads of these methods are the overloads that don't take a parameter of type IFormatProvider.

• How to Fix Issues of this Rule:

Globalize your applicaton and make sure to use the globalized overloads of these methods. In the column MethodsCallingMe of this rule result are listed the methods of your application that call the non-globalized overloads.

More information on Creating Globally Aware Applications here: https://msdn.microsoft.com/en-us/library/cc853414(VS.95).aspx

The estimated Debt, which means the effort to fix such issue, is equal to 5 minutes per application method calling at least one non-culture aware method called, plus 3 minutes per non-culture aware method called.

• How to Suppress an Issue of this Rule:

In source code, tag the concerned code element with this attribute:
[SuppressMessage("NDepend", "ND2700:FloatAndDateParsingMustBeCultureAware", 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-bold~~ means removed (since baseline)

1 method	shouldntCall	Debt	Annual Interest	Full Name
GenerateInsertSql(DataRow)	01 method	08min	05min	SqliteTools.Table.GenerateInsertSql (DataRow)

Quality Gates

1 Quality Gate(s) that Fail
- New Blocker / Critical / High Issues
2 Quality Gate(s) that Warn
- New Debt since Baseline
- New Annual Interest since Baseline
7 Quality Gate(s) that Pass
1 Queries
- Quality Gates Evolution

Code Query: Quality Gates Evolution

• Query Description:

Show quality gates evolution between baseline and now.

When a quality gate relies on diff between now and baseline (like New Debt since Baseline) it is not executed against the baseline and as a consequence its evolution is not available.

Double-click a quality gate for editing.

7 quality gates matched

7 quality gates	Evolution	BaselineStatus	Status	BaselineValue	Value	Full Name
Blocker Issues	2	3Pass	3Pass	0 issues	0 issues	Quality Gate
Critical Issues	0	1Pass	4Pass	0 issues	0 issues	Quality Gate
New Blocker / Critical / High Issues	N/A	6N/A	0Fail	0null	9 issues	Quality Gate
Percentage Debt	3	0Pass	6Pass	6.82 %	7.12 %	Quality Gate
New Debt since Baseline	N/A	5N/A	1Warn	6null	0.086 man-days	Quality Gate
Debt Rating per Namespace	1	2Pass	5Pass	0 namespaces	0 namespaces	Quality Gate
New Annual Interest since Baseline	N/A	4N/A	2Warn	4null	0.57 man-days	Quality Gate

Statistics

Stat	Evolution	BaselineStatus	Status	BaselineValue	Value
Sum:	-	-	-	-	-
Average:	-	-	-	-	-
Minimum:	-	-	-	-	-
Maximum:	-	-	-	-	-
Standard deviation:	-	-	-	-	-
Variance:	-	-	-	-	-

Quality Gate Pass: Percentage Coverage

Scalar Result: N/A %

Quality Gate Pass: Percentage Coverage on New Code

Scalar Result: N/A %

Quality Gate Pass: Percentage Coverage on Refactored Code

Scalar Result: N/A %

Quality Gate Pass: Blocker Issues

No issue matched

Quality Gate Pass: Critical Issues

No issue matched

Quality Gate Fail: New Blocker / Critical / High Issues

9 issues matched

9 issues	Severity	Debt	Annual Interest	Full Name
High issue on: SqlWrangler.SqlClient .ColorToolStripMenuItem_Click(Object ,EventArgs)	2High	65min	21h 0min	Rule violated: From now, all methods added should respect basic quality principles
High issue on: SqlWrangler.Services .SnippetMenuBuilder.BuildSnippetMenu (List<TextSnippet>,ToolStripMenuItem ,Keys,Scintilla,DataGridView)	3High	55min	11h 0min	Rule violated: From now, all methods added should respect basic quality principles
High issue on: SqlWrangler.Services .SnippetMenuBuilder.InsertFields (Scintilla,DataGridView)	0High	85min	01h 0min	Rule violated: From now, all methods added should respect basic quality principles
High issue on: SqlWrangler.SqlClient	1High	320min	520min	Rule violated: Avoid adding instance fields to a type that already had many instance fields
High issue on: SqliteTools.SqliteTypes..cctor()	4High	75min	620min	Rule violated: Don't use obsolete types, methods or fields
High issue on: SqlWrangler.SqlClient	7High	420min	341min	Rule violated: Avoid namespaces mutually dependent
High issue on: SqlWrangler.SqlClient. .ctor(List<TextSnippet>)	8High	230min	441min	Rule violated: Avoid namespaces mutually dependent
High issue on: SqlWrangler	5High	02h 0min	720min	Rule violated: Avoid namespaces dependency cycles
High issue on: SqlWrangler.Services.SnippetMenuBuilder	6High	136min	820min	Rule violated: UI layer shouldn't use directly DB types

Statistics

Stat	Severity	Debt	Annual Interest
Sum:	-	4h 6min	5h 43min
Average:	-	27min	38min
Minimum:	-	5min	20min
Maximum:	-	2h 0min	1h 0min
Standard deviation:	-	34min	17min
Variance:	-	149d	38d

Quality Gate Pass: Percentage Debt

Scalar Result: 7.12 %

Quality Gate Warn: New Debt since Baseline

Scalar Result: 0.086 man-days

Quality Gate Pass: Debt Rating per Namespace

No namespace matched

Quality Gate Warn: New Annual Interest since Baseline

Scalar Result: 0.57 man-days

Hot Spots

7 Queries

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.

13 types matched

13 types	Debt	Issues	Annual Interest	Breaking Point	# lines of code (LOC)	DebtRating	DebtRatio	Full Name
SqlClient	005h 41min	0212 issues	004h 16min	06486d	00407	06B	048.41	SqlWrangler.SqlClient
FrmLogin	013h 43min	0113 issues	031h 10min	001 155d	02205	01C	0311.31	SqlWrangler.FrmLogin
FrmMain	021h 36min	0410 issues	041h 8min	05514d	05110	05B	058.13	SqlWrangler.FrmMain
DataRowComparerViewer	031h 20min	057 issues	0553min	03555d	01227	12A	083.64	SqlWrangler.DataRowComparerViewer
FrmExportSql	041h 8min	076 issues	0648min	04517d	04129	04B	065.32	SqlWrangler.FrmExportSql
Wizard	0556min	0310 issues	021h 38min	10209d	03169	10A	093.61	SqlWrangler.Wizard
SnippetMenuBuilder	0652min	067 issues	012h 38min	11120d	0844	02C	0212.54	SqlWrangler.Services.SnippetMenuBuilder
Table	0732min	085 issues	0739min	09296d	0674	11A	074.11	SqliteTools.Table
Program	0820min	111 issue	0920min	08365d	113	00D	0046.3	SqlWrangler.Program
FrmNameInput	1014min	104 issues	108min	02638d	0762	07A	122.1	SqlWrangler.FrmNameInput
FieldDefinition	0914min	0023 issues	118min	01638d	0918	08A	103.45	SqlWrangler.FieldDefinition
SqliteTypes	115min	121 issue	0820min	1291d	121	03C	0114.47	SqliteTools.SqliteTypes
ScintillaStyler	124min 0s	094 issues	124min 0s	07365d	1017	09A	112.31	SqlWrangler.Services.ScintillaStyler

Statistics

Stat	Debt	Issues	Annual Interest	Breaking Point	# lines of code (LOC)	DebtRating	DebtRatio
Sum:	2d 0h	103	1d 6h	5 952d	1 466	-	125.69
Average:	1h 17min	7.92	1h 5min	457d	112.77	-	9.67
Minimum:	4min 0s	1	4min 0s	91d	1	-	2.1
Maximum:	5h 41min	23	4h 16min	1 155d	407	-	46.3
Standard deviation:	1h 34min	5.68	1h 8min	266d	112	-	11.27
Variance:	1 122d	32.22	594d	overflow	12 543	-	127.11

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.

8 types matched

8 types	Breaking Point	Debt	Annual Interest	Issues	# lines of code (LOC)	DebtRating	DebtRatio	Full Name
SnippetMenuBuilder	7120d	652min	12h 38min	57 issues	744	0C	012.54	SqlWrangler.Services.SnippetMenuBuilder
Wizard	6209d	556min	21h 38min	310 issues	3169	6A	73.61	SqlWrangler.Wizard
Table	5296d	732min	739min	75 issues	674	7A	54.11	SqliteTools.Table
SqlClient	4486d	05h 41min	04h 16min	112 issues	0407	2B	28.41	SqlWrangler.SqlClient
FrmMain	3514d	21h 36min	41h 8min	210 issues	5110	3B	38.13	SqlWrangler.FrmMain
FrmExportSql	2517d	41h 8min	648min	66 issues	4129	4B	45.32	SqlWrangler.FrmExportSql
DataRowComparerViewer	1555d	31h 20min	553min	47 issues	1227	5A	63.64	SqlWrangler.DataRowComparerViewer
FrmLogin	01 155d	13h 43min	31h 10min	013 issues	2205	1C	111.31	SqlWrangler.FrmLogin

Statistics

Stat	Breaking Point	Debt	Annual Interest	Issues	# lines of code (LOC)	DebtRating	DebtRatio
Sum:	3 854d	1d 7h	1d 5h	70	1 365	-	57.06
Average:	481d	1h 58min	1h 39min	8.75	170.62	-	7.13
Minimum:	120d	32min	39min	5	44	-	3.61
Maximum:	1 155d	5h 41min	4h 16min	13	407	-	12.54
Standard deviation:	296d	1h 40min	1h 9min	2.73	106.66	-	3.29
Variance:	overflow	1 265d	596d	7.44	11 377	-	10.79

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

104 issues matched

The following list of issues is truncated and contains only the first 100 issues of the 104 issues matched.

104 issues	Debt	Annual Interest	Breaking Point	CodeElement	Full Name
High issue on: SqlWrangler.SqlClient .ColorToolStripMenuItem_Click(Object ,EventArgs)	0315min	0021h 0min	07730d	ColorToolStripMenuItem_Click(Object,EventArgs)	Rule violated: From now, all methods added should respect basic quality principles
High issue on: SqlWrangler.Services .SnippetMenuBuilder.BuildSnippetMenu (List<TextSnippet>,ToolStripMenuItem ,Keys,Scintilla,DataGridView)	0325min	0011h 0min	07530d	BuildSnippetMenu(List<TextSnippet>,ToolStripMenuItem,Keys,Scintilla,DataGridView)	Rule violated: From now, all methods added should respect basic quality principles
High issue on: SqlWrangler.Services .SnippetMenuBuilder.InsertFields (Scintilla,DataGridView)	0295min	0001h 0min	07630d	InsertFields(Scintilla,DataGridView)	Rule violated: From now, all methods added should respect basic quality principles
Medium issue on: SqlWrangler.SqlClient .WizardToolStripMenuItem1_Click(Object ,EventArgs)	0632min 12s	02616min	07450d	WizardToolStripMenuItem1_Click(Object,EventArgs)	Rule violated: Avoid methods potentially poorly commented
Medium issue on: SqlWrangler .DataRowComparerViewer.ToggleMenuItems()	0602min 24s	02416min	07354d	ToggleMenuItems()	Rule violated: Avoid methods potentially poorly commented
Medium issue on: SqlWrangler.SqlClient .SaveExternalFile(Boolean)	0612min 24s	02516min	07254d	SaveExternalFile(Boolean)	Rule violated: Avoid methods potentially poorly commented
Medium issue on: SqlWrangler.Wizard .WriteModelClass(DataTable,StreamWriter ,IEnumerable<FieldDefinition> ,MapperAttributeType)	0562min 30s	02316min	07157d	WriteModelClass(DataTable,StreamWriter,IEnumerable<FieldDefinition>,MapperAttributeType)	Rule violated: Avoid methods potentially poorly commented
Medium issue on: SqlWrangler.Wizard .WriteCsWizard(DataTable,StreamWriter ,String,String)	0532min 48s	02216min	07063d	WriteCsWizard(DataTable,StreamWriter,String,String)	Rule violated: Avoid methods potentially poorly commented
Medium issue on: SqlWrangler.Wizard .WriteMappings(DataTable,StreamWriter ,IEnumerable<FieldDefinition>)	0592min 24s	02913min	06965d	WriteMappings(DataTable,StreamWriter,IEnumerable<FieldDefinition>)	Rule violated: Avoid methods potentially poorly commented
Medium issue on: SqlWrangler.Services .SnippetMenuBuilder.BuildSnippetMenu (List<TextSnippet>,ToolStripMenuItem ,Keys,Scintilla,DataGridView)	0403min 0s	02116min	06868d	BuildSnippetMenu(List<TextSnippet>,ToolStripMenuItem,Keys,Scintilla,DataGridView)	Rule violated: Avoid methods potentially poorly commented
Medium issue on: SqlWrangler.Wizard .WriteMaterializer(DataTable ,StreamWriter,IEnumerable <FieldDefinition>)	0542min 36s	02813min	06770d	WriteMaterializer(DataTable,StreamWriter,IEnumerable<FieldDefinition>)	Rule violated: Avoid methods potentially poorly commented
Medium issue on: SqlWrangler.Wizard .GetFields(DataTableReader)	0552min 36s	02713min	06670d	GetFields(DataTableReader)	Rule violated: Avoid methods potentially poorly commented
Medium issue on: SqlWrangler.FrmMain.GetSnippets()	0662min 0s	03410min	06571d	GetSnippets()	Rule violated: Avoid methods potentially poorly commented
Medium issue on: SqliteTools.Table .GenerateInsertSql(DataRow)	0622min 18s	03210min	06477d	GenerateInsertSql(DataRow)	Rule violated: Avoid methods potentially poorly commented
Medium issue on: SqlWrangler .DataRowComparerViewer.Compare(DataRow ,DataTable,String)	0582min 30s	03111min	06381d	Compare(DataRow,DataTable,String)	Rule violated: Avoid methods potentially poorly commented
Medium issue on: SqlWrangler.Services.SnippetMenuBuilder	0940min 30s	0392min 0s	05891d	SnippetMenuBuilder	Rule violated: Class with no descendant should be sealed if possible
Medium issue on: SqlWrangler.FieldDefinition	0990min 30s	0402min 0s	06091d	FieldDefinition	Rule violated: Class with no descendant should be sealed if possible
Medium issue on: SqlWrangler.Services.ScintillaStyler	0980min 30s	0412min 0s	05991d	ScintillaStyler	Rule violated: Class with no descendant should be sealed if possible
High issue on: SqliteTools.SqliteTypes..cctor()	0305min	01020min	05791d	.cctor()	Rule violated: Don't use obsolete types, methods or fields
Medium issue on: SqlWrangler .FieldDefinition.get_TableName()	0900min 30s	0532min 0s	06291d	get_TableName()	Rule violated: Methods that could have a lower visibility
Medium issue on: SqlWrangler .FieldDefinition.get_TableSchema()	0890min 30s	0562min 0s	06191d	get_TableSchema()	Rule violated: Methods that could have a lower visibility
Medium issue on: SqlWrangler .FieldDefinition.get_ClassName()	0880min 30s	0552min 0s	05691d	get_ClassName()	Rule violated: Methods that could have a lower visibility
Medium issue on: SqlWrangler.FrmLogin .CreateNhSessionFactory(String)	0334min 6s	03310min	055145d	CreateNhSessionFactory(String)	Rule violated: Avoid methods potentially poorly commented
High issue on: SqlWrangler.SqlClient	01720min	00341min	054175d	SqlClient	Rule violated: Avoid namespaces mutually dependent
Medium issue on: SqliteTools.Table.IsString(Type)	0701min 0s	0502min 0s	048182d	IsString(Type)	Rule violated: Methods should be declared static if possible
Medium issue on: SqliteTools.Table.IsDateTime(Type)	0711min 0s	0512min 0s	047182d	IsDateTime(Type)	Rule violated: Methods should be declared static if possible
Medium issue on: SqlWrangler .FrmExportSql.ExportSql(FileInfo ,DataTable,String,String,Boolean,Boolean )	0681min 0s	0492min 0s	049182d	ExportSql(FileInfo,DataTable,String,String,Boolean,Boolean)	Rule violated: Methods should be declared static if possible
Medium issue on: SqlWrangler.FrmLogin .GetExcelConnectionString(String)	0691min 0s	0472min 0s	053182d	GetExcelConnectionString(String)	Rule violated: Methods should be declared static if possible
Medium issue on: SqlWrangler.Wizard .WriteLinq2DbField(StreamWriter ,FieldDefinition,String)	0741min 0s	0482min 0s	052182d	WriteLinq2DbField(StreamWriter,FieldDefinition,String)	Rule violated: Methods should be declared static if possible
Medium issue on: SqlWrangler.Wizard .WriteEntityFrameworkField(StreamWriter ,FieldDefinition,String)	0731min 0s	0542min 0s	051182d	WriteEntityFrameworkField(StreamWriter,FieldDefinition,String)	Rule violated: Methods should be declared static if possible
Medium issue on: SqlWrangler.Services .ScintillaStyler.StyleElement(Scintilla)	0721min 0s	0522min 0s	050182d	StyleElement(Scintilla)	Rule violated: Methods should be declared static if possible
High issue on: SqlWrangler.SqlClient. .ctor(List<TextSnippet>)	01130min	00441min	046262d	.ctor(List<TextSnippet>)	Rule violated: Avoid namespaces mutually dependent
Medium issue on: SqlWrangler.FrmLogin .CreateNhSessionFactory(String)	0671min 30s	0462min 0s	045273d	CreateNhSessionFactory(String)	Rule violated: Methods should be declared static if possible
High issue on: SqlWrangler.SqlClient	01620min	00520min	044354d	SqlClient	Rule violated: Avoid adding instance fields to a type that already had many instance fields
High issue on: SqlWrangler.Program	01520min	02020min	042365d	Program	Rule violated: UI layer shouldn't use directly DAL layer
High issue on: SqliteTools.Table .GenerateInsertSql(DataRow)	01820min	00920min	043365d	GenerateInsertSql(DataRow)	Rule violated: Do not raise too general exception types
High issue on: SqlWrangler.FrmExportSql	01424min	01720min	041438d	FrmExportSql	Rule violated: UI layer shouldn't use directly DB types
Medium issue on: SqlWrangler.Wizard.GetFieldName(String)	0572min 30s	0452min 0s	040456d	GetFieldName(String)	Rule violated: Methods should be declared static if possible
High issue on: SqlWrangler.FrmMain	01328min	01820min	039511d	FrmMain	Rule violated: UI layer shouldn't use directly DB types
High issue on: SqlWrangler.FrmMain	01228min	01920min	038511d	FrmMain	Rule violated: UI layer shouldn't use directly DAL layer
Medium issue on: SqlWrangler .FrmExportSql.btnCancel_Click(Object ,EventArgs)	0463min 0s	0432min 0s	026547d	btnCancel_Click(Object,EventArgs)	Rule violated: Methods name should begin with an Upper character
Medium issue on: SqlWrangler .FrmExportSql.btnOk_Click(Object ,EventArgs)	0413min 0s	0442min 0s	025547d	btnOk_Click(Object,EventArgs)	Rule violated: Methods name should begin with an Upper character
Medium issue on: SqlWrangler.FrmLogin .button1_Click(Object,EventArgs)	0423min 0s	0422min 0s	028547d	button1_Click(Object,EventArgs)	Rule violated: Methods name should begin with an Upper character
Medium issue on: SqlWrangler.FrmLogin .button2_Click(Object,EventArgs)	0433min 0s	0712min 0s	023547d	button2_Click(Object,EventArgs)	Rule violated: Methods name should begin with an Upper character
Medium issue on: SqlWrangler.FrmLogin .frmLogin_Load(Object,EventArgs)	0453min 0s	0722min 0s	022547d	frmLogin_Load(Object,EventArgs)	Rule violated: Methods name should begin with an Upper character
Medium issue on: SqlWrangler.FrmLogin .comboBox1_SelectedIndexChanged(Object ,EventArgs)	0443min 0s	0702min 0s	021547d	comboBox1_SelectedIndexChanged(Object,EventArgs)	Rule violated: Methods name should begin with an Upper character
Medium issue on: SqlWrangler.FrmLogin .txtPassword_KeyDown(Object,KeyEventArgs )	0363min 0s	0682min 0s	024547d	txtPassword_KeyDown(Object,KeyEventArgs)	Rule violated: Methods name should begin with an Upper character
Medium issue on: SqlWrangler.FrmLogin .button3_Click(Object,EventArgs)	0353min 0s	0692min 0s	029547d	button3_Click(Object,EventArgs)	Rule violated: Methods name should begin with an Upper character
Medium issue on: SqlWrangler.FrmMain .newToolStripMenuItem_Click_1(Object ,EventArgs)	0343min 0s	0762min 0s	027547d	newToolStripMenuItem_Click_1(Object,EventArgs)	Rule violated: Methods name should begin with an Upper character
Medium issue on: SqlWrangler.FrmMain .frmMain_FormClosed(Object ,FormClosedEventArgs)	0393min 0s	0772min 0s	033547d	frmMain_FormClosed(Object,FormClosedEventArgs)	Rule violated: Methods name should begin with an Upper character
Medium issue on: SqlWrangler.FrmMain .frmMain_DragDrop(Object,DragEventArgs)	0383min 0s	0752min 0s	035547d	frmMain_DragDrop(Object,DragEventArgs)	Rule violated: Methods name should begin with an Upper character
Medium issue on: SqlWrangler.FrmMain .helpToolStripMenuItem_Click(Object ,EventArgs)	0373min 0s	0732min 0s	034547d	helpToolStripMenuItem_Click(Object,EventArgs)	Rule violated: Methods name should begin with an Upper character
Medium issue on: SqlWrangler.FrmMain .aboutToolStripMenuItem_Click(Object ,EventArgs)	0473min 0s	0742min 0s	037547d	aboutToolStripMenuItem_Click(Object,EventArgs)	Rule violated: Methods name should begin with an Upper character
Medium issue on: SqlWrangler .FrmNameInput.button1_Click(Object ,EventArgs)	0513min 0s	0672min 0s	036547d	button1_Click(Object,EventArgs)	Rule violated: Methods name should begin with an Upper character
Medium issue on: SqlWrangler .FrmNameInput.button2_Click(Object ,EventArgs)	0523min 0s	0602min 0s	031547d	button2_Click(Object,EventArgs)	Rule violated: Methods name should begin with an Upper character
Medium issue on: SqlWrangler .FrmNameInput.txtName_KeyPress(Object ,KeyPressEventArgs)	0503min 0s	0612min 0s	030547d	txtName_KeyPress(Object,KeyPressEventArgs)	Rule violated: Methods name should begin with an Upper character
Medium issue on: SqlWrangler.DataRowComparerViewer .ClearAllCheckFieldsToolStripMenuItem_Cl ick(Object,EventArgs)	0483min 0s	0592min 0s	032547d	ClearAllCheckFieldsToolStripMenuItem_Click(Object,EventArgs)	Rule violated: Avoid methods with name too long
High issue on: SqlWrangler.FrmExportSql	00932min	00820min	019584d	FrmExportSql	Rule violated: UI layer shouldn't use directly DAL layer
High issue on: SqlWrangler.FrmLogin	01032min	00620min	020584d	FrmLogin	Rule violated: UI layer shouldn't use directly DAL layer
Medium issue on: SqliteTools.Table .GenerateInsertSql(DataRow)	0208min	0375min	018584d	GenerateInsertSql(DataRow)	Rule violated: Float and Date Parsing must be culture aware
High issue on: SqlWrangler.Wizard	00736min	00720min	017657d	Wizard	Rule violated: UI layer shouldn't use directly DB types
High issue on: SqlWrangler.Services.SnippetMenuBuilder	00836min	01320min	016657d	SnippetMenuBuilder	Rule violated: UI layer shouldn't use directly DB types
Medium issue on: SqlWrangler.DataRowComparerViewer	0225min	0572min 0s	009912d	DataRowComparerViewer	Rule violated: Avoid types with poor cohesion
Medium issue on: SqlWrangler .DataRowComparerViewer.components	0255min	0582min 0s	012912d	components	Rule violated: Fields should be marked as ReadOnly when possible
Medium issue on: SqlWrangler.FrmExportSql.components	0245min	0652min 0s	011912d	components	Rule violated: Fields should be marked as ReadOnly when possible
Medium issue on: SqlWrangler.FrmLogin.components	0235min	0662min 0s	010912d	components	Rule violated: Fields should be marked as ReadOnly when possible
Medium issue on: SqlWrangler.FrmMain.components	0285min	0642min 0s	015912d	components	Rule violated: Fields should be marked as ReadOnly when possible
Medium issue on: SqlWrangler.FrmNameInput.components	0275min	0622min 0s	014912d	components	Rule violated: Fields should be marked as ReadOnly when possible
Medium issue on: SqlWrangler.SqlClient.components	0265min	0632min 0s	013912d	components	Rule violated: Fields should be marked as ReadOnly when possible
Medium issue on: SqlWrangler.FrmLogin	0216min	0382min 22s	008941d	FrmLogin	Rule violated: Avoid types with poor cohesion
Medium issue on: SqlWrangler.FrmMain	01918min	0356min	0071 043d	FrmMain	Rule violated: Avoid types with poor cohesion
Medium issue on: SqlWrangler.SqlClient	00638min	03013min	0061 071d	SqlClient	Rule violated: Avoid types with poor cohesion
High issue on: SqlWrangler.DataRowComparerViewer	0051h 0min	01220min	0051 095d	DataRowComparerViewer	Rule violated: UI layer shouldn't use directly DB types
High issue on: SqlWrangler.SqlClient	0041h 0min	01420min	0041 095d	SqlClient	Rule violated: UI layer shouldn't use directly DAL layer
High issue on: SqlWrangler.SqlClient	0021h 20min	01620min	0031 460d	SqlClient	Rule violated: UI layer shouldn't use directly DB types
High issue on: SqlWrangler	0012h 0min	01520min	0022 190d	SqlWrangler	Rule violated: Avoid namespaces dependency cycles
High issue on: SqlWrangler.FrmLogin	0002h 36min	01120min	0012 847d	FrmLogin	Rule violated: UI layer shouldn't use directly DB types
Medium issue on: SqlWrangler.SqlClient	0031h 15min	0365min	0005 186d	SqlClient	Rule violated: Avoid types with too many methods
Low issue on: SqlWrangler.Services.ScintillaStyler	0642min 0s	0920min 0s	09200:00:00	ScintillaStyler	Rule violated: A stateless class or structure might be turned into a static type
Low issue on: SqlWrangler.Services.SnippetMenuBuilder	0652min 0s	0930min 0s	09300:00:00	SnippetMenuBuilder	Rule violated: A stateless class or structure might be turned into a static type
Low issue on: SqlWrangler.FieldDefinition	0493min 0s	0910min 0s	09100:00:00	FieldDefinition	Rule violated: Types that could be declared as private, nested in a parent type
Low issue on: SqlWrangler .FieldDefinition.get_TableName()	0860min 30s	0890min 0s	08900:00:00	get_TableName()	Rule violated: Avoid public methods not publicly visible
Low issue on: SqlWrangler .FieldDefinition.set_TableName(String)	0850min 30s	0900min 0s	09000:00:00	set_TableName(String)	Rule violated: Avoid public methods not publicly visible
Low issue on: SqlWrangler .FieldDefinition.get_TableSchema()	0840min 30s	0940min 0s	09400:00:00	get_TableSchema()	Rule violated: Avoid public methods not publicly visible
Low issue on: SqlWrangler .FieldDefinition.set_TableSchema(String)	0770min 30s	0980min 0s	09800:00:00	set_TableSchema(String)	Rule violated: Avoid public methods not publicly visible
Low issue on: SqlWrangler .FieldDefinition.get_ClassName()	0760min 30s	0990min 0s	09900:00:00	get_ClassName()	Rule violated: Avoid public methods not publicly visible
Low issue on: SqlWrangler .FieldDefinition.set_ClassName(String)	0750min 30s	0970min 0s	09700:00:00	set_ClassName(String)	Rule violated: Avoid public methods not publicly visible
Low issue on: SqlWrangler.FieldDefinition.get_Name()	0790min 30s	0950min 0s	09500:00:00	get_Name()	Rule violated: Avoid public methods not publicly visible
Low issue on: SqlWrangler .FieldDefinition.set_Name(String)	0780min 30s	0960min 0s	09600:00:00	set_Name(String)	Rule violated: Avoid public methods not publicly visible
Low issue on: SqlWrangler .FieldDefinition.get_DbFieldName()	0870min 30s	0810min 0s	08100:00:00	get_DbFieldName()	Rule violated: Avoid public methods not publicly visible
Low issue on: SqlWrangler .FieldDefinition.set_DbFieldName(String)	0960min 30s	0820min 0s	08200:00:00	set_DbFieldName(String)	Rule violated: Avoid public methods not publicly visible
Low issue on: SqlWrangler .FieldDefinition.get_Length()	0950min 30s	0800min 0s	08000:00:00	get_Length()	Rule violated: Avoid public methods not publicly visible
Low issue on: SqlWrangler .FieldDefinition.set_Length(Int32)	0910min 30s	0780min 0s	07800:00:00	set_Length(Int32)	Rule violated: Avoid public methods not publicly visible
Low issue on: SqlWrangler .FieldDefinition.get_AllowsNull()	0920min 30s	0790min 0s	07900:00:00	get_AllowsNull()	Rule violated: Avoid public methods not publicly visible
Low issue on: SqlWrangler .FieldDefinition.set_AllowsNull(Boolean)	0930min 30s	0830min 0s	08300:00:00	set_AllowsNull(Boolean)	Rule violated: Avoid public methods not publicly visible
Low issue on: SqlWrangler.FieldDefinition.get_Type()	0970min 30s	0870min 0s	08700:00:00	get_Type()	Rule violated: Avoid public methods not publicly visible
Low issue on: SqlWrangler .FieldDefinition.set_Type(String)	0800min 30s	0880min 0s	08800:00:00	set_Type(String)	Rule violated: Avoid public methods not publicly visible
Low issue on: SqlWrangler .FieldDefinition.get_IsShortBool()	0810min 30s	0860min 0s	08600:00:00	get_IsShortBool()	Rule violated: Avoid public methods not publicly visible
Low issue on: SqlWrangler .FieldDefinition.set_IsShortBool(Boolean )	0820min 30s	0840min 0s	08400:00:00	set_IsShortBool(Boolean)	Rule violated: Avoid public methods not publicly visible
Low issue on: SqlWrangler.Services .ScintillaStyler.StyleElement(Scintilla)	0830min 30s	0850min 0s	08500:00:00	StyleElement(Scintilla)	Rule violated: Avoid public methods not publicly visible

Statistics

Stat	Debt	Annual Interest	Breaking Point	CodeElement
Sum:	2d 2h	1d 6h	42 343d	-
Average:	10min	8min	407d	-
Minimum:	0min 30s	0min 0s	00:00:00	-
Maximum:	2h 36min	1h 0min	5 186d	-
Standard deviation:	23min	12min	656d	-
Variance:	69d	19d 4h	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

22 rules matched

22 rules	Issues	Debt	Annual Interest	Breaking Point	Category	Full Name
UI layer shouldn't use directly DB types	047 issues	007h 0min	022h 20min	021 095d	Project Rules \ Architecture	Rule
UI layer shouldn't use directly DAL layer	065 issues	012h 52min	031h 40min	05627d	Project Rules \ Architecture	Rule
Avoid namespaces dependency cycles	141 issue	022h 0min	0920min	012 190d	Project Rules \ Architecture	Rule
Avoid types with too many methods	151 issue	031h 15min	155min	005 186d	Project Rules \ Code Smells	Rule
Avoid types with poor cohesion	074 issues	041h 9min	0624min	031 037d	Project Rules \ Code Smells	Rule
Avoid namespaces mutually dependent	132 issues	0550min	041h 23min	12219d	Project Rules \ Architecture	Rule
Methods name should begin with an Upper character	0116 issues	0648min	0532min	07547d	Project Rules \ Naming Conventions	Rule
Avoid methods potentially poorly commented	0213 issues	0733min	012h 58min	1669d	Project Rules \ Code Smells	Rule
Fields should be marked as ReadOnly when possible	056 issues	0830min	1212min	04912d	Project Rules \ Immutability	Rule
Avoid adding instance fields to a type that already had many instance fields	211 issue	1020min	0720min	10354d	Project Rules \ Code Smells Regression	Rule
Do not raise too general exception types	161 issue	0920min	0820min	09365d	Project Rules \ .NET Framework Usage \ System	Rule
From now, all methods added should respect basic quality principles	083 issues	1115min	003h 0min	1730d	Project Rules \ Code Smells Regression	Rule
Methods should be declared static if possible	039 issues	1211min	1118min	11223d	Project Rules \ Object Oriented Design	Rule
Avoid public methods not publicly visible	0020 issues	1310min	180min 0s	1800:00:00	Project Rules \ Visibility	Rule
Avoid defining multiple types in a source file	113 issues	149min	200min 0s	2100:00:00	Project Rules \ Source Files Organization	Rule
Float and Date Parsing must be culture aware	171 issue	158min	165min	06584d	Project Rules \ .NET Framework Usage \ System.Globalization	Rule
Don't use obsolete types, methods or fields	191 issue	165min	1020min	1491d	Project Rules \ Design	Rule
A stateless class or structure might be turned into a static type	122 issues	174min 0s	190min 0s	2000:00:00	Project Rules \ Object Oriented Design	Rule
Types that could be declared as private, nested in a parent type	181 issue	193min 0s	210min 0s	1900:00:00	Project Rules \ Visibility	Rule
Avoid methods with name too long	201 issue	183min 0s	172min 0s	08547d	Project Rules \ Naming Conventions	Rule
Class with no descendant should be sealed if possible	103 issues	211min 30s	146min	1591d	Project Rules \ Object Oriented Design	Rule
Methods that could have a lower visibility	093 issues	201min 30s	136min	1391d	Project Rules \ Visibility	Rule

Statistics

Stat	Issues	Debt	Annual Interest	Breaking Point	Category
Sum:	104	2d 2h	1d 6h	14 263d	-
Average:	4.73	51min	39min	648d	-
Minimum:	1	1min 30s	0min 0s	00:00:00	-
Maximum:	20	7h 0min	3h 0min	5 186d	-
Standard deviation:	5.19	1h 30min	56min	1 113d	-
Variance:	26.93	1 029d	398d	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

13 rules matched

13 rules	IssuesAdded	IssuesFixed	Issues	Debt	DebtDiff	Category	Full Name
Avoid namespaces dependency cycles	061 issue	05no issue	101 issue	012h 0min	002h 0min	Project Rules \ Architecture	Rule
Avoid namespaces mutually dependent	012 issues	06no issue	072 issues	0350min	0150min	Project Rules \ Architecture	Rule
Avoid adding instance fields to a type that already had many instance fields	071 issue	04no issue	121 issue	0520min	0220min	Project Rules \ Code Smells Regression	Rule
From now, all methods added should respect basic quality principles	003 issues	02no issue	053 issues	0615min	0315min	Project Rules \ Code Smells Regression	Rule
UI layer shouldn't use directly DB types	051 issue	03no issue	037 issues	007h 0min	048min	Project Rules \ Architecture	Rule
Don't use obsolete types, methods or fields	111 issue	07no issue	111 issue	095min	055min	Project Rules \ Design	Rule
A stateless class or structure might be turned into a static type	032 issues	11no issue	082 issues	104min 0s	064min 0s	Project Rules \ Object Oriented Design	Rule
Avoid types with poor cohesion	101 issue	12no issue	044 issues	021h 9min	072min 42s	Project Rules \ Code Smells	Rule
Class with no descendant should be sealed if possible	022 issues	10no issue	063 issues	121min 30s	101min 0s	Project Rules \ Object Oriented Design	Rule
Methods should be declared static if possible	081 issue	08no issue	029 issues	0711min	091min 0s	Project Rules \ Object Oriented Design	Rule
Avoid public methods not publicly visible	042 issues	09no issue	0020 issues	0810min	081min 0s	Project Rules \ Visibility	Rule
Avoid methods with name too long	091 issue	001 issue	091 issue	113min 0s	110min 0s	Project Rules \ Naming Conventions	Rule
Avoid methods potentially poorly commented	121 issue	011 issue	0113 issues	0433min	12-(1min 30s)	Project Rules \ Code Smells	Rule

Statistics

Stat	IssuesAdded	IssuesFixed	Issues	Debt	DebtDiff	Category
Sum:	19	2	67	1d 4h	3h 46min	-
Average:	1.46	0.15	5.15	58min	17min	-
Minimum:	1	0	1	1min 30s	-(1min 30s)	-
Maximum:	3	1	20	7h 0min	2h 0min	-
Standard deviation:	0.63	0.36	5.54	1h 49min	32min	-
Variance:	0.4	0.13	30.75	1 494d	131d	-

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.

77 code elements matched

77 code elements	Issues	Debt	Annual Interest	Breaking Point	Full Name
SqlClient	007 issues	004h 56min	002h 0min	09897d	SqlWrangler.SqlClient
FrmLogin	053 issues	013h 14min	0542min	011 672d	SqlWrangler.FrmLogin
SqlWrangler	321 issue	022h 0min	1120min	002 190d	SqlWrangler
FrmMain	063 issues	031h 14min	0446min	13586d	SqlWrangler.FrmMain
DataRowComparerViewer	023 issues	041h 8min	0922min	021 128d	SqlWrangler.DataRowComparerViewer
FrmExportSql	142 issues	0556min	0740min	31511d	SqlWrangler.FrmExportSql
Wizard	152 issues	0639min	1220min	10711d	SqlWrangler.Wizard
SnippetMenuBuilder	043 issues	0738min	1022min	12638d	SqlWrangler.Services.SnippetMenuBuilder
GenerateInsertSql(DataRow)	033 issues	0830min	0835min	35308d	SqliteTools.Table.GenerateInsertSql (DataRow)
.ctor(List<TextSnippet>)	331 issue	0930min	0641min	37262d	SqlWrangler.SqlClient..ctor(List <TextSnippet>)
Program	281 issue	1020min	1420min	34365d	SqlWrangler.Program
BuildSnippetMenu(List<TextSnippet> ,ToolStripMenuItem,Keys,Scintilla ,DataGridView)	013 issues	118min	011h 16min	5940d	SqlWrangler.Services.SnippetMenuBuilder .BuildSnippetMenu(List<TextSnippet> ,ToolStripMenuItem,Keys,Scintilla ,DataGridView)
CreateNhSessionFactory(String)	132 issues	125min	2312min	47166d	SqlWrangler.FrmLogin .CreateNhSessionFactory(String)
.cctor()	291 issue	195min	1320min	4891d	SqliteTools.SqliteTypes..cctor()
components	301 issue	185min	352min 0s	05912d	SqlWrangler.DataRowComparerViewer .components
components	341 issue	215min	362min 0s	04912d	SqlWrangler.FrmExportSql.components
components	381 issue	205min	342min 0s	08912d	SqlWrangler.FrmLogin.components
components	391 issue	175min	322min 0s	03912d	SqlWrangler.FrmMain.components
components	401 issue	145min	332min 0s	06912d	SqlWrangler.FrmNameInput.components
ColorToolStripMenuItem_Click(Object ,EventArgs)	351 issue	135min	021h 0min	6030d	SqlWrangler.SqlClient .ColorToolStripMenuItem_Click(Object ,EventArgs)
components	361 issue	165min	372min 0s	07912d	SqlWrangler.SqlClient.components
InsertFields(Scintilla,DataGridView)	371 issue	155min	031h 0min	6130d	SqlWrangler.Services.SnippetMenuBuilder .InsertFields(Scintilla,DataGridView)
FieldDefinition	092 issues	223min 30s	412min 0s	11638d	SqlWrangler.FieldDefinition
ClearAllCheckFieldsToolStripMenuItem_Cli ck(Object,EventArgs)	191 issue	333min 0s	422min 0s	25547d	SqlWrangler.DataRowComparerViewer .ClearAllCheckFieldsToolStripMenuItem_Cl ick(Object,EventArgs)
btnCancel_Click(Object,EventArgs)	201 issue	323min 0s	402min 0s	26547d	SqlWrangler.FrmExportSql.btnCancel_Click (Object,EventArgs)
btnOk_Click(Object,EventArgs)	171 issue	313min 0s	382min 0s	23547d	SqlWrangler.FrmExportSql.btnOk_Click (Object,EventArgs)
button1_Click(Object,EventArgs)	251 issue	343min 0s	392min 0s	24547d	SqlWrangler.FrmLogin.button1_Click (Object,EventArgs)
button2_Click(Object,EventArgs)	261 issue	373min 0s	272min 0s	29547d	SqlWrangler.FrmLogin.button2_Click (Object,EventArgs)
frmLogin_Load(Object,EventArgs)	221 issue	363min 0s	282min 0s	30547d	SqlWrangler.FrmLogin.frmLogin_Load (Object,EventArgs)
comboBox1_SelectedIndexChanged(Object ,EventArgs)	231 issue	353min 0s	262min 0s	27547d	SqlWrangler.FrmLogin .comboBox1_SelectedIndexChanged(Object ,EventArgs)
txtPassword_KeyDown(Object,KeyEventArgs)	181 issue	303min 0s	302min 0s	28547d	SqlWrangler.FrmLogin.txtPassword_KeyDown (Object,KeyEventArgs)
button3_Click(Object,EventArgs)	241 issue	253min 0s	292min 0s	22547d	SqlWrangler.FrmLogin.button3_Click (Object,EventArgs)
newToolStripMenuItem_Click_1(Object ,EventArgs)	271 issue	243min 0s	312min 0s	16547d	SqlWrangler.FrmMain .newToolStripMenuItem_Click_1(Object ,EventArgs)
frmMain_FormClosed(Object ,FormClosedEventArgs)	161 issue	233min 0s	432min 0s	17547d	SqlWrangler.FrmMain.frmMain_FormClosed (Object,FormClosedEventArgs)
frmMain_DragDrop(Object,DragEventArgs)	211 issue	263min 0s	552min 0s	14547d	SqlWrangler.FrmMain.frmMain_DragDrop (Object,DragEventArgs)
helpToolStripMenuItem_Click(Object ,EventArgs)	411 issue	293min 0s	562min 0s	15547d	SqlWrangler.FrmMain .helpToolStripMenuItem_Click(Object ,EventArgs)
aboutToolStripMenuItem_Click(Object ,EventArgs)	651 issue	283min 0s	532min 0s	20547d	SqlWrangler.FrmMain .aboutToolStripMenuItem_Click(Object ,EventArgs)
button1_Click(Object,EventArgs)	641 issue	273min 0s	542min 0s	21547d	SqlWrangler.FrmNameInput.button1_Click (Object,EventArgs)
button2_Click(Object,EventArgs)	311 issue	383min 0s	572min 0s	18547d	SqlWrangler.FrmNameInput.button2_Click (Object,EventArgs)
txtName_KeyPress(Object ,KeyPressEventArgs)	661 issue	393min 0s	602min 0s	19547d	SqlWrangler.FrmNameInput .txtName_KeyPress(Object ,KeyPressEventArgs)
WriteCsWizard(DataTable,StreamWriter ,String,String)	611 issue	402min 48s	1616min	5463d	SqlWrangler.Wizard.WriteCsWizard (DataTable,StreamWriter,String,String)
WriteMaterializer(DataTable,StreamWriter ,IEnumerable<FieldDefinition>)	601 issue	422min 36s	2113min	5170d	SqlWrangler.Wizard.WriteMaterializer (DataTable,StreamWriter,IEnumerable <FieldDefinition>)
GetFields(DataTableReader)	631 issue	412min 36s	2013min	5270d	SqlWrangler.Wizard.GetFields (DataTableReader)
Compare(DataRow,DataTable,String)	621 issue	452min 30s	2411min	4981d	SqlWrangler.DataRowComparerViewer .Compare(DataRow,DataTable,String)
WriteModelClass(DataTable,StreamWriter ,IEnumerable<FieldDefinition> ,MapperAttributeType)	681 issue	462min 30s	1916min	5557d	SqlWrangler.Wizard.WriteModelClass (DataTable,StreamWriter,IEnumerable <FieldDefinition>,MapperAttributeType)
GetFieldName(String)	741 issue	432min 30s	612min 0s	33456d	SqlWrangler.Wizard.GetFieldName(String)
ScintillaStyler	102 issues	442min 30s	582min 0s	32456d	SqlWrangler.Services.ScintillaStyler
ToggleMenuItems()	731 issue	492min 24s	1716min	5654d	SqlWrangler.DataRowComparerViewer .ToggleMenuItems()
SaveExternalFile(Boolean)	761 issue	482min 24s	1516min	5754d	SqlWrangler.SqlClient.SaveExternalFile (Boolean)
WriteMappings(DataTable,StreamWriter ,IEnumerable<FieldDefinition>)	751 issue	472min 24s	2213min	5365d	SqlWrangler.Wizard.WriteMappings (DataTable,StreamWriter,IEnumerable <FieldDefinition>)
WizardToolStripMenuItem1_Click(Object ,EventArgs)	701 issue	502min 12s	1816min	5850d	SqlWrangler.SqlClient .WizardToolStripMenuItem1_Click(Object ,EventArgs)
GetSnippets()	691 issue	512min 0s	2510min	5071d	SqlWrangler.FrmMain.GetSnippets()
StyleElement(Scintilla)	122 issues	521min 30s	592min 0s	36273d	SqlWrangler.Services.ScintillaStyler .StyleElement(Scintilla)
IsString(Type)	721 issue	591min 0s	462min 0s	46182d	SqliteTools.Table.IsString(Type)
IsDateTime(Type)	711 issue	581min 0s	472min 0s	40182d	SqliteTools.Table.IsDateTime(Type)
ExportSql(FileInfo,DataTable,String ,String,Boolean,Boolean)	591 issue	611min 0s	442min 0s	39182d	SqlWrangler.FrmExportSql.ExportSql (FileInfo,DataTable,String,String ,Boolean,Boolean)
GetExcelConnectionString(String)	471 issue	601min 0s	452min 0s	38182d	SqlWrangler.FrmLogin .GetExcelConnectionString(String)
get_TableName()	082 issues	571min 0s	482min 0s	43182d	SqlWrangler.FieldDefinition .get_TableName()
get_TableSchema()	112 issues	541min 0s	512min 0s	44182d	SqlWrangler.FieldDefinition .get_TableSchema()
get_ClassName()	072 issues	531min 0s	522min 0s	45182d	SqlWrangler.FieldDefinition .get_ClassName()
WriteLinq2DbField(StreamWriter ,FieldDefinition,String)	461 issue	561min 0s	492min 0s	41182d	SqlWrangler.Wizard.WriteLinq2DbField (StreamWriter,FieldDefinition,String)
WriteEntityFrameworkField(StreamWriter ,FieldDefinition,String)	491 issue	551min 0s	502min 0s	42182d	SqlWrangler.Wizard .WriteEntityFrameworkField(StreamWriter ,FieldDefinition,String)
set_TableName(String)	481 issue	720min 30s	720min 0s	7100:00:00	SqlWrangler.FieldDefinition .set_TableName(String)
set_TableSchema(String)	431 issue	710min 30s	710min 0s	7200:00:00	SqlWrangler.FieldDefinition .set_TableSchema(String)
set_ClassName(String)	421 issue	700min 30s	700min 0s	6900:00:00	SqlWrangler.FieldDefinition .set_ClassName(String)
get_Name()	451 issue	730min 30s	730min 0s	7000:00:00	SqlWrangler.FieldDefinition.get_Name()
set_Name(String)	441 issue	760min 30s	760min 0s	7500:00:00	SqlWrangler.FieldDefinition.set_Name (String)
get_DbFieldName()	501 issue	750min 30s	750min 0s	7600:00:00	SqlWrangler.FieldDefinition .get_DbFieldName()
set_DbFieldName(String)	561 issue	740min 30s	740min 0s	7300:00:00	SqlWrangler.FieldDefinition .set_DbFieldName(String)
get_Length()	551 issue	690min 30s	690min 0s	7400:00:00	SqlWrangler.FieldDefinition.get_Length()
set_Length(Int32)	581 issue	640min 30s	640min 0s	6400:00:00	SqlWrangler.FieldDefinition.set_Length (Int32)
get_AllowsNull()	571 issue	630min 30s	630min 0s	6600:00:00	SqlWrangler.FieldDefinition .get_AllowsNull()
set_AllowsNull(Boolean)	521 issue	620min 30s	620min 0s	6800:00:00	SqlWrangler.FieldDefinition .set_AllowsNull(Boolean)
get_Type()	511 issue	650min 30s	650min 0s	6700:00:00	SqlWrangler.FieldDefinition.get_Type()
set_Type(String)	541 issue	680min 30s	680min 0s	6300:00:00	SqlWrangler.FieldDefinition.set_Type (String)
get_IsShortBool()	531 issue	670min 30s	670min 0s	6200:00:00	SqlWrangler.FieldDefinition .get_IsShortBool()
set_IsShortBool(Boolean)	671 issue	660min 30s	660min 0s	6500:00:00	SqlWrangler.FieldDefinition .set_IsShortBool(Boolean)

Statistics

Stat	Issues	Debt	Annual Interest	Breaking Point
Sum:	104	2d 2h	1d 6h	28 522d
Average:	1.35	14min	11min	370d
Minimum:	1	0min 30s	0min 0s	00:00:00
Maximum:	7	4h 56min	2h 0min	2 190d
Standard deviation:	0.88	43min	20min	399d
Variance:	0.77	231d	50d	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.

12 code containers matched

12 code containers	IssuesAdded	IssuesFixed	Issues	Debt	DebtDiff	Full Name
SqlWrangler	051 issue	04no issue	071 issue	012h 0min	002h 0min	SqlWrangler
SnippetMenuBuilder	003 issues	05no issue	033 issues	0338min	0138min	SqlWrangler.Services.SnippetMenuBuilder
.ctor(List<TextSnippet>)	061 issue	03no issue	061 issue	0430min	0230min	SqlWrangler.SqlClient..ctor(List <TextSnippet>)
BuildSnippetMenu(List<TextSnippet> ,ToolStripMenuItem,Keys,Scintilla ,DataGridView)	013 issues	01no issue	023 issues	058min	038min	SqlWrangler.Services.SnippetMenuBuilder .BuildSnippetMenu(List<TextSnippet> ,ToolStripMenuItem,Keys,Scintilla ,DataGridView)
.cctor()	071 issue	02no issue	111 issue	065min	055min	SqliteTools.SqliteTypes..cctor()
DataRowComparerViewer	101 issue	06no issue	013 issues	021h 8min	045min	SqlWrangler.DataRowComparerViewer
ColorToolStripMenuItem_Click(Object ,EventArgs)	111 issue	10no issue	091 issue	075min	075min	SqlWrangler.SqlClient .ColorToolStripMenuItem_Click(Object ,EventArgs)
InsertFields(Scintilla,DataGridView)	081 issue	11no issue	081 issue	085min	065min	SqlWrangler.Services.SnippetMenuBuilder .InsertFields(Scintilla,DataGridView)
ClearAllCheckFieldsToolStripMenuItem_Cli ck(Object,EventArgs)	091 issue	09no issue	101 issue	093min 0s	083min 0s	SqlWrangler.DataRowComparerViewer .ClearAllCheckFieldsToolStripMenuItem_Cl ick(Object,EventArgs)
ScintillaStyler	042 issues	07no issue	052 issues	102min 30s	092min 30s	SqlWrangler.Services.ScintillaStyler
StyleElement(Scintilla)	032 issues	08no issue	042 issues	111min 30s	101min 30s	SqlWrangler.Services.ScintillaStyler .StyleElement(Scintilla)
SqlClient	022 issues	001 issue	007 issues	004h 56min	11-(1h 1min)	SqlWrangler.SqlClient

Statistics

Stat	IssuesAdded	IssuesFixed	Issues	Debt	DebtDiff
Sum:	19	1	26	1d 1h	2h 42min
Average:	1.58	0.083	2.17	48min	13min
Minimum:	1	0	1	1min 30s	-(1h 1min)
Maximum:	3	1	7	4h 56min	2h 0min
Standard deviation:	0.76	0.28	1.67	1h 22min	39min
Variance:	0.58	0.076	2.81	847d	192d

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.

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.

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.

No type matched

Rule Violated: Class with no descendant should be sealed if possible

• 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.

3 types matched

Formatting: bold means added, underlined means code was changed, ~~strike-bold~~ means removed (since baseline)

3 types	# lines of code (LOC)	Debt	Severity	Full Name
SnippetMenuBuilder	044	00min 30s	0Medium	SqlWrangler.Services.SnippetMenuBuilder
FieldDefinition	118	10min 30s	1Medium	SqlWrangler.FieldDefinition
ScintillaStyler	217	20min 30s	2Medium	SqlWrangler.Services.ScintillaStyler

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.

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.

No method matched

Rule Violated: A stateless class or structure might be turned into a static type

2 types matched

Formatting: bold means added, underlined means code was changed, ~~strike-bold~~ means removed (since baseline)

2 types	methodsUsingMe	Debt	Severity	Full Name
ScintillaStyler	01 method	02min 0s	0Low	SqlWrangler.Services.ScintillaStyler
SnippetMenuBuilder	11 method	12min 0s	1Low	SqlWrangler.Services.SnippetMenuBuilder

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.

No type matched

Rule Violated: Methods should be declared static if possible

9 methods matched

Formatting: bold means added, underlined means code was changed, ~~strike-bold~~ means removed (since baseline)

9 methods	staticFieldsUsed	methodsCallingMe	Debt	Severity	Full Name
IsString(Type)	2no field	41 method	41min 0s	2Medium	SqliteTools.Table.IsString(Type)
IsDateTime(Type)	3no field	21 method	21min 0s	3Medium	SqliteTools.Table.IsDateTime(Type)
ExportSql(FileInfo,DataTable,String ,String,Boolean,Boolean)	0no field	31 method	31min 0s	0Medium	SqlWrangler.FrmExportSql.ExportSql (FileInfo,DataTable,String,String ,Boolean,Boolean)
CreateNhSessionFactory(String)	1no field	12 methods	11min 30s	1Medium	SqlWrangler.FrmLogin .CreateNhSessionFactory(String)
GetExcelConnectionString(String)	4no field	71 method	71min 0s	4Medium	SqlWrangler.FrmLogin .GetExcelConnectionString(String)
WriteLinq2DbField(StreamWriter ,FieldDefinition,String)	7no field	81 method	81min 0s	7Medium	SqlWrangler.Wizard.WriteLinq2DbField (StreamWriter,FieldDefinition,String)
WriteEntityFrameworkField(StreamWriter ,FieldDefinition,String)	8no field	51 method	51min 0s	8Medium	SqlWrangler.Wizard .WriteEntityFrameworkField(StreamWriter ,FieldDefinition,String)
GetFieldName(String)	5no field	04 methods	02min 30s	5Medium	SqlWrangler.Wizard.GetFieldName(String)
StyleElement(Scintilla)	6no field	61 method	61min 0s	6Medium	SqlWrangler.Services.ScintillaStyler .StyleElement(Scintilla)

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.

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.

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.

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.

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.

No method matched

API Breaking Changes

3 validated Rule(s)

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.

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.

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.

No type matched

Code Coverage

10 validated Rule(s)

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.

No method matched

To run this query import some Code Coverage Data..

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.

No method matched

To run this query import some Code Coverage Data..

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.

No method matched

To run this query import some Code Coverage Data..

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.

No code element parent matched

To run this query import some Code Coverage Data..

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.

No type matched

To run this query import some Code Coverage Data..

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.

No namespace matched

To run this query import some Code Coverage Data..

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.

No method matched

To run this query import some Code Coverage Data..

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.

No method matched

To run this query import some Code Coverage Data..

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.

No type matched

To run this query import some Code Coverage Data..

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.

No method matched

To run this query import some Code Coverage Data..

Dead Code

4 validated Rule(s)

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.

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.

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.

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.

No member matched

Code Diff Summary

» Baseline for comparison : Compare with analysis result obtained on 2019 July - 21 Sunday 06:51 (which is the analysis result with date closest to 30 days ago)

25 Queries

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.

2 assemblies matched

2 assemblies	# lines of code (LOC)	oldNbLinesOfCode	delta	Full Name
SqliteTools	175	176	0-1	SqliteTools
SqlWrangler	01 448	01 459	1-11	SqlWrangler

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.

1 namespace matched

1 namespace	# lines of code (LOC)	Full Name
SqlWrangler.Services	061	SqlWrangler.Services

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.

2 namespaces matched

2 namespaces	# lines of code (LOC)	oldNbLinesOfCode	delta	Full Name
SqliteTools	175	176	0-1	SqliteTools
SqlWrangler	01 338	01 410	1-72	SqlWrangler

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.

1 type matched

1 type	# lines of code (LOC)	Full Name
~~DataUpdateMode~~	0N/A	SqliteTools.DataUpdateMode

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

7 types matched

7 types	# lines of code (LOC)	oldNbLinesOfCode	delta	Full Name
Table	674	675	3-1	SqliteTools.Table
DataRowComparerViewer	1227	1233	5-6	SqlWrangler.DataRowComparerViewer
FrmExportSql	4129	4130	2-1	SqlWrangler.FrmExportSql
FrmLogin	2205	2205	10	SqlWrangler.FrmLogin
FrmMain	5110	5110	00	SqlWrangler.FrmMain
SqlClient	0407	0469	6-62	SqlWrangler.SqlClient
Wizard	3169	3172	4-3	SqlWrangler.Wizard

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

1 type matched

1 type	typesChangedUsed	Full Name
Program	01 type	SqlWrangler.Program

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

1 type matched

1 type	depthOfUsingTypesChanged	typesChangedDirectlyUsed	Full Name
Program	01	01 type	SqlWrangler.Program

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.

19 methods 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.

20 methods 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

25 methods matched

25 methods	# lines of code (LOC)	oldNbLinesOfCode	delta	Full Name
get_ActualName()	223	223	130	SqliteTools.Table.get_ActualName()
.ctor(String,String)	213	215	21-2	SqliteTools.Table..ctor(String,String)
GenerateCreateTableSql(DataTable)	0228	0428	050	SqliteTools.Table.GenerateCreateTableSql (DataTable)
GenerateInsertSql(DataRow)	0525	0725	070	SqliteTools.Table.GenerateInsertSql (DataRow)
.ctor(DataTable,String)	1414	1216	23-2	SqlWrangler.DataRowComparerViewer..ctor (DataTable,String)
FillGrid()	1117	1117	060	SqlWrangler.DataRowComparerViewer .FillGrid()
DisplayDetailForRow(Int32)	1314	1415	19-1	SqlWrangler.DataRowComparerViewer .DisplayDetailForRow(Int32)
ToggleMenuItems()	0724	0236	24-12	SqlWrangler.DataRowComparerViewer .ToggleMenuItems()
InitializeComponent()	0184	0184	090	SqlWrangler.DataRowComparerViewer .InitializeComponent()
.ctor(DataTable)	1613	1513	080	SqlWrangler.FrmExportSql..ctor(DataTable )
btnOk_Click(Object,EventArgs)	0919	0919	020	SqlWrangler.FrmExportSql.btnOk_Click (Object,EventArgs)
ExportSql(FileInfo,DataTable,String ,String,Boolean,Boolean)	1017	1017	010	SqlWrangler.FrmExportSql.ExportSql (FileInfo,DataTable,String,String ,Boolean,Boolean)
button1_Click(Object,EventArgs)	1216	1316	040	SqlWrangler.FrmLogin.button1_Click (Object,EventArgs)
button3_Click(Object,EventArgs)	1712	1712	030	SqlWrangler.FrmLogin.button3_Click (Object,EventArgs)
.ctor()	1810	1810	100	SqlWrangler.FrmMain..ctor()
NewSqlForm()	232	232	150	SqlWrangler.FrmMain.NewSqlForm()
PersistSnippets()	206	206	160	SqlWrangler.FrmMain.PersistSnippets()
GetSnippets()	0822	0822	170	SqlWrangler.FrmMain.GetSnippets()
aboutToolStripMenuItem_Click(Object ,EventArgs)	241	241	140	SqlWrangler.FrmMain .aboutToolStripMenuItem_Click(Object ,EventArgs)
.ctor(List<TextSnippet>)	1514	1612	002	SqlWrangler.SqlClient..ctor(List <TextSnippet>)
Uncheck(Object)	198	199	20-1	SqlWrangler.SqlClient.Uncheck(Object)
InitializeComponent()	00220	00220	120	SqlWrangler.SqlClient .InitializeComponent()
WriteModelClass(DataTable,StreamWriter ,IEnumerable<FieldDefinition> ,MapperAttributeType)	0625	0627	22-2	SqlWrangler.Wizard.WriteModelClass (DataTable,StreamWriter,IEnumerable <FieldDefinition>,MapperAttributeType)
WriteMaterializer(DataTable,StreamWriter ,IEnumerable<FieldDefinition>)	0427	0527	110	SqlWrangler.Wizard.WriteMaterializer (DataTable,StreamWriter,IEnumerable <FieldDefinition>)
GetFields(DataTableReader)	0327	0328	18-1	SqlWrangler.Wizard.GetFields (DataTableReader)

Code Query: Methods directly calling one or several methods changed

5 methods matched

5 methods	methodsChangedCalled	Full Name
CreateSql(DataTable)	21 method	SqliteTools.Table.CreateSql(DataTable)
newToolStripMenuItem_Click_1(Object ,EventArgs)	11 method	SqlWrangler.FrmMain .newToolStripMenuItem_Click_1(Object ,EventArgs)
frmMain_FormClosed(Object ,FormClosedEventArgs)	41 method	SqlWrangler.FrmMain.frmMain_FormClosed (Object,FormClosedEventArgs)
ProcessCmdKey(Message&,Keys)	31 method	SqlWrangler.FrmMain.ProcessCmdKey (Message&,Keys)
WriteCsWizard(DataTable,StreamWriter ,String,String)	03 methods	SqlWrangler.Wizard.WriteCsWizard (DataTable,StreamWriter,String,String)

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

8 methods matched

8 methods	depthOfUsingMethodsChanged	methodsChangedDirectlyUsed	Full Name
CreateSql(DataTable)	41	41 method	SqliteTools.Table.CreateSql(DataTable)
newToolStripMenuItem_Click_1(Object ,EventArgs)	31	21 method	SqlWrangler.FrmMain .newToolStripMenuItem_Click_1(Object ,EventArgs)
frmMain_FormClosed(Object ,FormClosedEventArgs)	51	31 method	SqlWrangler.FrmMain.frmMain_FormClosed (Object,FormClosedEventArgs)
ProcessCmdKey(Message&,Keys)	71	11 method	SqlWrangler.FrmMain.ProcessCmdKey (Message&,Keys)
WriteCsWizard(DataTable,StreamWriter ,String,String)	61	03 methods	SqlWrangler.Wizard.WriteCsWizard (DataTable,StreamWriter,String,String)
.ctor()	12	6no method	SqlWrangler.FrmLogin..ctor()
WizardToolStripMenuItem1_Click(Object ,EventArgs)	22	7no method	SqlWrangler.SqlClient .WizardToolStripMenuItem1_Click(Object ,EventArgs)
Main()	03	5no method	SqlWrangler.Program.Main()

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.

4 fields matched

4 fields	Full Name
SqlLiteTypes	SqliteTools.Table.SqlLiteTypes
_snippets	SqlWrangler.FrmMain._snippets
_styler	SqlWrangler.SqlClient._styler
_menuBuilder	SqlWrangler.SqlClient._menuBuilder

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.

1 field matched

1 field	Full Name
~~Snippets~~	SqlWrangler.FrmMain.Snippets

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.

2 types matched

2 types	Methods	Fields	TypesUsingMe	Full Name
ObsoleteAttribute	0no method	0no field	01 type	System.ObsoleteAttribute
SuppressMessageAttribute	1no method	1no field	11 type	System.Diagnostics.CodeAnalysis .SuppressMessageAttribute

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.

2 methods matched

2 methods	MethodsCallingMe	Full Name
Concat(String,String,String,String)	12 methods	System.String.Concat(String,String ,String,String)
Concat(String[])	03 methods	System.String.Concat(String[])

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.

2 methods matched

2 methods	MethodsThatCalledMe	Full Name
Format(String,Object,Object,Object)	03 methods	System.String.Format(String,Object ,Object,Object)
Format(String,Object[])	11 method	System.String.Format(String,Object[])

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
SqliteTools v1.0.0.0	mscorlib v4.0.0.0 ; System.Data v4.0.0.0 ; System.Core v4.0.0.0 ;	SqlWrangler v1.0.0.0 ;
SqlWrangler v1.0.0.0	mscorlib v4.0.0.0 ; System.Data v4.0.0.0 ; System.Drawing v4.0.0.0 ; System v4.0.0.0 ; System.Windows.Forms v4.0.0.0 ; System.Core v4.0.0.0 ; System.Data.DataSetExtensions v4.0.0.0 ; SqliteTools v1.0.0.0 ; NHibernate v4.0.0.4000 ; System.Configuration v4.0.0.0 ; System.Xml v4.0.0.0 ; ScintillaNET v3.5.6.0 ; Newtonsoft.Json v9.0.0.0 ; Oracle.ManagedDataAccess v4.121.2.0 ;	-

Assemblies Build Order

SqliteTools
SqlWrangler

Assemblies Build Order

SqliteTools
SqlWrangler

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.

	Message
	Begin full analysis with NDepend v2019.2.5
	Compare with analysis result obtained on 2019 July - 21 Sunday 06:51 (which is the analysis result with date closest to 30 days ago)
	.NET Assemblies resolved from the Visual Studio solution file {D:\src\SqlWrangler\SqlWrangler\SqlWrangler.sln} D:\src\SqlWrangler\SqlWrangler\SqlWrangler\bin\Debug\SqlWrangler.exe D:\src\SqlWrangler\SqlWrangler\SqliteTools\bin\Debug\SqliteTools.dll
	No .NET Assembly filtered out from the Visual Studio solution file {D:\src\SqlWrangler\SqlWrangler\SqlWrangler.sln}.
	Concurrent mode
	.NET Assemblies loaded from {C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319} System.Core.dll v4.0.0.0 System.Data.DataSetExtensions.dll v4.0.0.0 System.Xml.dll v4.0.0.0 System.Configuration.dll v4.0.0.0 System.Drawing.dll v4.0.0.0 System.dll v4.0.0.0 System.Data.dll v4.0.0.0 System.Windows.Forms.dll v4.0.0.0 mscorlib.dll v4.0.0.0
	23 source files parsed ; all source files found ; all source files 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.
	In the analyzed code base, SuppressMessageAttribute is used to suppress issues emitted by other tools. Since NDepend v2018.2 SuppressMessageAttribute can be used to suppress NDepend issues.
	Execute queries and rules.
	2 quality gates warn: - 'New Debt since Baseline' value 0.086 man-days greater than warn threshold 0 man-days - 'New Annual Interest since Baseline' value 0.57 man-days greater than warn threshold 0 man-days
	1 quality gate fails: - 'New Blocker / Critical / High Issues' value 9 issues greater than fail threshold 0 issues
	NDepend analysis done. Duration: 00:15
	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:

Definitions of related Code Metrics

Search:

19 methods	# lines of code (LOC)	Full Name
GenerateImportDataSql(DataTable)	047	SqliteTools.Table.GenerateImportDataSql (DataTable)
.cctor()	131	SqliteTools.Table..cctor()
DataGridView1_CellFormatting(Object ,DataGridViewCellFormattingEventArgs)	065	SqlWrangler.DataRowComparerViewer .DataGridView1_CellFormatting(Object ,DataGridViewCellFormattingEventArgs)
DataGridView1_RowHeaderMouseClick(Object ,DataGridViewCellMouseEventArgs)	141	SqlWrangler.DataRowComparerViewer .DataGridView1_RowHeaderMouseClick (Object,DataGridViewCellMouseEventArgs)
SetKeyToolStripMenuItem_Click(Object ,EventArgs)	122	SqlWrangler.DataRowComparerViewer .SetKeyToolStripMenuItem_Click(Object ,EventArgs)
FormatDataGridColumns()	0213	SqlWrangler.DataRowComparerViewer .FormatDataGridColumns()
DataGridView1_ColumnHeaderMouseClick (Object,DataGridViewCellMouseEventArgs)	0016	SqlWrangler.DataRowComparerViewer .DataGridView1_ColumnHeaderMouseClick (Object,DataGridViewCellMouseEventArgs)
SetCheckFieldsToolStripMenuItem_Click (Object,EventArgs)	112	SqlWrangler.DataRowComparerViewer .SetCheckFieldsToolStripMenuItem_Click (Object,EventArgs)
ClearAllCheckFieldsToolStripMenuItem_Cli ck(Object,EventArgs)	075	SqlWrangler.DataRowComparerViewer .ClearAllCheckFieldsToolStripMenuItem_Cl ick(Object,EventArgs)
ExecuteToolStripMenuItem_Click(Object ,EventArgs)	161	SqlWrangler.SqlClient .ExecuteToolStripMenuItem_Click(Object ,EventArgs)
ToCSVToolStripMenuItem_Click(Object ,EventArgs)	037	SqlWrangler.SqlClient .ToCSVToolStripMenuItem_Click(Object ,EventArgs)
TextBox1_KeyUp_1(Object,KeyEventArgs)	104	SqlWrangler.SqlClient.TextBox1_KeyUp_1 (Object,KeyEventArgs)
ToXMLToolStripMenuItem_Click(Object ,EventArgs)	151	SqlWrangler.SqlClient .ToXMLToolStripMenuItem_Click(Object ,EventArgs)
CancelToolStripMenuItem_Click(Object ,EventArgs)	084	SqlWrangler.SqlClient .CancelToolStripMenuItem_Click(Object ,EventArgs)
ToDaveSqlToolStripMenuItem_Click(Object ,EventArgs)	094	SqlWrangler.SqlClient .ToDaveSqlToolStripMenuItem_Click(Object ,EventArgs)
DataGridView1_DataError(Object ,DataGridViewDataErrorEventArgs)	180	SqlWrangler.SqlClient .DataGridView1_DataError(Object ,DataGridViewDataErrorEventArgs)
ToJSONToolStripMenuItem_Click(Object ,EventArgs)	171	SqlWrangler.SqlClient .ToJSONToolStripMenuItem_Click(Object ,EventArgs)
ColorToolStripMenuItem_Click(Object ,EventArgs)	0115	SqlWrangler.SqlClient .ColorToolStripMenuItem_Click(Object ,EventArgs)
CompareRowsToolStripMenuItem_Click (Object,EventArgs)	056	SqlWrangler.SqlClient .CompareRowsToolStripMenuItem_Click (Object,EventArgs)

20 methods	# lines of code (LOC)	Full Name
~~GenerateImportDataSql(DataTable ,DataUpdateMode)~~	067	SqliteTools.Table.GenerateImportDataSql (DataTable,DataUpdateMode)
~~dataGridView1_CellFormatting(Object ,DataGridViewCellFormattingEventArgs)~~	085	SqlWrangler.DataRowComparerViewer .dataGridView1_CellFormatting(Object ,DataGridViewCellFormattingEventArgs)
~~dataGridView1_RowHeaderMouseClick(Object ,DataGridViewCellMouseEventArgs)~~	151	SqlWrangler.DataRowComparerViewer .dataGridView1_RowHeaderMouseClick (Object,DataGridViewCellMouseEventArgs)
~~setKeyToolStripMenuItem_Click(Object ,EventArgs)~~	104	SqlWrangler.DataRowComparerViewer .setKeyToolStripMenuItem_Click(Object ,EventArgs)
~~dataGridView1_ColumnHeaderMouseClick (Object,DataGridViewCellMouseEventArgs)~~	0216	SqlWrangler.DataRowComparerViewer .dataGridView1_ColumnHeaderMouseClick (Object,DataGridViewCellMouseEventArgs)
~~setCheckFieldsToolStripMenuItem_Click (Object,EventArgs)~~	114	SqlWrangler.DataRowComparerViewer .setCheckFieldsToolStripMenuItem_Click (Object,EventArgs)
~~clearAllCheckFieldsToolStripMenuItem_Cli ck(Object,EventArgs)~~	095	SqlWrangler.DataRowComparerViewer .clearAllCheckFieldsToolStripMenuItem_Cl ick(Object,EventArgs)
~~BuildSnippetMenu()~~	0030	SqlWrangler.SqlClient.BuildSnippetMenu()
~~ScintallaStyle()~~	0117	SqlWrangler.SqlClient.ScintallaStyle()
~~executeToolStripMenuItem_Click(Object ,EventArgs)~~	161	SqlWrangler.SqlClient .executeToolStripMenuItem_Click(Object ,EventArgs)
~~toCSVToolStripMenuItem_Click(Object ,EventArgs)~~	057	SqlWrangler.SqlClient .toCSVToolStripMenuItem_Click(Object ,EventArgs)
~~textBox1_KeyUp_1(Object,KeyEventArgs)~~	124	SqlWrangler.SqlClient.textBox1_KeyUp_1 (Object,KeyEventArgs)
~~toXMLToolStripMenuItem_Click(Object ,EventArgs)~~	181	SqlWrangler.SqlClient .toXMLToolStripMenuItem_Click(Object ,EventArgs)
~~cancelToolStripMenuItem_Click(Object ,EventArgs)~~	144	SqlWrangler.SqlClient .cancelToolStripMenuItem_Click(Object ,EventArgs)
~~toDaveSqlToolStripMenuItem_Click(Object ,EventArgs)~~	134	SqlWrangler.SqlClient .toDaveSqlToolStripMenuItem_Click(Object ,EventArgs)
~~dataGridView1_DataError(Object ,DataGridViewDataErrorEventArgs)~~	190	SqlWrangler.SqlClient .dataGridView1_DataError(Object ,DataGridViewDataErrorEventArgs)
~~toJSONToolStripMenuItem_Click(Object ,EventArgs)~~	171	SqlWrangler.SqlClient .toJSONToolStripMenuItem_Click(Object ,EventArgs)
~~colorToolStripMenuItem_Click(Object ,EventArgs)~~	0315	SqlWrangler.SqlClient .colorToolStripMenuItem_Click(Object ,EventArgs)
~~InsertFields()~~	0414	SqlWrangler.SqlClient.InsertFields()
~~compareRowsToolStripMenuItem_Click (Object,EventArgs)~~	077	SqlWrangler.SqlClient .compareRowsToolStripMenuItem_Click (Object,EventArgs)

Diagrams

Application Metrics

Quality Gates summary

Rules summary

Application Statistics

Assemblies Metrics

Types Metrics : Code Quality

Types Metrics : Code Members and Inheritance

Types Metrics : Lack Of Cohesion Of Methods and Association Between Classes

Namespaces Metrics

721Project Rules

721Quality Gates

Scalar Result: N/A %

Scalar Result: N/A %

Scalar Result: N/A %

No issue matched

No issue matched

9 issues matched

Statistics

Scalar Result: 7.12 %

Scalar Result: 0.086 man-days

No namespace matched

Scalar Result: 0.57 man-days

000Rules extracted from Source Code

127211Project Rules

530Code Smells

1 type matched

13 methods matched

4 types matched

720Code Smells Regression

3 methods matched

1 type matched

1130Object Oriented Design

3 types matched

2 types matched

9 methods matched

1110Design

1 method matched

431Architecture

2 members matched

1 namespace matched

7 types matched

5 types matched

730Visibility

3 methods matched

1 type matched

20 methods matched

1010Immutability

6 fields matched

1820Naming Conventions

16 methods matched

1 method matched

510Source Files Organization

3 types matched

2320.NET Framework Usage

910System

1 method matched

010System.Globalization

1 method matched

Quality Gates

7 quality gates matched

Statistics

Scalar Result: N/A %

Scalar Result: N/A %

Scalar Result: N/A %

No issue matched

No issue matched

9 issues matched

Statistics

Scalar Result: 7.12 %

Scalar Result: 0.086 man-days

No namespace matched

Scalar Result: 0.57 man-days

Hot Spots

13 types matched

Statistics

8 types matched

Statistics

104 issues matched

Statistics

721
Project Rules

721
Quality Gates

000
Rules extracted from Source Code

127211
Project Rules

530
Code Smells

720
Code Smells Regression

1130
Object Oriented Design

1110
Design

431
Architecture

730
Visibility

1010
Immutability

1820
Naming Conventions

510
Source Files Organization

2320
.NET Framework Usage

910
System

010
System.Globalization