c#; ef core – My Point of View

.NET Code Analysis with Roslyn Analyzers

NET compiler platform (Roslyn) analyzers inspect your C# or Visual Basic code for style, quality, maintainability, design, and other issues. This inspection or analysis happens during design time in all open files.

Here are the key take aways;

Maintainability index range and meaning

For the thresholds, we decided to break down this 0-100 range 80-20 to keep the noise level low and we only flagged code that was suspicious. We’ve used the following thresholds:

Index value Color Meaning
0-9 Red Low maintainability of code
10-19 Yellow Moderate maintainability of code
20-100 Green Good maintainability of code

Code metrics – Class coupling

“Module cohesion was introduced by Yourdon and Constantine as ‘how tightly bound or related the internal elements of a module are to one another’ YC79. A module has a strong cohesion if it represents exactly one task […], and all its elements contribute to this single task. They describe cohesion as an attribute of design, rather than code, and an attribute that can be used to predict reusability, maintainability, and changeability.”

The Magic Number
As with cyclomatic complexity, there is no limit that fits all organizations. However, S2010 does indicate that a limit of 9 is optimal:

“Therefore, we consider the threshold values […] as the most effective. These threshold values (for a single member) are CBO = 9[…].” (emphasis added)

Code metrics – Cyclomatic complexity

https://learn.microsoft.com/en-us/visualstudio/code-quality/code-metrics-cyclomatic-complexity?view=vs-2022

Cyclomatic complexity is defined as measuring “the amount of decision logic in a source code function” NIST235. Simply put, the more decisions that have to be made in code, the more complex it is.

The Magic Number
As with many metrics in this industry, there’s no exact cyclomatic complexity limit that fits all organizations. However, NIST235 does indicate that a limit of 10 is a good starting point:

“The precise number to use as a limit, however, remains somewhat controversial. The original limit of 10 as proposed by McCabe has significant supporting evidence, but limits as high as 15 have been used successfully as well. Limits over 10 should be reserved for projects that have several operational advantages over typical projects, for example experienced staff, formal design, a modern programming language, structured programming, code walkthroughs, and a comprehensive test plan. In other words, an organization can pick a complexity limit greater than 10, but only if it’s sure it knows what it’s doing and is willing to devote the additional testing effort required by more complex modules.” NIST235

As described by the Software Assurance Technology Center (SATC) at NASA:

“The SATC has found the most effective evaluation is a combination of size and (Cyclomatic) complexity. The modules with both a high complexity and a large size tend to have the lowest reliability. Modules with low size and high complexity are also a reliability risk because they tend to be very terse code, which is difficult to change or modify.” SATC

Putting It All Together
The bottom line is that a high complexity number means greater probability of errors with increased time to maintain and troubleshoot. Take a closer look at any functions that have a high complexity and decide whether they should be refactored to make them less complex.

Code metrics – Depth of inheritance (DIT)

Depth of Inheritance. Depth of inheritance, also called depth of inheritance tree (DIT), is defined as “the maximum length from the node to the root of the tree”.

High values for DIT mean the potential for errors is also high, low values reduce the potential for errors. High values for DIT indicate a greater potential for code reuse through inheritance, low values suggest less code reuse though inheritance to use. Due to lack of sufficient data, there is no currently accepted standard for DIT values.

You can read full article here;

https://learn.microsoft.com/en-us/visualstudio/code-quality/code-metrics-values?view=vs-2022

Add following nuget package in your project;

Microsoft.CodeAnalysis.NetAnalyzers

Integration in Azure DevOps

To integrate in Azure DevOps, follow this article;

https://secdevtools.azurewebsites.net/helpRoslynAnalyzers.html

Method vs Linq based query syntax example

I need to make inner join on 3 tables; LedgerTypes, LedgerControl and Ledger.

Method based query example

//method based query
            
// your starting point - table in the "from" statement
var list = LedgerTypes
  //the source table of the inner join
  .Join(LedgerControl,
     //primary key (first part of sql "join" statement)
     t => t.Id,
     //foreign key (the second part of the "on" clause)
     lc => lc.ControllerTypeId, 
  (t, lc) => new { t, lc })   //new join
  // third table in the join clause
  .Join(Ledger, 
    //third table foreign key
    tc => tc.lc.Id, 
    //second table primary key
    l => l.ControllerID, 
  (tc, l) => new { tc, l })
      .Select(result => new {          //selection
       LedgerTypeId = result.tc.t.Id,
       LedgerTypeName = result.tc.t.ControllerTypeName,
       LedgerControlId = result.tc.lc.Id,
       LedgerControlName = result.tc.lc.ControllerCodeFullName,
       LedgerId = result.tc.lc.Id,
       LedgerName = result.tc.lc.ControllerCodeFullName
       // other assignments
});

Linq based query example

 //linq based query
var list = from t in LedgerTypes
    join lc in LedgerControl on t.Id equals lc.ControllerTypeId
    join l in Ledger on lc.Id equals l.ControllerID
    select new
       {
             LedgerTypeId = t.Id,
             LedgerTypeName = t.ControllerTypeName,
             LedgerControlId = lc.Id,
             LedgerControlName = lc.ControllerCodeFullName,
             LedgerId = l.Id,
             LedgerName = l.LedgerCodeFullName
            // other assignments
       };

I prefer query syntax because it’s readable and maintainable.

Resources

For more info read here and here

Simplifying ADO.NET Code in .NET 6

When developers think of how to access data, many use the Entity Framework (EF), Dapper, NHibernate, or some other object-relational mapper (ORM). Each of these ORMs use ADO.NET to submit their SQL queries to the back-end database. So, why do many developers use ORMs instead of just using ADO.NET directly? Simply put, ORMs allow you to write. If each of these ORMs are simply wrappers around ADO.NET, can you write your own wrapper to cut down the amount of code you need to write? Absolutely! This series of articles shows you how to create a set of reusable wrapper classes to make it simpler to work with ADO.NET in .NET 6.