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.

Format Buffet Nobody Ordered

Developers wanted one format. We got twenty. CSV mangles data, XML drowns in tags, JSON forbids comments, YAML punishes spaces. TOML tried fixing it. TAML went minimal. TOON optimized for AI. CCL brought category theory. Result? Five formats per project, three parsers, and debugging why NO became false. AI can’t save us either. Welcome to format hell.

Why Real Professionals Will Never Be Replaced by AI

The elephant everyone ignores: AI can generate code faster than you can type. GitHub Copilot autocompletes entire functions. ChatGPT builds APIs from prompts. Typing is dead. So why will real professionals never be replaced? Because “vibe coding”—describe what you want, ship what AI generates—is a productivity illusion that collapses spectacularly in production. When code generation becomes trivial, understanding what that code costs, where it fails, why it breaks under load becomes everything. AI generates syntax. Professionals understand execution, failure modes, operational cost, and production consequences. The differentiator isn’t typing speed—it’s mastering the feedback loop: write code, watch it fail, understand why, refine thinking. This discipline can’t be automated. Prompt engineers generate code. Real professionals ensure it survives contact with reality.

Most Software Teams Are Lying to Themselves—2026 Needs to Be Different

Happy New Year 2026! 🎉

Fix one piece of technical debt this week—not next quarter. .NET 10, analyzers, and tests are ready; discipline is the only missing part.

Power of Ten Rules: More Relevant Than Ever for .NET

Gerard Holzmann’s Power of Ten rules prevented spacecraft failures and exposed Toyota’s fatal throttle bugs. Four rules transfer directly to C# with superior enforcement. Three become irrelevant thanks to the managed runtime.

The verdict: These principles aren’t just valid. They’re finally enforceable without heroic manual effort.

Code Metrics: 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.