Jump to content
NotionCommotion

JSON naming convention

Recommended Posts

I am sure I've asked this or a similar question before, and expect received "personal choice", "it depends" and "most importantly be consistent" as answers.  Unfortunately, with so many conflicting recommendations (i.e. Google uses CamelCase, Facebook and Twitter use snake_case, etc), I haven't cemented down my personal choice thus am not as consistent as I should be, so would like to see whether "it depends" might bring consistency.  Several potentially influencing factors are:

  1. I am using Symfony's serializer to serialize and will likely later use it to deserialize.
  2. My SQL column names use snake_case.
  3. I am okay with exposing some SQL column names in the JSON.
  4. While I am using Symfony's serializer, I am not currently using Symfony (I think Symfony promotes CamelCase but am not sure whether this has any impact).
  5. I am obviously using PHP.

Based on the above, one benefit of using snake_case is I will not need to rename all the serialized names.

<property name="some_sql_column" serialized-name="someSqlColumn"/>

As such, I am thinking of standardizing on snake_case.  Any strong reasons to do differently?

Share this post


Link to post
Share on other sites
Posted (edited)

You pretty much covered it in the first sentence so I will just tell you what my standard is.

snake_case = DB Columns, Variable Names & Function Names (same as Php. i.e:  set_exemption_handler)

camelCase = OOP methods, method calls, & OOP Properties

PascalCase = Class Names. (i.e: class UserAccount)

dash-seperator = Filenames (For SEO i.e: my-file.php)

Edited by benanamen

Share this post


Link to post
Share on other sites

Thanks benanamen,

Seems like a reasonable standard, and I mimic most of it.  I am less worried about variable names and have previously made no attempt to standardize but surely should.

Does JSON property names full under your OOP Properties standard?

Share this post


Link to post
Share on other sites

I pretty much never use snake_case as I hate the style of it.  I tend to use camelCase in most cases as it's generally valid anywhere and I find it most readable.   For classes and DB columns I use PascalCase as I prefer the initial capital letter.  In places where I can, I like using - as a separator but that doesn't work in many instances due to syntax / alphabet restrictions.

So to summarize, for me it's:

  • camelCase = variables, property names, method names, array indexes, etc.
  • PascalCase = class names, DB column names, global function names
  • dash-separator = html attributes, css class names, id names
  • snake_case = basically never

The only kind of "bad" thing about my style is that I end up writing a lot of queries like

SELECT
    s.StudentId as studentId,
    s.FirstName as firstName,
    s.LastName as lastName
FROM students s 

in order to get the preferred case for my array keys, but I don't really mind.  I could just make the db columns camelCase too but for some reason I don't really like that.  Aliasing everything in the query has the benefit of making things explicit and also consistent when I am going to end up aliasing some columns anyway to avoid a name conflict.

 

Share this post


Link to post
Share on other sites
2 hours ago, kicken said:

I pretty much never use snake_case as I hate the style of it.

I think you have the key for consistency.  You have to venomously despise  the others so there is only one choice!

2 hours ago, kicken said:

The only kind of "bad" thing about my style is that I end up writing a lot of queries like ... in order to get the preferred case for my array keys, but I don't really mind.

I had previously been doing the same, and similarly didn't mind doing so.  It was only when I started utilizing Doctrine and then soon after Symfony's serializer did I have issues.  I am really starting to question my decision to do so...

Share this post


Link to post
Share on other sites

I align almost exactly with @kicken except I use snake case for database, table, and column names, and - for whatever random reason - array keys. Couldn't explain the array key preference if I absolutely had to as I really do hate snake case. Unfortunately, I currently work with WordPress so I have see that crap daily...

Share this post


Link to post
Share on other sites
1 hour ago, maxxd said:

I use snake case for database, table, and column names, and - for whatever random reason - array keys.

My gads Max!  You call yourself a snake case hater?  No!  You don't belong and will never be a member of BOSCH (brotherhood of snake case haters).

Share this post


Link to post
Share on other sites

I forgot about the table names.  I do tend to use snake_case there, mostly because I think of them as the components as separate identifiers with a separator rather than a single name.  My tables end up being named similar to namespaces, eg

  • student
  • student_enrollment
  • student_program
  • student_paper
  • course
  • course_assignment
  • course_exam
  • ...

I'd prefer dashes honestly, but syntax rules don't easily allow that.

3 hours ago, NotionCommotion said:

It was only when I started utilizing Doctrine and then soon after Symfony's serializer did I have issues.

You can still have the different case setup with doctrine if you want, it allows specifying the DB column name and entity field name separately, that's what I'd been doing so far in most projects but over the last few months I've been considering just going with camelCase for the column name as well for simplicity.

Share this post


Link to post
Share on other sites
1 hour ago, NotionCommotion said:

My gads Max!  You call yourself a snake case hater?  No!  You don't belong and will never be a member of BOSCH (brotherhood of snake case haters).

I know - I can't stand snake case, but if it's an array key or database *anything*, my fingers just type it that way. Database tables and columns actually make sense to me because I have a tendency to prepend table names with "tbl_". In case I get confused, I guess. But "tbl_student" or "tbl_orders" reads easier to me than "tblStudents" and "tblOrders". And once you've got that established for table names, you might as well keep it going for the column names because then you don't have to think too much or type different patterns in the middle of custom MySQL statements. It makes perfect sense. Really.

The array key thing I can't even pretend to explain, it's just something I realized I was doing at some point.

I may have been dropped on my head as a child.

Share this post


Link to post
Share on other sites
8 hours ago, kicken said:

You can still have the different case setup with doctrine if you want, it allows specifying the DB column name and entity field name separately, that's what I'd been doing so far in most projects but over the last few months I've been considering just going with camelCase for the column name as well for simplicity.

I am unfortunately not quite as passionate as you and maxxd when it comes to case and it is not a major concern when it comes to Doctrine, but this is a different topic and I will create a new post.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.