Summary: The judge’s criteria for the Windows PowerShell 2011 Scripting Games are released.
Microsoft Scripting Guy, Ed Wilson, here. Yesterday we released our list of judges for the 2011 Scripting Games. One of the things that is important about the games, is the grading. Not only from a competition standpoint, but also from the perspective of obtaining feedback on your scripts, the judging is a vital learning tool. The goal of an automation language, such as Windows PowerShell, is to make things easier. It therefore makes no sense for the 2011 Scripting Games to reward bad coding practices or scripts that are unnecessarily complex.
Judges grade the scripts on a five-point scale. Multiple judges will grade the scripts, and the reflected score is an average of all the scores.
· 1 star is automatically awarded to the submission. If a person submits a script for an event, it receives a star.
· 1 star is awarded if the submission looks like it answers the question or meets the criteria of the scenario.
Three remaining stars are available to grant to (or in some cases remove from) a submission. Judges do not award negative scores.
The judges are considering the following when they award the final three stars:
· Reusable code
· Clarity of style
· Liberal use of comments
· Following a logical naming convention
· Anything that goes beyond the bare minimum requirements of the scenario
· Use of graphical elements (that are not specified in the script)
· Usage of a novel approach to the problem
If an event specifies “additional points” for a particular addition to a script, keep in mind that these are excellent ways to ensure that your script is worthy of a perfect five.
The following are things that you should strive to avoid:
· Failure to use Verb-Noun naming standards for functions
· Failure to use approved verbs in your naming of functions
· Not using a Windows PowerShell cmdlet or a parameter of a cmdlet that will clearly meet the needs of the script
· Using obsure code. Additional points are NOT awarded for deliberately obscure code. In some cases, points will be subtracted for confusing, obscure, hard to read code
· Creating your own “help function” instead of using comment-based help (all your effort will likely be in vain, and could cost you points)
· Using WMI, .net, COM or other technology when a simple Windows PowerShell cmdlet will do the trick
· Using hundreds of lines of comments for a simple single-line Windows PowerShell command that merely uses one cmdlet and a couple of parameters
· Creating a complex function and NOT including comment-based help so that people have a chance to actually understand how to use your function
· Using aliases in scripts—especially really obscure aliases that make your code difficult to read
· Using jumbled formatting that makes your code hard to read
As you can see, the number one rule of good code is that you should be able to read and understand your script. If you can, it simplifies troubleshooting and future modifications.
I invite you to follow me on Twitter or Facebook. If you have any questions, send email to me at email@example.com or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy