Parameter and Variable naming - CamelCase

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

For parameter names:

[Parameter(Mandatory=$True)]
[string]$ComputerName,

[Parameter(Mandatory=$False)]
[int]$PortNumber

For regular variables:

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

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

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.

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.

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

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.