dotnet-csharp-code-smells

Reviewing C# for logic issues. Anti-patterns, common pitfalls, async misuse, DI mistakes.

Safety Notice

This listing is imported from skills.sh public index metadata. Review upstream SKILL.md and repository scripts before running.

Copy this and send it to your AI assistant to learn

Install skill "dotnet-csharp-code-smells" with this command: npx skills add wshaddix/dotnet-skills/wshaddix-dotnet-skills-dotnet-csharp-code-smells

dotnet-csharp-code-smells

Proactive code-smell and anti-pattern detection for C# code. This skill triggers during all workflow modes -- planning, implementation, and review. Each entry identifies the smell, explains why it is harmful, provides the correct fix, and references the relevant CA rule or cross-reference.

Cross-references: [skill:dotnet-csharp-async-patterns] for async gotchas, [skill:dotnet-csharp-coding-standards] for naming and style, [skill:dotnet-csharp-dependency-injection] for DI lifetime misuse, [skill:dotnet-csharp-nullable-reference-types] for NRT annotation mistakes.

Out of Scope: LLM-specific generation mistakes (wrong NuGet packages, bad project structure, MSBuild errors) are covered by [skill:dotnet-agent-gotchas]. This skill covers general .NET code smells that any developer -- human or AI -- should avoid.


1. Resource Management (IDisposable Misuse)

SmellWhy HarmfulFixRule
Missing using on disposable localsLeaks unmanaged handles (sockets, files, DB connections)Wrap in using declaration or using blockCA2000
Undisposed IDisposable fieldsClass holds disposable resource but never disposes itImplement IDisposable; dispose fields in Dispose()CA2213
Wrong Dispose pattern (no finalizer guard)Double-dispose or missed cleanup on GC finalizationFollow canonical Dispose(bool) pattern; call GC.SuppressFinalize(this)CA1816
Disposable created in one method, stored in fieldOwnership unclear; easy to forget disposalDocument ownership; make the containing class IDisposableCA2000
using on non-owned resourcePremature disposal of shared resource (e.g., injected HttpClient)Only dispose resources you create; let DI manage injected services--

See details.md for code examples of each pattern.


2. Warning Suppression Hacks

SmellWhy HarmfulFixRule
Invoking event with null to suppress CS0067Creates misleading runtime behavior; masks real bugsUse #pragma warning disable CS0067 or explicit event accessors { add {} remove {} }CS0067
Dummy variable assignments to suppress CS0219Dead code that confuses readersUse _ = expression; discard or #pragma warning disableCS0219
Blanket #pragma warning disable without restoreSuppresses ALL warnings for rest of fileAlways pair with #pragma warning restore; suppress specific codes only--
[SuppressMessage] without justificationFuture maintainers cannot evaluate if suppression is still validAlways include Justification = "reason"CA1303

See details.md for the CS0067 motivating example (bad pattern to correct fix).


3. LINQ Anti-Patterns

SmellWhy HarmfulFixRule
Premature .ToList() mid-chainForces full materialization; wastes memoryKeep chain lazy; materialize only at the endCA1851
Multiple enumeration of IEnumerable<T>Re-executes query or DB call on each enumerationMaterialize once with .ToList() then reuseCA1851
Client-side evaluation in EF CoreLoads entire table into memory; silent perf bombRewrite query as translatable LINQ or use AsAsyncEnumerable() with explicit intent--
.Count() > 0 instead of .Any()Enumerates entire collection instead of short-circuitingUse .Any() for existence checksCA1827
Nested foreach instead of .Join() or .GroupJoin()O(n*m) when O(n+m) is possibleUse LINQ join operations or Dictionary lookup--
.Where().First() instead of .First(predicate)Creates unnecessary intermediate iteratorPass predicate directly to .First() or .FirstOrDefault()CA1826

4. Event Handling Leaks

SmellWhy HarmfulFixRule
Not unsubscribing from eventsMemory leak: publisher holds reference to subscriberUnsubscribe in Dispose() or use weak event pattern--
Raising events in constructorSubscribers may not be attached yet; derived class not fully constructedRaise events only from fully initialized instancesCA2214
async void event handler (misused)async void is the only valid signature for event handlers, but exceptions are unobservableWrap body in try/catch; log and handle exceptions explicitly--
Event handler not checking for nullNullReferenceException when no subscribersUse event?.Invoke() null-conditional pattern--
Static event without cleanupRooted references prevent GC for application lifetimePrefer instance events or use WeakEventManager--

Cross-reference: [skill:dotnet-csharp-async-patterns] covers async void fire-and-forget patterns in depth.


5. Design Smells

SmellThresholdWhy HarmfulFix
God class>500 linesToo many responsibilities; hard to test and maintainExtract cohesive classes using SRP
Long method>30 linesHard to understand, test, and reviewExtract helper methods with descriptive names
Long parameter list>5 parametersIndicates missing abstractionIntroduce parameter object or builder
Feature envyMethod uses another class's data more than its ownMisplaced responsibility; tight couplingMove method to the class it envies
Primitive obsessionDomain concepts represented as raw string/intNo type safety; validation scatteredIntroduce value objects or strongly-typed IDs
Deep nesting>3 levels of indentationHard to follow control flowUse guard clauses (early return) and extract methods

6. Exception Handling Gaps

SmellWhy HarmfulFixRule
Empty catch blockSilently swallows errors; masks bugsAt minimum, log the exception; prefer letting it propagateCA1031
Catching base ExceptionCatches OutOfMemoryException, StackOverflowException, etc.Catch specific exception typesCA1031
Log-and-swallow (catch { log; })Caller never learns operation failedRe-throw after logging, or return error result--
Throwing in finallyMasks original exception with the new oneUse try/catch inside finally; never throw from finally--
throw ex; instead of throw;Resets stack trace; hides original failure locationUse bare throw; to preserve stack traceCA2200
Not including inner exceptionLoses causal chain when wrapping exceptionsPass original as innerException parameter--

Cross-reference: [skill:dotnet-csharp-async-patterns] covers exception handling in fire-and-forget and async void scenarios.


Quick Reference: CA Rules

RuleDescription
CA1031Do not catch general exception types
CA1816Call GC.SuppressFinalize correctly
CA1826Do not use Enumerable methods on indexable collections
CA1827Do not use Count()/LongCount() when Any() can be used
CA1851Possible multiple enumerations of IEnumerable collection
CA2000Dispose objects before losing scope
CA2200Rethrow to preserve stack details
CA2213Disposable fields should be disposed
CA2214Do not call overridable methods in constructors

Enable these via <AnalysisLevel>latest-all</AnalysisLevel> in your project. See [skill:dotnet-csharp-coding-standards] for analyzer configuration.


References

Source Transparency

This detail page is rendered from real SKILL.md content. Trust labels are metadata-based hints, not a safety guarantee.

Related Skills

Related by shared tags or category signals.

Coding

dotnet-cli-distribution

No summary provided by upstream source.

Repository SourceNeeds Review
Coding

dotnet-github-releases

No summary provided by upstream source.

Repository SourceNeeds Review
Coding

dotnet-cli-release-pipeline

No summary provided by upstream source.

Repository SourceNeeds Review