auto">Audit by Deep Research

Impact of C# 10 Mixed Deconstruction on StyleCopAnalyzers

C# 10 allows mixing existing and newly declared variables in a single deconstruction, e.g.:

(x, int y) = GetValues();

This affects several naming and spacing rules.

SA1312 – VariableNamesMustBeginWithLowerCaseLetter

Interaction

Ensures local variable names start with a lower-case letter.
Applies to variables introduced in deconstruction assignments or pattern matching.

Behavior with Mixed Deconstruction

In (x, int Y) = GetValues();, the newly declared variable Y should trigger SA1312 for starting with uppercase.
An existing variable reused in the deconstruction should not be re-checked here; its declaration already underwent validation.

Implementation

SA1312 already inspects SingleVariableDesignationSyntax nodes.
It should naturally catch newly declared variables in mixed deconstruction.
Verify that mixed deconstruction doesn’t cause the analyzer to skip new declarations.

Documentation & Tests

Docs: clarify that SA1312 also applies to variables introduced in deconstruction assignments.

Tests:

int existing;
(existing, int NewVar) = (1, 2); // SA1312 on NewVar

SA1305 – FieldNamesMustNotUseHungarianNotation

Interaction

Flags identifiers that appear to use Hungarian notation (e.g., szName, iCount).
Applies to newly declared variables, including those declared via deconstruction.

Behavior with Mixed Deconstruction

In (x, int iCount) = GetCounts();, iCount may be flagged for Hungarian notation depending on configuration.

Implementation

Uses VariableDeclarationSyntax and SingleVariableDesignationSyntax to find variable names.
Verify that declarations in deconstructions (including mixed ones) are detected.

Documentation & Tests

Docs: explicitly note that variables introduced by deconstruction assignments are subject to SA1305.

Tests:

(string szName, int iValue) = GetData(); // both should be flagged if prefixes disallowed
string name; int iValue;
(name, int iCount) = GetNameAndCount(); // iCount flagged

SA1316 – TupleElementNamesShouldUseCorrectCasing

Interaction

Enforces casing for tuple element names (e.g., ValueA, valueB).
In deconstruction, left-hand side elements are local variables, not tuple element names.

Behavior

SA1316 was updated to ignore deconstruction targets (IsInDeconstructionTarget), so it doesn’t flag variables on the left side of (x, y) = tuple;.
Mixed-deconstruction does not change this: variables on the left are still locals, handled by SA1312/SA1305.

Documentation & Tests

Docs: clarify this rule does not apply to variables introduced by deconstruction; only to tuple types/elements.

Tests:

(int ValueA, int ValueB) tuple = (1, 2);
var (valueA, valueB) = tuple; // SA1316 should not fire on valueA/valueB

SA1001 – CommasMustBeSpacedCorrectly

Interaction

Ensures appropriate spacing around commas: no space before, single space after.

Behavior in Deconstruction

Applies to commas in deconstruction lists:

(int x , int y) = (1, 2);  // space before comma → SA1001
(int x,int y) = (1, 2);    // no space after comma → SA1001
(int x, int y) = (1, 2);   // correct

Implementation

SA1001 analyzes comma tokens globally.
No special changes for deconstruction; just ensure tuples/deconstructions are covered by tests.

SA1008 & SA1009 – ParenthesesMustBeSpacedCorrectly

Interaction

SA1008: opening parenthesis spacing (no space immediately after (, etc.).
SA1009: closing parenthesis spacing (no space immediately before )).

Behavior in Deconstruction

Left side in (x, int y) = GetValues(); is subject to these rules:
- ( x, int y) → space after ( → SA1008.
- (x, int y ) → space before ) → SA1009.

Implementation

Both rules work at token level and already handle tuple-like constructs.
Confirm behavior by tests; no logic change expected.

Tests

Examples:

( x, int y) = GetValues();  // SA1008
(x, int y ) = GetValues();  // SA1009
(x, int y) = GetValues();   // no diagnostics

Include multi-line variants where newline after ( is allowed.

SA1119 – StatementMustNotUseUnnecessaryParenthesis

Interaction

Flags unnecessary parentheses around statements/expressions.

Behavior in Deconstruction

Parentheses forming the deconstruction target (x, y) are required syntax and must not be considered unnecessary.

Only additional wrapping parentheses around the whole assignment may be unnecessary:

int a = 1, b = 2;
(a, b) = (3, 4);          // required parentheses → no SA1119
((a, b) = (3, 4));        // outer parentheses unnecessary → SA1119 should flag

Implementation

Ensure SA1119 distinguishes between:
- Required tuple/deconstruction parentheses (never flagged).
- Extraneous parentheses that wrap the entire assignment.

Documentation & Tests

Docs: add note that deconstruction parentheses are exempt (similar to tuple and pattern syntax).
Tests verifying:
- No SA1119 for (a, b) = (3, 4);.
- SA1119 for ((a, b) = (3, 4));.

Summary

Only a small number of rules are affected by C# 10’s mixed deconstruction feature:

Naming rules (SA1312, SA1305, SA1316).
Spacing rules (SA1001, SA1008, SA1009).
Parentheses rule (SA1119).

By verifying and slightly adjusting implementations, clarifying documentation, and adding targeted tests, StyleCopAnalyzers can fully support (x, int y) = ... style mixed deconstruction without false positives or missed violations.

Sources

SA1312VariableNamesMustBeginWithLowerCaseLetter.cs, SA1312CSharp7UnitTests.cs
SA1305FieldNamesMustNotUseHungarianNotation.cs
SA1316TupleElementNamesShouldUseCorrectCasing.cs and related configuration docs
SA1001.md, SA1008CSharp7UnitTests.cs
SA1119.md

Uh oh!

Review impact of assignment and declaration in the same deconstruction on existing rules #3990

Description

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions