Depending on your background or tendencies, coding may not come natural as it does for other people. I have found over time that one aspect in coding will make your scripts better, easier to read and easier to duplicate saving you time for later scripts. That aspect is consistency. Now consistency can be subjective. Is it really needed? Is it necessary to make sure that when you are coding that your scripts are consistent and contain almost cookie cutter like sections.
Simple answer is no.
However, if you want to improve your skills and provide a more professional level of scripts, then consistency is important. I have found that consistency carries over from your efforts outside of writing code for PowerShell scripts. For example, as an author, consistency in how content is presented is such a ways that not only makes a book more readable and accessible, but also does not lead to confusion for the readers. Carrying this over to code writing, what you find is that when code differs for similar sections or code blocks it causes confusion if duplication is needed or another person runs your script and sees formatting changes.
Consistency Examples in PowerShell
There are many places where PowerShell code can be made to be more consistent. These include commenting, formatting, the use of Functions, color schemes, wording, menus, etc. We can explore some of these examples in this article:
Menus
Menus can be used to help drive scripts to perform many different tasks in an interactive process versus a scheduled or automated task which performs a set of functions with no interaction or input from a user. Key is the construction and layout of all of the options in a menu. Label the top of the menu with something descriptive and meaningful, create menu items with the same patter (#’s or letters) and have a way to exit the menu when done. Something like these:
Both menus drive prerequisite scripts for Exchange Server builds. Notice the similarities of layout and options. They are not exactly the same, but that is not the point either. However, they use the same layout and options – title, menu options, and exit. They are also repeatable and a process that can be used in other scripts. Makes for easy script building by copying the code from old menus and using that for new menus in different scripts.
The tip here is to use consistent, repeatable code that can be reused in future scripts.
Functions
Now for functions, you will want to come up with a process for creating them and deciding things like options or parameters to be used for scripts as well as possibly naming conventions and comments at the beginning and end of functions. Add to this the possible addition of logging the progress of the same said function. like so:
[sourcecode language=”powershell”]
# START Apps Function
Function Apps {
Write-Host 'Checking for Exchange Apps.' -ForegroundColor Yellow
# Apps installed / allowed
$Line = '—————————————————————' | Out-File $Destination -Append
$Line = " App Report " | Out-file $Destination -Append
$Line = "————" | Out-file $Destination -Append
Try {
$Line = Get-App -ErrorAction STOP | Ft -auto | Out-file $Destination -Append
} Catch {
$Line = 'Get-App failed.' | Out-File $Destination -Append
$Line = "Error message – $_.Exception.Message" | Out-File $Destination -Append
}
$Line = '—————————————————————' | Out-File $Destination -Append
$Line = '' | Out-File $Destination -Append
$Line = '' | Out-File $Destination -Append
} # END Apps Function
[/sourcecode]
Notice the Starting and Ending comments, the same out-file syntax used to keep track of the functions processing. These are repeatable. Also notice the two lines (one at the beginning and one at the end. These are used for end caps for the functions results. This can be used as a consistent formatting for output to a file and if used with all functions, it would provide a consistent experience in both coding as well as output file to review later.
Commenting
While commenting in and of itself may be unnecessary, it can be quite useful for sectioning off a PowerShell script into logical chunks or documenting how a script operates. Here are some practical examples:
First, comments above a few lines, to describe what they do:
Next you see the bracketing around some process that is needed for a script:
Additionally, comments can be used for the script description at the top of a script, or to post more detail on how a section of script is to be used, etc. Applying these in a script in a reliable way, makes for a much better script.
Conclusions
Consistency is not a requirement for creating and using PowerShell for your tasks, projects or scripts. However, it certainly improves the look and feel of a script. There are a couple of ways you can apply these techniques to your script. You can code for consistency from the start of the build process. This could be supplemented or made easier by using previous created snippets of PowerShell coding. Another method would be to code the core working function of a script and then to add consistency to the script. Th last and perhaps best method for new scripts if to code the consistency as you go. This tasks effort as it requires planning and understanding how a script will operate., It may take more effort, but the payoff will be that once a methodology is decided, it can be made repeatable and reusable in future scripts.
Consistency
Categories:
