Naming conventions: `camelCase` vs `separate-words`

[carlesjove]

In issue #12 , a subtle decision is introduced: the use of camelCase for multiple word properties. Maybe it'd be a good idea to have some naming conventions at the spec, so authors of extensions follow it and clients know exactly what to expect.

[carlesjove]

I vote for separate-words

[mamund]

i'd like to keep as much fidelity between internal code modeling and external message modeling. this is not a requirement, but something i'd like to keep an eye upon.

i prefer not using dashed names since it adds some "cruft" in coding for the properties. while JS allows this using brackets, i know of no other language that supports "dashes" in property/variable names.

1. read-only
2. readOnly
3. readonly

are the basic options. i'd be ok w/ 2 or 3.

and i understand we're dealing with style here and setting a precedent. it's worth discussing.

comments?

[mamund]

it's been close to a week since i responded to this item. i'd like to close this up in order to move on teh actual implementation of the "read only" property marking for items.

does anyone want to actually discuss this?

[carlesjove]

I'd just add that camelCase seems the best option to me, after what you
said.

On Wednesday, March 11, 2015, Mike Amundsen notifications@github.com
wrote:

it's been close to a week since i responded to this item. i'd like to
close this up in order to move on teh actual implementation of the "read
only" property marking for items.

does anyone want to actually discuss this?

—
Reply to this email directly or view it on GitHub
#13 (comment).

[mamund]

@carlesjove

ok, thanks.

unless i hear more on this, i'll write up some notes in the extensions section advising the preference for camelCase in all future extensions.