what is our policy with naming abstract operation parameters?

[michaelficarra]

We seem to use TitleCase and camelCase fairly arbitrarily for parameters in abstract operations. At first I thought that TitleCase might be reserved for parameters that are parse nodes, but that doesn't seem to be true. Should we consistently use TitleCase or camelCase throughout? Should we do the same to named aliases in the algorithm steps?

[ljharb]

Can you provide a few conflicting examples?

I doubt there’s been a reigning convention, but I’d expect PascalCase to apply to Parse Nodes and constructors, and probably a few other things I’m not recalling atm.

[michaelficarra]

@ljharb You don't have to look far.

FunctionInitialize ( F, kind, ParameterList, Body, Scope )

F is a function object. kind is an enum. ParameterList and Body are parse nodes. Scope is a Lexical Environment.

FunctionDeclarationInstantiation ( func, argumentsList )

func is a function object. argumentsList is a List of ECMAScript language values.

[[DefineOwnProperty]] ( P, Desc )

P is a property key (I think an ECMAScript language value). Desc is a property descriptor.

[[Set]] ( P, V, Receiver )

P, V, and Receiver are all ECMAScript language values.

It goes on and on.

[devsnek]

The pattern I follow is:

• caps for single-letter
• caps for required MOP params
• caps for productions
• lowercase everything else

There are definitely inconsistencies though.

[ljharb]

Happy to decide on a pattern, codify it, and fix inconsistencies.

[michaelficarra]

I would prefer to just camelCase everything. I could see using a different naming scheme for parse nodes, but anything more is just too much for my taste. If we really wanted useful information available in that position, we would add some kind of type signature.

[bakkot]

we would add some kind of type signature

(cf https://github.com/tc39/ecma262/pull/545)

[ljharb]

Casing is useful information.