Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rename functions to their proper case on Format #1112

Closed
PrzemyslawKlys opened this issue Dec 16, 2018 · 9 comments · Fixed by #1117
Closed

Rename functions to their proper case on Format #1112

PrzemyslawKlys opened this issue Dec 16, 2018 · 9 comments · Fixed by #1117
Assignees

Comments

@PrzemyslawKlys
Copy link
Contributor

PrzemyslawKlys commented Dec 16, 2018

Summary of the new feature

I sometimes type functions like get-childitem. I sometimes copy it from Internet like that. I like my code to be nice looking. Would it be possible to rename functions to their proper case variant on Format? For example Get-ChildItem.

Proposed technical implementation details (optional)

A clear and concise description of what you want to happen.

@bergmeister
Copy link
Collaborator

There have been similar requests, like e.g. #767 and in another issue that I cannot find right now. I have never considered it to be of importance and left open to the community as 'up for grabs'. Sometimes, I'd like that features as well myself. Technically it should be relatively easy by just calling Get-Command in a runspace under the hood. As I have a bit of spare time this weekend, I might give it a try.

@PrzemyslawKlys
Copy link
Contributor Author

While you're at it, maybe it would be possible to expand on aliases and do the replacement for Aliases as well? People tend to use % or things like that and it's a bit hard to understand for beginners (and probably slower?). Having expanded FT to Format-Table would be cool.

What would be totally cool (and probably performance improving) would be expanding parameter names or even giving ones.

For example:

$Value | ft -a
Write-Host "Test"
# to
$Value | Format-Table -Auto
Wrtite-Host -Object "Test"

But I guess that's much harder to fix ;-)

@bergmeister
Copy link
Collaborator

PSSA can already fix cmdlet aliases since v 1.17.1 using the -Fix switch and VS-Code has it as well. I'd have to check but I think parameter names are not included though.

@PrzemyslawKlys
Copy link
Contributor Author

I don't see that as an option in VSCode. Where can I find it?

@bergmeister
Copy link
Collaborator

If you click where the green squiggly is, then a lightbulb will appear that offers fixing it for you, sometimes you have to click a few times or be patient though:
image
Alternatively, you can also just call Invoke-ScriptAnalyzer -Path $path -IncludeRule PSAvoidUsingCmdletAliases -Fix if you need more automated fixing.

@PrzemyslawKlys
Copy link
Contributor Author

I see, I was thinking it would be added as a Formatter. so when you format it replaces everything automatically. I had to disable this feature you describe due to problems PowerShell/vscode-powershell#1593 and I believe one is related to other, right?

@bergmeister bergmeister self-assigned this Dec 20, 2018
@bergmeister
Copy link
Collaborator

No, AvoidUsingCmdletAliases is a code analysis rule but we could consider making it a formatting rule but I'd have to be disabled bu default because many people do not like this rule. Your issue seems to be an issue of the PowerShell extension, there is not much we can do here, I should add that the next version of PSSA will have better performance, which might help you with opening and formatting big files.
P.S. Today, I got the first prototype working that corrects the case but getting it in will be a bit tedious as I'll need to make 3 PRs: Here, in vscode-powershell and PowerShellEditorServices
image

@PrzemyslawKlys
Copy link
Contributor Author

PrzemyslawKlys commented Dec 20, 2018

That's great! Take your time!

I'm fine with it being disabled by default as long as we get this in settings. Actually, I wanted to ask why PSScriptAnalyzer Rules are not part of settings but you need to access them in a special way?

image

Can't this be integrated? It's not really "easy" to find and I actually found it by accident. I don't even know where's saving things.

On a separate note, If you can "convert" all those avoid into formatter (where it makes sense) and give an option to the user for a replacement that would be a really cool feature. I can open Issue if you want to track it separately or maybe it's needed somewhere else? I often use if ($something -eq $null) and it would be great if I wouldn't have to go and fix 500 scripts manually ;-)

As for performance that's surely needed. I believe I've been hitting both perf issues and the issue I've mentioned above a lot.

@bergmeister
Copy link
Collaborator

bergmeister commented Dec 20, 2018

PSScriptAnalyzer settings can be configured using e.g. powershell.scriptAnalysis.settingsPath pointing to a PSSA settings file, see here for a full end-to-end integration. The UI that you show should not be used because it is a known bug of the PowerShell extension, see e.g. here

As I said, you can already use the new -Fix parameter to fix files automatically (where the rule can do that as e.g. for PSAvoidCmdletAliases, the specific rule that you mention does not provide an auto-fix suggestion yet as this is quite tricky, feel free to create an issue or a PR to make the rule calculate a correction that could be picked up for auto-fixing). Code analysis rules and formatting are separated at the moment, not only would one need to add new settings to the extension, I believe some low level code of Invoke-Formatter would need adaption as well.
If you already want to try out the improved performance, then you can just build the development branch locally yourself and replace your installed module with that (I can give you a zip as well if you prefer that)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants