Invio del codice camelCase al codice under_score

Question

Invio del codice camelCase al codice under_score

#1 da (3 voti)
#2 da (2 voti)
#3 da (1 voti)
#4 da (0 voti)

0

Sto lavorando con JavaScript e PHP adesso. Il mio JavaScript utilizza camelCase mentre il mio PHP utilizza under_score per la denominazione di variabili / oggetto / array.

Spesso ho JavaScript che invia dati a PHP. In realtà è fatto appositamente per l'invio a PHP.

Quindi, la mia domanda è, dovrei scrivere i dati inviati a PHP da JavaScript in camelCase o under_score?

Anche vice versa.

Ecco un esempio

Javascript - > PHP

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

PHP riceve

var foo_bar = $_POST['fooBar'];

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

Modifica: non è un duplicato perché non sto chiedendo se il codice debba avere le stesse convenzioni di codice, ma quale convenzione di codice ha la precedenza quando comunicano tra di loro.

variables naming

posta Trevor Wood 23.06.2018 - 02:52

fonte

4 risposte

Leggi altre domande sui tag variables naming

Come risolvere efficacemente l'associazione dei dati C # Come evitare codice duplicato con interfacce in cui gli oggetti hanno lo stesso comportamento

score 3 · Answer 1

La convenzione di denominazione inviata attraverso la rete è irrilevante. Basta scegliere una convenzione e seguirla.

Ogni cliente può gestire direttamente i dati, ma in molti casi creare un livello di astrazione in cima a tali chiamate API è una buona pratica. Mappare la risposta dell'API a un altro oggetto può correggere le differenze della convenzione di denominazione.

JavaScript è il client e PHP è sul server, quindi camelCase è perfettamente a posto. JavaScript consumerà i dati e CamelCase è la convenzione.

Le cose diventano oscure quando il tuo codice server assiste più client in diversi stack tecnologici. Quindi inizi con JavaScript. Quindi aggiungi un'applicazione Java per Android. Usare camelCase ha ancora senso, perché è ancora la convenzione con Java.

Ma poi aggiungi un'applicazione web C # come client della tua applicazione PHP. Ora PascalCase è la convenzione. E aggiungi un'API web di Ruby per buona misura, e torniamo di nuovo su snake_case.

Quindi non importa ciò che scegli, ma sii coerente.

score 2 · Answer 2

Non c'è una risposta corretta qui. Scoprirai che quando utilizzi strumenti diversi da diversi fornitori (o addirittura dallo stesso fornitore, ma con patrimoni diversi) ti imbatterai in questo problema. Il meglio che puoi sperare di fare è essere coerenti in ciò che stai scrivendo.

Se questo è un problema grave, puoi sempre creare costanti con nome (che dovresti fare indipendentemente) che lo cambiano. Ad esempio in PHP, fai questo:

define("first_name", "firstName");
...
foo_bar[first_name]; // Or whatever the appropriate syntax would be

score 1 · Answer 3

JSON è l'abbreviazione di "JavaScript Object Notation" che lo identifica chiaramente nel dominio JavaScript, quindi JSON dovrebbe usare JavaScript camelCase. Anche se il tuo server è scritto in una lingua che usa il caso Pascal o caratteri di sottolineatura, dovrebbe funzionare con JSON nel suo formato specifico, usando le sue convenzioni.

Allo stesso modo, se il tuo server sta eseguendo il rendering CSS, devi usare caratteri minuscoli con trattini, coerenti con le convenzioni di denominazione CSS. Lo stesso per qualsiasi altra piattaforma con cui il tuo server entrerà in contatto, ad es. il tuo verbo HTTP dovrebbe sempre essere in maiuscolo.

score 0 · Answer 4

Hai spesso 1 server, 1 API e più client scritti in lingue diverse, ma è improbabile che abbia 1 client, 1 API e più server scritti in lingue diverse.

Quindi è quasi sempre più sensato che il server definisca l'API. Le convenzioni di denominazione dei nomi di variabili sull'API fanno parte dell'API.

Purtroppo questo non risponde alla tua domanda. Anche se il lato server definisce l'API, è ancora possibile decidere che l'API debba utilizzare diverse convenzioni di denominazione rispetto alla rappresentazione del server interno - se si riscontra un vantaggio tangibile nel farlo . Ad esempio, potresti preferire camelCase per un'API pubblica utilizzata da utenti occasionali che hanno maggiori probabilità di essere confusi da più convenzioni di denominazione nella loro base di codice. A seconda del caso d'uso e dei costi di supporto, potresti persino decidere di supportare camelCase, under_score e PascalCase e convertire automaticamente la rappresentazione interna.

Per semplicità, ti consiglio di "perdere" le convenzioni di denominazione lato server, a meno che tu non possa definire un beneficio tangibile nel non farlo per il tuo caso d'uso specifico.