PowerShell / PowerShell/PSScriptAnalyzer

Rule request: AvoidUsingPlusEqualOnCollections

オープン
#2,112 コメント 3 件 リアクション 2 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

主要言語
C#
スター
2.2k
フォーク
414
平均マージ
13時間 1分
マージ済み PR(30日)
2

説明

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:

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

コントリビューションガイド

コントリビューションガイドを開く

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

調査の方向性

提案されている AstVisitor の実装と VisitAssignmentStatement から始め、次に Helper.Instance.GetTypeFromAnalysis() と、issue で説明されている初期化および型分析のパスを確認します。実装前に、コレクション、配列、文字列、数値演算、PowerShell のバージョン条件の扱いを定義します。完了とは、ルールが指定された collection += のケースをコンテキストに適した提案とともに報告し、数値の += は報告しないことです。

索引モデルが issue の本文から書いたものです。

評価

技術スタック
csharp, powershell
領域
tooling
issue の種類
機能追加
難易度
5/5
見積もり時間
1週間以上
活発さ
停滞
明瞭さ
おおむね明確
初心者へのやさしさ
35/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。