couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Hahn <>
Subject Re: Naming conventions
Date Fri, 26 Aug 2011 19:33:43 GMT
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 <> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message