Naming fields

[Gary Moore]

Micah pointed out that when I speak of (and document) properties on tickets, I speak in caps and underscores:

SOLD
BASE_PRICE
SOME_LONG_PROPERTY

But when I deal with other components (transactions and payments, for example) I speak in camel case. See: http://github.com/fracturedatlas/ATHENA-Helpers/tree/master/transaction/

We all agreed that it doesn't matter too much which is which, but we should be consistent with client facing interactions. Anyone have a preference either way? I'm vote for camel case.

--
Gary Moore | gary....@fracturedatlas.org | @gsmoore
Fork us on Github: http://github.com/fracturedatlas/
Join us on IRC: ##athena on irc.freenode.net

[Micah L. Frost]

I would vote camelCase over ALL_CAPS. I've done some aliasing on the client side to match someVariable to some_variable so that my Ruby code follows Ruby convention. If we got all camelCase, then that aliasing can be abstracted out a bit to apply to all ATHENA interactions.

Micah

SOLD
BASE_PRICE
SOME_LONG_PROPERTY

--
Visit: http://athena.fracturedatlas.org/tix
Fork: http://github.com/fracturedatlas
Chat: ##athena on Freenode

You received this email because you are subscribed to the "ATHENA Tix Developers" group on Google Groups.

To post, email: athena-t...@googlegroups.com
To unsubscribe, email: athena-tix-dev...@googlegroups.com
For more, visit: http://groups.google.com/group/athena-tix-devel?hl=en