Event 2: My notes…

OK, I’ve seen your entries, and I must say – in general, I like what I saw. But it wouldn’t be helpful to tap you on the back and pretend everything is perfect, would it?

As previously, I will mention few pain points I’ve seen. I will also try to mention what I liked about entries. Let’s jump to beginner category first.

Beginner “likes”

First and foremost: any entry that was producing object was on my potentially “favorite” list. I was happy to see so many entries that were actually taking this approach rather than writing text to the console.

I also liked entries where authors would take into account scope of lookup and even though they were using CIM cmdlets (that use WSMan by default), they would talk in DCOM instead. Great to see that people pay attention and understand what can be used where.

Another point is that many authors actually took advantage of the fact, that ComputerName parameter usually accepts an array and rather than pipe Get-Content into Foreach-Object – they would pass result of Get-Content directly to ComputerName parameter.

Beginner “issues”

First things first. Write-Host is not reporting tool. Write-Host is fine to display colorful message. No other uses. If you won’t stop using Write-Host to display results, you will never be able to take advantage of PowerShell. Seriously, you are putting chains on.

Another thing is pseudo-one-liners. Why are you punishing yourself and any potential reader of your code? Breaking code on pipe, comma, braces – good. Joining several lines into one with semicolon – very bad.

Next: calculations. Why would you use code like that:

$foo/1024/1024/1024            

Instead of clear, obvious, less-typing, lazy-pants (are you really from IT? ):

$foo / 1gb            

Finally: I’ve seen few entries that tried to create functions, and that was great. But keep in mind: PowerShell function is command, and should follow naming convention. I’m bad cop, and won’t listen to the excuses. You have to do it right. If you don’t like rules – use aliases. Function? Approved Verb – Singular Noun. Period.

Advanced “likes”

What I liked in advanced category? I’ve seen very good entries, with very smart use of pipeline, good implementation of credentials, with proper error handling (better than mine for sure, but as Jakub pointed out – mine was awful, and he is absolutely right).

Lots of entries with objects in output made my day(s), really. That’s what I would like to see in each advanced entry. Also, I feel that naming was better (maybe it was easier to name the functions in this event).

Advanced “issues”

I have to start with mistakes in pipeline implementation. Two major that I’ve seen:

• “supporting” pipeline without process script block
• “supporting” multiple parameters ByValue with same type.

I won’t go into details why this is bad. If you haven’t seen it yet – read Boe’s article on that topic. It’s great reference for anybody who want to use pipeline.

Another issue I’ve seen: great (but not returned) love for arrays. Why oh why would you waste time and resources to create so many arrays, tossing each one away after each process/ foreach cycle, and in the end – let PowerShell turn this array into stream of objects? I think that has to be said again: you can’t add item to an array in PowerShell. There is no operation that will allow you to do that. What you do is: create new array, rewrite old array to new one, add new element at the end of new array, toss old array into depth of $null. Why would you do that? If you really have to combine results, use classes that support adding elements (like [Collections.ArrayList]). But if you don’t plan to do anything smart with collection anyway – why bother? Just write objects straight into my pipe, where they belong!

Finally – function with Get- name that returns formatting objects… Why would you do that? That’s worse idea ever (almost: you can write host to make it worse than that). If you want to make sure that you will get table – use other techniques. It’s more work on your side, but user will be happy. You have to think what next person may want to do with your results. Filtering, sorting should just work. Otherwise your report is useless.

Advanced “side notes”

Lastly: two side notes. Nothing very important, but I’ve seen few entries that was using new v3 syntax, but in a way that does not take advantage of it (at least: not full advantage). New construct:

[PSCustomObject]@{            
    First = 1            
    Second = 2            
}

This is nice way to produce report that will keep the order of parameters. But only if:

• you use exactly that literal
• you pass [ordered] hashtable

if you try it with “normal” hash table – end results is not so good:

When you do it like that – you are not taking advantage of new PSCustomObject syntax. Instead, you are using feature that allows us create new objects of many types with hash tables:

If you want to know what types are working with this – take a look at Shay’s article on that topic.

Second side not is related to one of my favorite things when working in v3, OutputType attribute. Why some functions would tell me that they output strings and send custom objects to the pipe instead is really difficult for me to understand…It’s metadata, so you can put anything there. But if you want to really take advantage of it, objects in output and information provided should match. Otherwise you are misleading your users:

Obviously, if I select “Day” property I won’t get any results… So as much as I love that people are using this feature, I would really prefer to get information, not gossip.