PowerShell / PowerShell/PSScriptAnalyzer
Rule request: AvoidUsingPlusEqualOnCollections
まだ誰も着手していません。
- 主要言語
- 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:
- Microsoft's documentation has a good start to this:
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
GetTypeFromAnalysiswas 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
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
調査の方向性
提案されている AstVisitor の実装と VisitAssignmentStatement から始め、次に Helper.Instance.GetTypeFromAnalysis() と、issue で説明されている初期化および型分析のパスを確認します。実装前に、コレクション、配列、文字列、数値演算、PowerShell のバージョン条件の扱いを定義します。完了とは、ルールが指定された collection += のケースをコンテキストに適した提案とともに報告し、数値の += は報告しないことです。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- csharp, powershell
- 領域
- tooling
- issue の種類
- 機能追加
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 活発さ
- 停滞
- 明瞭さ
- おおむね明確
- 初心者へのやさしさ
- 35/100