Rule request: AvoidUsingPlusEqualOnCollections

Summary of the new feature

NOTE: I do believe this rule isn't relevant for v7.5+ but a lot of us are unfortunately stuck on v5.1.

As a code reviewer, I want developers to be warned about using += to build collections so that I don't have to repeatedly explain why their scripts have poor performance and can focus on reviewing logic instead of catching inefficient patterns.

Problem Statement:
Using += to build arrays and collections in PowerShell is a common performance anti-pattern. Each += operation creates an entirely new array and copies all existing elements, resulting in O(n²) complexity for building collections. This can cause significant performance degradation, especially with large datasets.

For example, adding 10,000 items to an array using += performs ~50 million copy operations, while using proper collection types performs only 10,000 add operations.

Proposed technical implementation details

Rule Name: PSAvoidUsingPlusEqualsOnCollections

Severity: Warning

Behavior:

• Skip if using PowerShell v7.5+
• Flag usage of += operator when the left-hand side is a collection, array, or string.
• Suggest more efficient alternatives based on the context

Recommended alternatives to suggest:

• Microsoft's documentation has a good start to this:
• • Array Addition
• • String Addition

Example violations:

# Building array with += - Flagged
$results = @()
foreach ($item in $data) {
    $results += $item
}

# Building collection in loop - Flagged
$numbers = @()
for ($i = 1; $i -le 1000; $i++) {
    $numbers += $i
}

# Adding to existing array - Flagged
$existingArray += $newItem

# Adding to IDictionaries
$hashtable = @{}
for ($i = 1; $i -le 1000; $i++)
{
    $hashtable += @{$i = $i }
}

Should NOT be flagged:

# Numeric operations
$sum += $number

Technical Implementation:

• I plan on implementing this rule if approved.
• From my testing, the rule will inherit AstVisitor and visit VisitAssignmentStatement.
• Left-hand assignment's type can be retrieved via Helper.Instance.GetTypeFromAnalysis()
• If not found, analyze where the variable was initialized and go from there. From my testing, analyzing the right-hand side ExpressionAsts' helped determine said type if GetTypeFromAnalysis was unreliable.
• Provide context-appropriate suggestions based on the use case

Configuration Options (up for discussion):

• Add type exclusion (e.g., String)?

What is the latest version of PSScriptAnalyzer at the point of writing

1.24.0

Start with the proposed AstVisitor implementation and VisitAssignmentStatement, then inspect Helper.Instance.GetTypeFromAnalysis() and the initialization/type-analysis paths described in the issue. Define the handling for collections, arrays, strings, numeric operations, and the PowerShell version condition before implementation. Done means the rule reports the specified collection += cases with context-appropriate suggestions while leaving numeric += unreported.