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

Add rule: Variable names should use camelCase #381

Open
KarolKaczmarek opened this issue Nov 25, 2015 · 5 comments
Open

Add rule: Variable names should use camelCase #381

KarolKaczmarek opened this issue Nov 25, 2015 · 5 comments

Comments

@KarolKaczmarek
Copy link
Contributor

https://github.com/PowerShell/DscResources/blob/master/StyleGuidelines.md#variable-names-should-use-camelcase

@Jaykul
Copy link
Contributor

Jaykul commented Nov 28, 2015

No, they absolutely should not. Nobody should try to enforce case on entity names in PowerShell.

Camel case variable names are a legacy rule. It comes from languages which are case sensitive, and where you can refer to class members like methods, properties, and variables without needing $this -- in C and C# and Java it's possible to look at a method and not be able to tell a reference to a class property from a class variables. That is obviously not the case in PowerShell, so there's obviously no need for any naming conventions to distinguish the two.

@rkeithhill
Copy link
Contributor

I agree with @Jaykul that PSScriptAnalyzer should not try to dictate any sort of casing style. That said, I would be OK if the rule existed but was not enabled by default in any ruleset. If an individual or a team wanted to use the rule, they would need to enable the rule in a custom ruleset. Hmm, pehaps a rule like this would be a better fit as a "community" rule?

FWIW I tend to use camelCase for function local variables. This helps me distinguish locals from parameters and global/script scope variables.

@Jaykul
Copy link
Contributor

Jaykul commented Dec 4, 2015

Yeah, I have no problems with rules like this existing in a library of rules, at a minimum as an example so people can customize it. Certainly some projects and code repos will want to be able to enforce code style stuff like this as part of their tests on pull requests (plenty of repos do similar things on other languages).

I would note that it enforcing this usefully requires a built-in dictionary and probably project dictionaries so a team (or user) can add/remove words..

@Jaykul
Copy link
Contributor

Jaykul commented Mar 7, 2016

Can we label issues for rules like this such that it's clear they would be shipped if implemented but wouldn't run by default? Considering how few outside people are contributing to this, perhaps a label would help prioritize effort.

@bergmeister
Copy link
Collaborator

I agree that this should be just an optional rule but to me the only case that I would find useful is to have function parameter names only start with an uppercase.

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

No branches or pull requests

5 participants