PowerShell is all about getting things done but how you do things can be as important as what you do. I’ll explain what I mean so you be able to be putting on the style.
While PowerShell is used by a number of developers its predominantly an administrators tool. Most administrators aren’t taught to code so they pick things up as they go along – including coding styles.
Back when PowerShell first appeared Jeffrey Snover talked about administrators having an ad hoc development methodology. They’d use single cmdlets to get things done. Then progress to using multiple cmdlets in a pipeline. They’d then realise that if they saved that pipeline in a script they wouldn’t have to retype it every time they wanted to use it and so save so time and errors.
What happens once you’ve got those first scripts?
You’ll realise that scripting enables you to generate tools that make your life easier and that others can also use. By then you’ve probably discovered the PowerShell community and seen what others are doing – so you learn a bit more about coding.
You adopt some standards – no aliases in scripts etc., etc. And you think about creating modules of advanced functions.
At this point you need to think about your coding style. I’m deliberately separating coding standards from coding style. Standards are what you do – style is how you do it.
We’ve used this style concept as the basis of the Iron Scripter competition at PowerShell Summit 2018. To help people divide themselves into teams we have three factions defined – http://ironscripter.us/factions/. The factions split on coding styles as much as anything. You can regard the differences between the factions as philosophical discussions if you prefer.
The factions can be summarised as:
- Daybreak Faction – beautiful code
- Flawless Faction – flawless code
- Battle Faction – good enough to get the job done
Battle faction is the easiest to understand. You have a solution to your problem. It works and gives the correct result in a reasonable time frame. Job done. Next task. if it breaks at some time in the future you’ll fix it then but in the meantime there’s a stack of other problems to solve.
This is the way many administrators work, at least to begin with. Working code doesn’t mean that the code is easy to maintain. If it breaks in the future you may not be the one to fix it – so the code needs to be readable and understandable. Daybreak faction with their view that code should be beautiful take this to the extreme.
Ideally, your code shouldn’t break. The idea of flawless code is at the heart of Flawless faction who believe in doing everything possible to ensure that the code will run. Beauty has its place but beautiful code that doesn’t work is wasted time and effort.
The three factions are stereotypes and extremes but there is an extremely valid point to them. Imagine an equilateral triangle that has a faction at each point. Your code will sit somewhere in that triangle with varying influences of battle, flawless and daybreak factions.
Does all your code sit at the same place in the triangle? Sometimes good enough will do and you can move on to the next task. Sometimes the code just has to run so you need a lot of flawless influence.
All the code you produce doesn’t have to have the same influences but knowing when to be putting on the style – and more importantly which style – could arguably make you a better coder and make your life easier.