After using PowerShell for over a decade, I have started to get better about organizing my coding projects. In the past my laptop would be scattershot with directories and temp files in a lot of different places (and still do …). However, I have started a process of getting better about putting files in locations that make sense. For now, my larger scripts are in a directory called ‘_PowerShellProjects’. Under here I have subdirectories for each project I am working on.
Organizing Scripts by Folder
My working folders:
Why do this? Well, at first creating scripts and remember where everything is located tends to be an easy process. However, this only lasts so long. Either we end up creating too many scripts or we forget where we put our scripts. Searching works about 50-60% of the time in my experience and this means we lose time and energy trying to find something we need. Organizing the scripts into directories will help.
Now the above folder structure show above is just the first level. Most of the folders have multiple subfolders to help differentiate out different scripts or project types I have going on. The more granular the folder structure, the easier it will make it for you to find your prewritten scripts.
DEV / QA of Scripts?
Now what about when you are developing code? Do we necessarily want to put the working code into the same directories as our tested code above? Maybe not. In my case I use a set of folders under a QA directory. This area tends to be less managed and a bit more sloppy than the final code directories above. I’m just not that disciplined yet in keeping the directories as clean. However, I still organize the structure based on what I am doing.
For example, if I am working on a script for a client, I will make a subdirectory just for that client under the QA directory so I can perform testing without overwriting any other work. If I am working on a script for a particular area, like .NET, then I will create a directory for that topic as well.
While testing I may also create subdirectories for each test run I am working on so I can keep track of the runs and differences between run (results and code). This help me backtrack if something is broken or if a feature I was working on was removed and I want it back.
Conclusion
In the end, what you should do as a PowerShell coder is find a way to organize your scripts so that you don’t lose track of your code. Hopefully this will lead to more time coding and less time searching for code you have already created.
In a future blog post I will talk about how to secure your files and control versioning.
