Code Quality and Clean Code Principles
“Quality” is the word teams reach for when a codebase frustrates them and nobody wants to argue about specifics. The articles in this collection try to put specifics back: which metric actually predicts maintainability, which Clean Code rule survives contact with a real change request, which analyzer warning is signal and which is decoration. Quality without a measurement attached is taste, and taste does not survive a team rotation.
The metric-focused content treats cyclomatic complexity, maintainability index, and class coupling as imperfect proxies rather than thresholds. The same number means different things in a CQRS handler and in a parser. Articles cover how to configure code metrics in Visual Studio and dotnet tooling so the output reflects intent — and when to ignore the numbers because the context invalidates them.
Analyzer and nullable-reference-type content sits at the boundary between style and correctness. Turning on TreatWarningsAsErrors, adopting <Nullable>enable</Nullable> in a legacy project, and choosing which Roslyn rules to enforce in .editorconfig are not aesthetic choices — they decide what kind of bug your CI is allowed to ship. The articles walk through staged adoption strategies rather than the all-or-nothing flag flip that most teams attempt and abandon.
Testing strategy gets the same treatment. Coverage percentages are easy to game; mutation testing exposes assertions that test nothing. Articles examine where mutation testing pays for its runtime cost, where it produces noise, and how to read the surviving mutants without rewriting the entire suite.
The social dimension runs through everything. Quality practices that one engineer pushes through review get reverted by the next rotation unless they live in tooling. The recurring theme is moving quality out of opinion and into configuration that fails the build — so the standard outlives whoever set it.
Code Metrics and Configuration: Beyond the Numbers Game
Code metrics have become a standard feature in modern development environments, yet their implementation and interpretation often leave much to be desired. While Visual Studio and .NET provide comprehensive code metrics analysis, the way these metrics are configured, presented, and (more critically) acted upon reveals a fundamental disconnect between measurement and meaningful improvement.
What code metrics actually measure, how to configure them properly, and (more importantly) why blindly following thresholds without understanding context is, frankly, a recipe for misguided refactoring efforts that waste your team’s time and actively damage your codebase.
.NET 10: Boring by Design, Reliable by Default
Microsoft wants you to believe .NET 10 is boring. They’re right — and that’s the best news we’ve had in years.
.NET 10 is here, and for once, Microsoft didn’t oversell it. LTS support through 2028, JIT improvements that actually matter, and C# 14 features that won’t rewrite your architecture. Here’s what you need to know before migrating.
How SearchValues Saved Us From Scaling Hell
While you’re busy optimizing database queries and adding cache layers, thousands of string searches per second are quietly eating your CPU budget. The problem isn’t visible in your APM dashboard because it’s distributed across every request. But it’s there. Compounding. Scaling linearly with load.
I discovered this the hard way when a log processing API started choking under production traffic. The bottleneck? String validation and sanitization. The fix? A .NET 8 feature that delivered a 5x performance improvement and let us shut down servers instead of adding them. And it’s gotten even better in .NET 9 and 10.
Clean Code: A Lip Service, Not a Standard