The current solution to options arguments is lame. Firstly we don't base our key names on those in the HTTP API spec because that goes against JS naming conventions (= more unimportant details for developers to remember), secondly, we don't standardize the HTTP API spec key names to camelCase because of the terrible results entailed: subscriberId, durationMs, etc.
So we lose either way: unique names to learn, difficult-to-read names.
However there's a third way: support both. This has several benefits:
developers insisting on camelCase can do so (ugly, but their choice)
developers favouring readability can use snake_case (non-standard style, but their choice)
important: a _pattern_ is defined for converting HTTP API options key names, _nothing unique to learn_
The current solution to
options
arguments is lame. Firstly we don't base our key names on those in the HTTP API spec because that goes against JS naming conventions (= more unimportant details for developers to remember), secondly, we don't standardize the HTTP API spec key names to camelCase because of the terrible results entailed:subscriberId
,durationMs
, etc.So we lose either way: unique names to learn, difficult-to-read names.
However there's a third way: support both. This has several benefits:
options
key names, _nothing unique to learn_