couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Hahn <m...@boutiquing.com>
Subject Re: Naming conventions
Date Fri, 26 Aug 2011 19:32:01 GMT
Since I'm using nothing but javascript with couch I use only camelCase.

On Fri, Aug 26, 2011 at 12:16 PM, Jon S <jon3638@live.com> 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
>

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