Script organization (all my functions clutter my script)

Question

I have a big script that I am now clearing with functions. But I found that it is becoming useless to put them all at the top of the script .. I need to scroll through hundreds of lines of code to get to the script itself ..

How do you guys keep your scripts in order? Do you have your own functions in a separate file?

Answer 1

Try #Region and #EndRegion

If you use the PowerGUI script editor, you can use the following regions:

#region Set of functions A function foo { Write-Host "Just a function" } function bar { return "Just another function" } #endregion 

When you open the script in the PowerGUI script editor, the regions will be collapsed, so you do not need to scroll to go to the main logic. It also works in Microsoft ISE. However, not all script editors tag region tags.

Try to find the source or import it as a module

Another way is to push your functions either into another script, and do what is called dot sourcing . C:\myfunctions.ps1 . C:\myfunctions.ps1 , or put them in a module file with the extension .psm1 and use Import-Module .

Answer 2

A useful method is to include the entire script in a function:

 #!/bin/sh main() { # The majority of the code is here } foo() { # auxiliary functions go here } main " $@ " # invoke the main function 

I just noticed that this question was marked by powershell , while the above example is for Bourne. This method is probably valid, but the syntax may be different.

Answer 3

Try the modules

The technique we use is to ensure that all our functions are loaded through the script module. We created a folder to store all the individual function files and further subdivided them into the appropriate categories. Once we have done this, we create a .psm1 file to tell the module what to load, and then add the module path to our PowerShell profile (if not at the default module location).

Folder structure

 Module-Name\ Subfolder1\ Subfolder2\ ... Module-Name.psm1 

.psm1 file

Module-Name.psm1 (located under the folder with the same name - required)

 # Script Module for Company Functions Function Get-ScriptDirectory { # $MyInvocation is an Automatic variable that contains runtime details and # we can use this to get information about where the file is run from. $Invocation = (Get-Variable MyInvocation -Scope 1).Value Split-Path $Invocation.MyCommand.Path } Get-ChildItem (Get-ScriptDirectory) -Recurse ` | Where-Object { $_.Name -like "func_*" } ` | %{ . $_.FullName } 

File profile

Microsoft.PowershellISE_profile.ps1 / Microsoft.Powershell_profile.ps1

 $LocalLibraries = "C:\Local\Path\On\Disk\" $env:PSModulePath = $env:PSModulePath + ";$LocalLibraries" 

The code above means that you do not need to store the module in the same place as the rest (useful in our case, since we use SVN for the version and transfer our materials to our team).

Summary

Repeat:

• Function file name as "func_ {Verb} - {Namespace} {Exist.}. Ps1"
• Create a top-level folder to store the module psm1 file
• Create subfolders to categorize and store features, such as Utilities, Active Directory, Exchange, etc.
• Create the file "psm1"
• Optional: add an additional module location to your profile

We attach the “ps1” files with “func_” so that when filling in the name of the function, if it is in the same directory as the file, it will not get confused. In addition, we add a namespace (company initials, etc.) in front, so that our function names do not interfere with other added functions.

Convenient reboot function

Another useful tip that may come in handy during development is to define the alias "reload" in our case, which will cause the module to reboot. This means that after you have changed the file, all you have to do is print it and it will be automatically added to the memory with your changes.

 # Function to reload Module Function int_ModuleNameModuleLoad { Import-Module Module-Name -Force -WarningAction SilentlyContinue Write-Host "Module-Name Reloaded" } # Set Aliases If (-not(Get-Alias "reload" -ErrorAction SilentlyContinue)) { New-Alias -Name reload -Value int_ModuleNameModuleLoad -Force } 

The reason I use "int_" instead of our usual naming structure is because this function is inside our profile, and I consider it to be an internal rather than a complete function.

Hope this gives you some good ideas, it worked out great for us!

-Adam

Answer 4

One thing to keep in mind is the scope. This will not work:

 function main{ function1 function2 function3 } function load-functions{ function function1 {"This is function1"} function function2 {"This is function2"} function function3 {"This is function3"} } load-functions main 

The load-functions function will have its own region, and the functions created by it will exist only in the local region. They will disappear when the function ends and the area is deleted.

You need to run those located in the local area using dot-sourcing the following functions:
(Note that there is a space between the period and the function names.)

 function main{ function1 function2 function3 } function load-functions{ function function1 {"This is function1"} function function2 {"This is function2"} function function3 {"This is function3"} } . load-functions . main 

It will work if main not executed in the local scope, but if you pass arguments to the script, you will need to do this to use $args in the script scope.

Answer 5

Another possible solution is to split the functions into separate files and pack them in the form of a module. Then you can simply import the module into the main script.

You end up with several .ps1 files, but this simplifies the management (and testing) of each individual function.

Webcast on how to do this (about 1/2 inch):

[http://powershell.com/cs/media/p/8773.aspx] [1] [1]: http://powershell.com/cs/media/p/8773.aspx

It also includes a handy module for creating modules.