-1

I'm working with JavaScript and PHP right now. My JavaScript uses camelCase while my PHP uses under_score for variable/object/array naming.

I often have JavaScript send data to PHP. In fact it's specially made to send to PHP.

So, my question is, should I write the data being sent to PHP by JavaScript in camelCase or under_score?

Also vice versa.

Heres an example

Javascript -> PHP

var fooBar = {firstName:"Daenerys",lastName:"Targaryen",titles:{...}};

PHP receives

var foo_bar = $_POST['fooBar'];

// this is where the problem arises
foo_bar['firstName'];
foo_bar['lastName'];

Edit: It's not a duplicate because I'm not asking whether the code should have the same code conventions, but which code convention takes precedence when communicating between each other.

Trevor Wood
  • 101
  • 4
  • Possible duplicate of [Should naming conventions be consistent or not across multiple programming languages in one project?](https://softwareengineering.stackexchange.com/questions/273096/should-naming-conventions-be-consistent-or-not-across-multiple-programming-langu) – gnat Jun 23 '18 at 01:29

4 Answers4

3

The naming convention sent across the network is irrelevant. Just pick a convention and stick with it.

Each client can deal with the data directly, but in many cases building a layer of abstraction on top of those API calls is good practice. Mapping the API response to another object can rectify the naming convention differences.

JavaScript is the client, and PHP is on the server, therefore camelCase is perfectly fine. JavaScript will be consuming the data, and camelCase is the convention.

Things get murky when your server code services multiple clients in different tech stacks. So you start out with JavaScript. Then you add a Java Android application. Using camelCase still makes sense, because that's still the convention with Java.

But then you add a C# web application as a client of your PHP application. Now PascalCase is the convention. And throw in a Ruby web API for good measure, and we are back to snake_case again.

So it doesn't really matter what you pick, just be consistent.

Greg Burghardt
  • 34,276
  • 8
  • 63
  • 114
  • I'm not fond of the idea of creating a layer of abstraction solely to reconcile naming convention inconsistencies. – Robert Harvey Jun 23 '18 at 02:53
  • @RobertHarvey: Me neither. The layer of abstraction should be about an abstraction, not a naming convention. It's just that if you need a layer of abstraction for other reasons, use the naming conventions that go with the tech stack you are working with, thus hiding any descrepencies that come over the network. – Greg Burghardt Jun 23 '18 at 13:09
2

There is no correct answer here. You will find as you use different tools from different vendors (or even from the same vendor, but with different heritages) that you will run into this problem. The best you can hope to do is be consistent in what you are writing.

If this is a major problem, you can always make named constants (which you should do regardless) that change it. For example in PHP, do this:

define("first_name", "firstName");
...
foo_bar[first_name]; // Or whatever the appropriate syntax would be
user1118321
  • 4,969
  • 1
  • 17
  • 25
2

JSON is short for "JavaScript Object Notation" which clearly identifies it in the JavaScript domain, so JSON should use JavaScript camelCase. Even if your server is written in a language which uses Pascal case or underscores, it would be expected to work with JSON in its specific format, using its conventions.

Similarly, if your server is rendering CSS, you'd use lowercase with hyphens, consistent with CSS naming conventions. Same for any other platforms your server will come in contact with, e.g. your HTTP verb should always be in upper case.

John Wu
  • 26,032
  • 10
  • 63
  • 84
0

You often have 1 server, 1 API and multiple clients written in different languages, but it's unlikely to have 1 client, 1 API and multiple servers written in different languages.

Therefore it's almost always more sensible for the server to define the API. Naming conventions of variable names on the API are part of the API.


Unfortunately that doesn't answer your question. Even though the server side defines the API, you may still decide that the API should use different naming conventions than the internal server representation - if you find that there's a tangible benefit in doing so. For example, you might prefer camelCase for a public API used by casual users which are more likely to get confused by multiple naming conventions in their codebase. Depending on the exact use case and support costs, you might even decide to support camelCase, under_score, and PascalCase, and automatically convert to the internal representation.

For simplicity, I recommend "leaking" the server side naming conventions, unless you can define a tangible benefit in not doing so for your specific use case.

Peter
  • 3,718
  • 1
  • 12
  • 20