Parameter and Variable naming - CamelCase

Welcome Forums General PowerShell Q&A Parameter and Variable naming - CamelCase

This topic contains 4 replies, has 5 voices, and was last updated by

10 months, 2 weeks ago.

  • Author
  • #103799

    Topics: 5
    Replies: 0
    Points: 13
    Rank: Member

    A co-worker reviewing my code stated variable names should follow this case convention:

    For parameter names:


    For regular variables:

    $computerName = 'DC001'
    $portNumber = '80'

    Is this correct? Is there an official 'PowerShell' convention. Or is consistency key?

  • #103802

    Topics: 13
    Replies: 4872
    Points: 1,811
    Helping HandTeam Member
    Rank: Community Hero

    That's a personal or company style. Doesn't matter at all to PowerShell, technically. However, you'll see that PowerShell native commands tend to follow that pattern, so it's not a bad idea to also follow that pattern.

  • #103810

    Topics: 2
    Replies: 426
    Points: 825
    Helping Hand
    Rank: Major Contributor

    For parameters in general, sure. If you want the closest thing we have to an 'offical' style guide, that's over here:

    It's by no means a mandate. You can code in the style that's best for you. I would advise you pick a style that is readily comprehensible for you. I'd conjecture that for most people that means: minimal aliases, clear and consistent casing systems, and consistent indentation and brace patterns. The minute details of that... are up to you. The above style guide's recommendation is basically "PascalCase All The Things" except for language keywords. In other words, all variables, parameters, functions, class names, method and property names, etc., are all PascalCase.

    The exceptions are language keywords and operators. So things like the function, filter, workflow, enum, class, for, foreach($i in $n){}, switch, if and else, keywords — and -eq, -ne, -match, -replace, etc., operators are all lowercase.

    I personally tend to follow this fairly thoroughly, so my code ends up looking like (cramming all the examples in that I can, hah!)

    I personally like how this style draws a clear distinction between everything. I find camelCase to be... a bit harder to read, honestly. This allows me to just glance at what's going on and get a solid grasp of what the intent of the code is.

  • #103870

    Topics: 0
    Replies: 669
    Points: 0
    Rank: Member

    Not using aliases is a best practice

    The rest is style.

    I tend to use lower case for variables and use tab completion to case cmdlets and parameters.

    Its better to be consistent and you be comfortable with what you're doing than blindly try to follow someone else's style guide. It doesn't matter what style you adopt someone somewhere will object to it

  • #103897

    Topics: 12
    Replies: 215
    Points: 381
    Helping Hand
    Rank: Contributor

    As already said there aren't any rules per say.
    I think the only thing that people will agree on is that you don't mix and match styles for the same thing.
    E.g. having Pascal Case for one parameter and then Camel Case for the second.

    It's probably more important to speed up reading the code once you have larger projects.
    E.g. maybe private methods will use one style compared to public methods.
    Constants are usually all upper case and so forth.

The topic ‘Parameter and Variable naming - CamelCase’ is closed to new replies.

denizli escort samsun escort muğla escort ataşehir escort kuşadası escort