Standard

Should we use snake_case in WordPress JavaScript?

Let’s start a discussion about WordPress JavaScript coding standards.


This is an age-old discussion that extends way beyond the realms of both WordPress and JavaScript, but I have always been a fan of snake_case over CamelCase. There is no refute that in regards to legibility, snake_case takes the cake. No matter how you slice it.

The current WordPress standard for PHP is snake_case, yet the standard for JavaScript is CamelCase. While this may not be an issue for most full-stack WordPress developers, developers that are usually focused on one language may have a tedious time remembering to change their coding habits completely in order to write a different the other. Which will cause inconsistency.

Besides, would it not be much more efficient to have one naming convention for all sets of code on the project?


I have always preferred snake_case and push everyone I know to write JS in snake_case; however, it is not so easy to change a standard (for good reason).

So please, take this short poll and let’s see where we stand.


2 Comments

  1. tywayne · April 23, 2015

    I’m sure you’ve encountered my opposing argument before, but I’m interested in your take on it.

    From my understanding, the WP standards are the way they are to maintain consistency with external JS libraries used. Since the standard for jquery, underscore, backbone, etc is camelCase, it would make sense to maintain consistency within the specific language.

    Your question of “Besides, would it not be much more efficient to have one naming convention for all sets of code on the project?” is legit, and I would love for that to be possible – but it isn’t because the external libraries differ.

    I find it be easier to remember that PHP uses snake_case and JS uses camelCase, than to open a JS file and see mixed case within a single file.

  2. Justin Kopepasah · April 23, 2015

    I am not sure if the current standards for WordPress JavaScript are set to maintain consistency with external libraries or because most JavaScript, especially legacy JavaScript, is written in CamelCase. There are some PHP libraries in WordPress that use CamelCase as well, but that does not stop us from setting a standard for snake_case in PHP.

    Overall, I do not feel that the libraries are the cause, but rather the preference of the developers of the time.

    Obviously we should not change the current JavaScript if we set the standard for snake_case. This would cause many issues in regards to backwards compatibility. But moving forward I feel that snake_case provides a readability aspect that CamelCase cannot provide. For example, model_instance vs modelInstance. Thankfully monospace helps with this issue, but you get the idea.

    I find it be easier to remember that PHP uses snake_case and JS uses camelCase, than to open a JS file and see mixed case within a single file.

    Would you not find it even easier if everything was one standard? 😛