SeeminglyScience / EditorServicesCommandSuite

Collection of editor commands for use in PowerShell Editor Services.
Other
152 stars 13 forks source link

ConvertTo-SplatExpression - parameter to choose variable name capitalization #58

Closed phoerr closed 4 years ago

phoerr commented 4 years ago

On my team at work, we write a lot of PowerShell and have found ConvertTo-SplatExpression very helpful. However, we've also standardized on a naming scheme that says our variable names should begin with an uppercase letter.

From the documentation example for ConvertTo-SplatExpression, instead of a variable name $getChildItemSplat, we'd like to see the name $GetChildItemSplat (with a capital "G").

In the previous version (0.4.0), I was able to modify the code myself. Seeing as how this will be a compiled DLL in verion 1.0.0, I wanted to put in an issue to see if we could have an option to change this.

I'm going to submit a pull request to show an idea I had of adding a new parameter that would allow the user to choose their variable name case.

SeeminglyScience commented 4 years ago

That's a reasonable request, I'll try to slip it in the next preview. I'll add it as a setting (settable at workspace, user, and machine level).

Thanks for the suggestion!

Settings file looks like this currently (click to expand) ```powershell @{ # The relative path from the current workspace to the root directory of the module. # MainModuleDirectory = '.\module' # The relative path from the current workspace to the main module manifest file. # SourceManifestPath = '.\module\*.psd1' # The relative path from the current workspace to the string localization psd1 file. # StringLocalizationManifest = '.\module\en-US\Strings.psd1' # The relative path from the current workspace to the directory where markdown files are stored. # MarkdownDocsPath = '.\docs' # The relative path(s) from the current workspace to the directory(ies) where functions are stored. # FunctionPaths = '.\module\Public', '.\module\Private' # The string used to created line breaks. Defaults to "[Environment]::NewLine" # NewLine = [Environment]::NewLine # The string used to created indents. Defaults to four spaces. # TabString = ' ' # Specifies whether namespaces will automatically be removed when writing type literal # expressions. Removed namespaces will be automatically added as a using statement. # EnableAutomaticNamespaceRemoval = $true CommandSplatRefactor = @{ # The variable name to use when creating the splat expression variable. The default behavior # is to name the string similar to "getCommandNameHereSplat". Setting this to $null will # enforce the default behavior. # VariableName = $null # Specifies whether a new line should be placed between the hashtable and the original command # expression. # NewLineAfterHashtable = $true # Specifies if additional parameters that have not been should be added to the splat # expression. The following options are available: # "None" - Only bound parameters. This is the default. # "Mandatory" - Mandatory parameters that have not yet been bound will be added. # "All" - All resolved parameters will be added. # AdditionalParameters = "None" # Specifies whether the value for additional unbound parameters should be a variable of the # same name as the parameter, or if it should be decorated with mandatoriness and parameter # type. # $true - Path = $path # $false - Path = $mandatoryStringPath # ExcludeHints = $false } ExpandMemberExpression = @{ # AllowNonPublicMembers = $false } UsingStatements = @{ # Specifies whether groups of using statement types should be separated with a new line character. # SeparateGroupsWithNewLine = $true # Specifies whether using statements that start with "System" should be ordered first # regardless of alphabetical order. # SystemNamespaceFirst = $true # The order in which groups of using statement types will appear. # UsingKindOrder = 'Assembly', 'Module', 'Namespace' } } ```
phoerr commented 4 years ago

That'd be great. I like the approach of using a setting versus adding a parameter.

I'll give the next preview a try when it's available.

Thanks!

SeeminglyScience commented 4 years ago

I have the changes in a preview build available here. Note that this only works with the preview version of the PowerShell extension currently.

If you run New-CommandSuiteSettingFile in the workspace you want to add settings for a file will be generated (or use the -Scope parameter to specify per user or machine). You may need to reload the window after making changes to the setting file. You're looking for a setting like this:

        # Specifies the case style to use for generated variable names.
        #     'CamelCase' - $getChildItemSplat. This is the default.
        #     'PascalCase' - $GetChildItemSplat
        # VariableCaseType = 'CamelCase'

I'll close this once it makes it to a published release.

phoerr commented 4 years ago

This is working great for me! I downloaded that build, and with VS Code 1.45.1 and the PowerShell Preview Extension v2020.6.0-preview, it's doing exactly what I what.

My settings:

        # Specifies the case style to use for generated variable names.
        #     'CamelCase' - $getChildItemSplat. This is the default.
        #     'PascalCase' - $GetChildItemSplat
        VariableCaseType = 'PascalCase'

I tested with the settings file in the Workspace, User, and Machine scopes, and they all behaved as expected.

SeeminglyScience commented 4 years ago

Fantastic! Thank you for testing so thoroughly ❤️

SeeminglyScience commented 4 years ago

Included in v1.0.0-beta3, thanks again!