One thing I hate in couch though is the naming of keywords. They have include_docs and startkey used together. Somebody was smoking something when they came up with that.
On Fri, Aug 26, 2011 at 12:16 PM, Jon S <[email protected]> wrote: > > I'm writing a webapp in Javascript that talks to CouchDB. Are there any > conventions for choosing field names? Should my documents have fields like > "red_ball" or "redBall" or "red-ball"? > > Seems like "red_ball" is the way to go, but then when I read JSON from > CouchDB into Javascript I have to either deal with a mix of naming > conventions or mangle the names manually (a la Rail's camelize()). > > Suggestions? > > > Here are my thoughts: > > * CouchDB's reserved fields (e.g., _revs_info) make me think that > underscores are standard. > * Mixing two naming conventions in one CouchDB document is confusing and > error-prone, so I should stick to _. > * But my JS code uses camel case, like everyone else's. If I directly read > underscored JSON from CouchDB, then my code will mix two different naming > conventions. Yuck. > * Or, I could rename fields when I read and write to CouchDB. Again, yuck. > * The CouchDB book offers no guidance on multi-word field names, as no > user-defined field in the book is more than one word long. The book uses a > dashed style ("hello-world") for db names, view names, show names, and _ids. > The book uses a camel case style ("function(newDoc, oldDoc, userCtx)") for > JS variable names. > * Jquery.couch.js is an inconsistent mix of underscore and camel case, even > in places (local vars, formal parameters) that never have to touch JSON. > > > Thanks, > Jon >
