Comparatif PowerShell entre @() et += jugés inefficaces, et List[T] avec .Add() comme alternative performante.

Pourquoi @() et += sont à éviter en PowerShell

par

ArrayList PowerShell revient souvent dès qu’on cherche à construire une collection dynamiquement dans un script.

Ce n’est pas un hasard : entre les tableaux @(), les ajouts avec += et les collections .NET modernes comme List[T], beaucoup de scripts utilisent encore des patterns simples à lire mais coûteux en performance.

Dans cet article, on va voir pourquoi @() et += deviennent vite inefficaces, pourquoi ArrayList reste séduisant malgré son âge, et surtout quelle approche utiliser aujourd’hui pour manipuler des collections proprement en PowerShell.

Le vrai problème avec @() et +=

En PowerShell, un tableau natif a une taille fixe. Donc quand vous faites ça :

PowerShell
$Items = @()
$Items += "A"
$Items += "B"
$Items += "C"

PowerShell ne “rajoute” pas vraiment un élément au tableau existant. Il recrée un nouveau tableau à chaque fois et recopie le contenu précédent. Une fois, ce n’est rien. Cent fois, c’est médiocre. Dix mille fois, c’est une punition.

Le problème n’est donc pas seulement stylistique. Il est algorithmique. Plus la collection grossit, plus le coût explose. Sur des scripts d’inventaire, d’audit, d’API, de parsing ou de reporting, cette habitude peut transformer un script correct en casserole ambulante.

Pourquoi ArrayList séduit encore en PowerShell

Beaucoup finissent donc par tomber amoureux de System.Collections.ArrayList :

PowerShell
$Items = [System.Collections.ArrayList]::new()
[void]$Items.Add("A")
[void]$Items.Add("B")
[void]$Items.Add("C")

Et honnêtement, la tentation se comprend. C’est mutable, rapide pour l’ajout, simple à lire, simple à expliquer. Contrairement à ce qu’on lit parfois, ArrayList est déprécié, mais pas obsolète au sens strict. Il fonctionne encore très bien.

Son défaut n’est pas qu’il soit “cassé”. Son défaut, c’est qu’il appartient à une génération plus ancienne de .NET. Il n’est pas typé fortement, ce qui veut dire qu’il accepte à peu près n’importe quoi. C’est pratique au début, puis cela finit souvent en collection fourre-tout, avec conversions implicites, surprises, et dette technique.

Quelle alternative à ArrayList en PowerShell

Aujourd’hui, la bonne approche, dans la majorité des cas, c’est List[T] :

PowerShell
$Items = [System.Collections.Generic.List[string]]::new()
$Items.Add("A")
$Items.Add("B")
$Items.Add("C")

Pourquoi c’est mieux ?

D’abord, l’ajout est efficace. Ensuite, la collection est typée. Si vous annoncez une liste de string, vous obtenez une vraie liste de string, pas une boîte de rangement remplie au hasard. Le code devient plus robuste, plus prévisible, et plus facile à maintenir.

Pour des objets plus riches :

PowerShell
$Results = [System.Collections.Generic.List[object]]::new()

$Results.Add([pscustomobject]@{
    Name = "SRV01"
    Role = "FileServer"
})

Et si vous ne connaissez pas le type à l’avance, List[object] reste souvent un meilleur choix que ArrayList.

Le bon réflexe

La règle simple est celle-ci :

  • pour une collection alimentée dynamiquement, évitez @() avec +=
  • si vous ajoutez des éléments un par un, utilisez List[T]
  • gardez ArrayList uniquement pour des cas legacy ou très spécifiques
  • utilisez les tableaux PowerShell surtout pour des données déjà constituées, pas comme structure de construction progressive

@() n’est pas “interdit”. += n’est pas “buggé”. Mais les deux ensemble sont souvent le signe d’un script qui fera illusion sur 20 lignes et souffrira dès qu’il devra travailler sérieusement.

PowerShell est excellent, à condition d’arrêter de lui faire porter des habitudes paresseuses. Un tableau n’est pas une liste dynamique. Le traiter comme tel, c’est demander à un tournevis de faire le boulot d’une perceuse.

Mickael R.

Ingénieur tout terrain, je m’adapte avec rigueur et autonomie. Mon sens du travail en commun fait de moi un atout dans une équipe technique. Le pilier de mon métier? l’automatisation par le script!

Laisser un commentaire