-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Naming conventions: camelCase
vs separate-words
#13
Comments
I vote for |
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.
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? |
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? |
I'd just add that camelCase seems the best option to me, after what you On Wednesday, March 11, 2015, Mike Amundsen [email protected]
|
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. |
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.
The text was updated successfully, but these errors were encountered: