Dan Harman, a PM in the Windows PowerShell team has published an excellent blog article: Increasing visibility of cmdlet design guidelines. The article talks about cmdlet naming conventions and the importance of good naming around the verbs and nouns used in the names of cmdlets (and by implication advanced functions too). The article also talks about the problems of a proliferation of uses of PowerShell that deviate from the standards currently being set by the PowerShell team.
With the increasing adoption of PowerShell across MS and non-MS products, standards are vital and enforcement probably mandatory. PowerShell aims help organisations break down their knowledge silos. To achieve this, there needs to be a standard set of verbs and nouns you can use and some good way of enforcing it.
Microsoft proposes some changes to V2 to resolve the issue. Specifically, when you call Import-Module to import cmdlets, Powershell evaluates the module and warns against violations of the standards. The end use sees a warning message but the cmdlets are still imported. Thus, by default, when you load a module with badly named cmdlets, you get a warning message but everything works (i.e. the module is imported!). For scripts where you want to suppress the Warning, just use the –DisableNameChecking on the call to Import-Module.
This is a pretty neat solution. We’ve already seen a number of interesting approaches to the use of PowerShell by various teams, and MS is right to want to stop the problem from being a real problem.
One addition I’d like to see: a GPO setting to set a default value to enable disabling name checking. The scenario I envisage is an organisation that has, for whatever reason, invested in cmdlets that end up being badly named. Rather than have their admins constantly be reminded, or worse possibly confused, I’d like to see a GPO setting to always just not show the message for my organisation (or part of an organisation).
No comments:
Post a Comment