Ez elméleti rész lezárásaként összefoglalnám azokat a főbb jellemzőket, amelyek a PowerShellben történő programozás jellegzetességeinek érzek:
Csövezés minden mennyiségben!
Egy-egy művelet eredményét legtöbb esetben felesleges változókba rakni, érdemes azonnal tovább küldeni további feldolgozásra a csővezetéken keresztül egy újabb parancs számára. Ezzel nem csak egyszerűbb, tömörebb lesz a programunk, hanem egy csomó átmeneti adattárolás memória-felhasználását spóroljuk meg.
Gyűjtemény vagy objektum?
Mint ahogy a láttuk például a get-member cmdlet működésénél, a PowerShell néha túl „okosan” próbál gyűjteményeket kezelni, azaz nem mint objektumokat használja, hanem kifejti az egyes elemeit. Míg ha egy elemet adunk neki, akkor meg azt az adott objektumként kezeli. Ez gyakran félrevezető, főleg amikor egy objektum tulajdonságait próbáljuk feltérképezni, és azt hisszük, hogy már egy indexelhető tömbnél tartunk, és akkor derül ki számunkra, hogy nem, még mélyebbre kell ásnunk, mert amit látunk az még mindig egy egyetlen elemet tartalmazó tömbobjektum.
Hagyományos „programolós” ciklus helyett bármi más!
Akinek valamilyen klasszikus programnyelvben van gyakorlata, az PowerShellben is hajlamos eleinte minden többelemű adat feldolgozásakor FOR ciklust írni. De ha nincs szükségünk az elemek ilyen jellegű indexelésére, nyugodtan használjunk FOREACH ciklust. Ha csővezetéken érkeznek az adatok, akkor meg használjunk ForEach-Object cmdletet. Sőt, mint ahogy az „Exchange 12 Rocks” példámban szerepelt ( 1.3.13 Típuskonverzió fejezet), a típuskonverzió is kiválthat sok esetben ciklust, illetve még a SWITCH kifejezés is használható ciklusként.
Minden objektum!
Soha ne feledkezzünk meg arról, hogy a PowerShellben minden kimenet objektum. Ugyan a konzolon szövegeket, karaktereket látunk, de ezek az esetek túlnyomó többségében nem egyszerű szövegek, hanem összetett objektumok, melyeknek csak néhány tulajdonságát látjuk a képernyőn szövegként. Ráadásul ezek a tulajdonságok is általában szintén objektumok. Ne legyünk restek ezeknek a mélyére ásni. Ebben segít bennünket a get-member cmdlet, a különböző szkriptszerkesztők (mint például a PowerGUI Script Editora) és a Reflector segédprogram, valamint az MSDN weboldal. Nézzünk utána a tulajdonságoknak, metódusoknak, konstruktoroknak, statikus metódusoknak, nehogy leprogramozzunk valami olyasmit, ami már készen megtalálható az objektum jellemzői között vagy a .NET keretrendszer valamelyik osztályában.
Szabjuk testre a PowerShellt, de ez ne menjen a kompatibilitás kárára
Ugyan a 2.0-ás verzióval a PowerShellnek egyre kevesebb hiányossága van, de ha mégis szeretnénk valamivel kibővíteni, akkor azt nagyon egyszerűen megtehetjük. Újabb függvényekkel új funkciókat valósíthatunk meg. Új álnevekkel kevesebbet kell gépelnünk. A típusok kiegészítésével újabb tulajdonságokat és metódusokat készíthetünk objektumainkhoz. Modulokkal újabb funkció-halmazokat tudunk egy egységként kezelni és hordozni gépek között.
A beépített cmdleteket, álneveket lehetőleg ne definiáljuk újra, mert ez a programjaink, parancssoraink értelmezhetőségének kárára megy.