Phoenix naming convention for model attributes

[Brad O'Hearne]

Hey there....trying to keep myself in the "doing it right" column with Phoenix, and I've noticed that generators enforce naming conventions in some places (namely, the plural of the primary model in question), but not in other places (attribute names). This got me to looking into naming conventions in general. I'm sure this derives primarily from Elixir, which dictates the following: 

• variables, function names, module names, etc.: snake case.
• aliases: camel case. 
• atoms: snake case or camel case -- although in Elixir, snake case is the convention (??? then why camel case too?)

In Phoenix generators, it tolerates and allows camel case on model attributes, which if there's a hard convention (or there should be), I was curious why it was enforced in one place and not the other. I believe the answer is that model attributes manifest themselves in generated code as typed atoms, but then that was additionally curious to me, as apparently the preferred convention for atoms in Elixir is snake case. Is there a conclusive naming convention, and if so, what is it, and if it is snake case, why isn't this enforced (or suggested) in generator output? 

Thanks, 

Brad

[Brad O'Hearne]

It turns out this was actually a bigger issue than originally perceived, so I thought I'd post my conclusion to help anyone who comes along after and confronts the same question of naming conventions. 

I have a web app built on Phoenix Framework with both HTML and JSON -generated views / controllers, and using mongodb_ecto to talk to a MongoDB database. Restated: a web app that serves both HTML web pages and web services with JSON payloads, with a backend document-oriented MongoDB database. The question of naming conventions isn't just one which touches Phoenix, but rather touches all of the following, and their standards (or de facto uses):

• Elixir: Camel case for module names; snake case for function name, variable names, and identifiers; either camel case or snake case for atoms, though snake case is preferred.
• Phoenix: based on Elixir and follows its conventions, but snake_case results in better output from HTML view and template generators
• MongoDB: I haven’t found any official documented standard by the vendor, but official documentation appears to favor snake case. Traditionally, the database world also favors snake case.
• JSON: No specification naming convention standard that I could find. Many follow Google’s JSON naming conventions which dictate camel case, but others use snake case, and as document-oriented NoSQL databases typically use JSON as internal persistence structure, often favors snake case. 
• REST: virtually any question related to REST is a major flame war online...I tend to like to put my brain through the paces of figuring out the "right" thing to do, but enter the word "REST", and be prepared for transport to another pedantic dimension. Here's the rub: some prefer camel case, some prefer snake case, and others prefer (and demand that it is the only truly “RESTful” way) hyphenated words. There are debates about issues with unicode and case sensitivity (or not) for URLs / web servers. Best advice: think it through, form your opinion based on what makes sense. REST is broken in my view anyway.... (I can already smell smoke)

So taking into account all of this, and the fact that snake_case is either the standard / desired / compatible option in all cases (and seems to be the only one which is), and is the standard in the underlying programming language and framework, snake case appeared to be the best choice here, and in like Phoenix / Elixir web apps and their services.  Note that the best choice here doesn’t affect naming conventions elsewhere — not in Javascript, Java, C#, Swift, <fill in language here>, etc. Use camelCase or whatever is appropriate with any of those. I hope that helps sum up the issue and saves some time for someone down the road. 

Cheers, 

Brad

[benwil...@gmail.com]

I guess I just don't see this is being all that complicated. Module names are CamelCase. functions, other atoms, variables, etc are all snake case. If you interface with some external thing that expects something else or hands you something else, transform at the edge so that the inside stays nice and clean.

Phoenix doesn't have any additional conventions to add as far as I can tell.