C# Coding Skill

Patterns and idioms for writing modern C# code.

This skill covers C# 14 language features, .NET 10 conventions, and idiomatic C# development. Load this skill before writing or modifying C# code.

Required Language Features

• •File-scoped namespaces: namespace MyApp.Core;
• •Primary constructors: class Service(IDep dep, ILogger logger)
• •Collection expressions (MANDATORY): [], [item], [..spread]
  • •NEVER use new[], new List<T>(), Array.Empty<T>()
  • •For type inference, prefer [new T { }, new T { }] over casts
  • •Use T[] x = [...] only when simpler forms fail
• •Records for DTOs, init setters
• •Pattern matching: is not null, switch expressions, property patterns
  • •Property patterns: obj is Type { Prop: value } over obj is Type t && t.Prop == value
  • •Recursive/nested: obj is Type { Outer: { Inner: value } }
  • •Extended property pattern: obj is { Outer.Inner: value } (C# 10)
  • •Empty property pattern: { } name matches non-null and binds (e.g., is Type { Prop: { } x })
• •Spread operator for collections: [..first, ..second]

C# 14 Features (.NET 10)

• •field keyword: public string Name { get; set => field = value ?? throw; } = "";
• •Extension blocks: extension(T src) { public bool IsEmpty => !src.Any(); } (properties + statics)
• •Null-conditional assignment: obj?.Prop = value; (RHS evaluated only if obj not null)
• •Lambda modifiers without types: (text, out result) => int.TryParse(text, out result)

Migration: Use new syntax for new code; opportunistically refactor existing code when revisiting.

Required Idioms

Visibility

• •Use internal for implementation classes (CLI apps, service implementations)
• •Use public only for genuine external APIs
• •Concrete classes implementing public interfaces should be internal

Data Modeling

• •Records for data models
• •Favor immutability where reasonable
• •Use immutable collections: IReadOnlyCollection, IReadOnlyDictionary

JSON Serialization

• •System.Text.Json: Use JsonSerializerOptions for convention/style settings applied uniformly
• •Reserve attributes ([JsonPropertyName], etc.) for special cases only
• •Check for existing options configuration before creating new instances

UsedImplicitly Attribute

Mark runtime-used members (deserialization, reflection, DI):

• •[UsedImplicitly] - type instantiated implicitly (DI, empty marker records)
• •[UsedImplicitly(ImplicitUseKindFlags.Assign)] - properties set via deserialization
• •[UsedImplicitly(..., ImplicitUseTargetFlags.WithMembers)] - applies to type AND all members
• •Common for DTOs: [UsedImplicitly(ImplicitUseKindFlags.Assign, ImplicitUseTargetFlags.WithMembers)]

Warning Suppression

• •NEVER use #pragma warning disable
• •Use [SuppressMessage] with Justification on class/method level
• •Prefer class-level when multiple members need same suppression

LINQ

• •LINQ method chaining over loops
• •LINQ method syntax only; NEVER use query syntax (from/where/select keywords)

Method Calls

• •Named arguments for boolean literals: new Options(SendInfo: false, SendEmpty: true)
• •Named arguments for consecutive same-type parameters to clarify intent

Async

• •ValueTask for hot paths
• •CancellationToken everywhere (use ct for variable name)

Interfaces

• •Avoid interface pollution: not every service class must have an interface
• •Add interfaces when justified (testability, more than one implementation)

Local Functions

• •Local functions go after return/continue statements
• •Add explicit return; or continue; if needed to separate main logic from local function defs

Design Principles

Quality Gates

• •Zero warnings/analysis issues - treat warnings as errors
• •All code must pass static analysis before commit

Abstraction

• •Prefer polymorphism over enums when modeling behavior or extensibility
• •Propose enum vs polymorphism tradeoffs for discussion rather than defaulting to enums
• •Every abstraction must justify its existence with concrete current needs

Dependency Injection

• •MUST use DI for all dependencies; NEVER manually new service objects in production code
• •Concrete implementations get injected; tests can substitute
• •Search existing registrations before adding new ones

Comment Guidelines

Comments must earn their place by reducing cognitive load. When to comment:

• •LINQ chains (3+ operations): Brief comment stating transformation goal
• •Conditional blocks with non-obvious purpose: One-line comment (e.g., // Explicit: user specified)
• •Private methods: Block comment if name + parameters don't make purpose self-evident
• •Early returns/continues: Include reason if not obvious from context
• •Complex algorithms: Comment explaining approach at top, not line-by-line
• •General: Any code where a reader would pause and wonder "why?" or "what's happening here?"

NEVER:

• •XML doc comments (unless public API library)
• •Commented-out code
• •Restating what code literally does

Tooling

Formatting

• •CSharpier is the ONLY formatting tool
• •NEVER use dotnet format or other formatters
• •Run pre-commit hooks on all changed files

dotnet CLI

• •Use dotnet CLI for: adding/removing packages, adding projects to solution
• •Central package management via Directory.Packages.props - specify versions there, not in csproj
• •Avoid --no-build or --no-restore flags; dotnet test handles restore + build automatically
• •Minimal verbosity for build/test: dotnet build -v m --no-incremental, dotnet test -v m
• •For verbose debugging, pipe to file: dotnet test -v d 2>&1 > /tmp/test.log then search with rg

Project Structure

• •SLNX format preferred over traditional SLN
• •One Autofac/DI module per library to keep registration modular
• •Dotnet tools configured in .config/dotnet-tools.json