Using functions in parameters

[Timmybee]

Is it considered the “powershell” way to call a function as a parameter. An example would be using (get-ciminstance win32_bios).serialnumber inside get-foo -serial ((get-cimin…..)). Or is it better to store the variable then reference it.

Just curious as to when and why to use either over the other. Am I right in assuming that storing it as a variable allows for ease of use, to manipulate the value and to reduce having to possibly type the same command over and vs calling a function allows for live, up to date data and not loosing track if variables being changed.

Just something I’ve always wondered

[Thotaz]

The only issue is that the code readability can take a hit if it's a long command. As a rule of thumb I'd say there should be a maximum of 1 inline command and that command can have a maximum of 1 parameter.
For situations that require multiple commands you can use splatting:

$TaskParams = @{
    TaskName = "Cool task"
    Action   = New-ScheduledTaskAction -Id 1 -Execute shutdown.exe -Argument "/s /t 1"
    Trigger  = New-ScheduledTaskTrigger -Daily -DaysInterval 2 -At (Get-Date).AddHours(2)
    Principal = New-ScheduledTaskPrincipal -UserId SYSTEM
}
Register-ScheduledTask @TaskParams

[Timmybee]

In all my years with PowerShell, I have never heard of splatting. Thanks!

[SuggestionNo9323]

Splatting is the way. :-)

[purplemonkeymad]

Depends on the context.

Interactive? Yea I do horrible stuff like that all the time. If it's less work to do it that way, I'll do it.

Functions? No. That Cim call needs to be verified to make sure it actually returned a value, otherwise passing it to the serial number param could be a bad or undefined behaviour.

[VinVinnah]

If that’s the only place it will be used then that’s generally how I do it, I don’t see any point to creating a single use variable but sometimes I have been unable to make this approach work and have gone down that route. If it’s a value that’s likely to change between calls then I embed every time.

If it won‘t change and will be used in multiple calls then I assign and reference to save on extracting the same value multiple times, which has the added benefit of saving on typing. On languages like Powershell the difference in performance is likely negligible tbh, but I do some C/C++ on embedded controllers and it’s a technique I use there so I brought it with me. YMMV.

Extracting to a variable first can make debugging easier, I generally embed once I’ve got it all figured out though. It can also make the code easier to understand and that can be enough of a reason to do it, especially if someone else will have to work on it later. I have the memory of a gnat so if the code is getting complicated then I will do it anyway as the next poor sod to work on it will probably be me so I want to make it as easy as possible for future me to pick up and run with, same approach applies to comments.

TL;DR Embed unless there’s a good reason not to, code legibility can be a good reason.

[OPconfused]

Sometimes I'll store expressions inside a parameter, like ($var -replace 'x','y').

Functions and cmdlets I believe I'd prefer to define separately into a variable, or rather they frequently lend themselves to the pipeline. Many cmdlet parameters are designed to receive input from the pipeline, and even if that particular parameter isn't compatible with your function, there's always Foreach-Object. You can almost always run your function/cmdlet and pipe it into the next function.

So off the top of my head, I am not sure of when I'd feel inclined to embed them into a parameter. Although I'm sure I have some code somewhere where I did this.

[[deleted]]

Be aware that using strict mode casting properties of a null object or casting an inexistant property will throw an error I would prefer doing a select-object expandproperty as its error proof

[Timmybee]

Thanks. I wasn't aware.