un programmatore, molte lingue - il dilemma del nome

Avendo programmato in un bel po 'di lingue negli oltre 30 anni della mia esperienza, direi che provare a trovare gli standard di denominazione che funzioneranno in qualsiasi lingua è probabilmente una torta nell'idea del cielo.

All'inizio della mia esperienza, ho cercato di usare #define in C per creare cose che avrebbero reso il mio codice C simile al codice Pascal che stavo usando prima. Ero così abituato a programmare in Pascal che pensavo che se solo fossi riuscito a far funzionare C come Pascal mi renderebbe più produttivo. Ho presto scoperto che avevo torto.

Ciò che mi ha reso più produttivo è stato imparare C e non provare a sfruttare la sintassi Pascal in un'altra lingua solo perché mi ha reso più comodo.

Penso che potresti potenzialmente limitare i tuoi programmatori impedendoli di fare qualcosa in una lingua, solo perché è sbagliato farlo in un'altra lingua che stai utilizzando.

Se limiti le convenzioni di denominazione a cose che hanno senso spiegare l'uso della variabile, probabilmente creerai un buon codice, in qualsiasi lingua.

Non dovresti nominare le cose "elenco", "nuovo", "var", "questo" in primo luogo, poiché non sono abbastanza descrittivi in nessuna lingua.

Il passaggio da, ad esempio, JavaScript a Python è già un interruttore di contesto. Non penso che sia male se i nomi delle variabili cambiano, specialmente se i cambiamenti nel nome sono idiomatici con la lingua. Si potrebbe persino sostenere che interruttori di contesto più difficili possono essere d'aiuto in questo caso in quanto aiuta a rafforzare "amico, ora stai scrivendo javascript non python".

Penso che se stai usando una variabile descrittiva, il problema che descrivi dovrebbe essere minimo. Detto questo, se è minimo, accettare anche lo spostamento del contesto causato dalla denominazione delle variabili tra le lingue diventa anche minimo.

Le parole più riservate (in qualsiasi lingua) sono piuttosto generali. Preferisco i nomi di variabili / funzioni che sono più descrittivi e questo significa che non ho quasi mai incontrato questo problema. Devo ammettere di essere stato contagiato da Charles Simonyi con il suo schema originale di denominazione - questo era in Xerox alla fine degli anni '70, prima ancora che fosse chiamato Notazione ungherese - e questo tende anche a significare che i nomi sono qualcosa di userebbe mai come parole riservate.

Non dovresti perdere tempo scrivendo le linee guida finché non scopri che si tratta di un problema effettivo , non di ipotesi.

Una situazione a cui posso pensare dove questo può diventare un problema è quando condividi strutture di dati tra linguaggi di programmazione. Ad esempio, se si dispone di un oggetto Javascript sul lato client che si riflette in un oggetto Python sul lato server, e naturalmente si desidera che abbiano gli stessi nomi per i propri membri. In tal caso la regola è semplice: non utilizzare nomi che sono parole riservate in una delle lingue. Questo è tutto. Scrivilo nelle linee guida se vuoi. Ora passa a compiti più importanti.

BTW, né list né dict è una parola riservata in Python. Possono essere usati come nomi di variabili, anche se piuttosto scadenti.

Secondo la mia esperienza, la soluzione a questo problema è di disporre di ampie convenzioni di denominazione valide per tutte le lingue. Che si tratti di JavaScript, C # o qualche altro linguaggio funky, il modo in cui le variabili e le classi sono denominate può diventare uno standard all'interno di una base di codice, il che è il modo in cui generalmente vedrei risolvere questo problema. Le convenzioni possono essere concordate per consenso di tutti, semplicemente una maggioranza che vuole una linea guida, la direzione che dice "Questo è come lo facciamo", o qualche altra possibilità che immagino.

Raramente vedo il problema dell'identificatore che descrivi perché la maggior parte delle volte il nome della mia classe o della variabile è abbastanza descrittivo da non contraddire così facilmente. Allo stesso tempo, se si lavora con gli altri piuttosto che avere chiarezza su come il team vuole gestire questo è il punto importante.

Non riesco a vedere come questo potrebbe mai essere un problema, a meno che non pianifichi di spostare il codice da una lingua all'altra. Se si tende personalmente a dimenticare quali nomi di variabili sono validi, non utilizzare un nome di variabile a meno che non si sia certi che sia valido. Ma se altre persone usano nomi di variabili non validi, il loro codice non verrà compilato o eseguito. Quindi, se stai lavorando al codice di qualcun altro e hanno chiamato qualcosa "var", puoi essere certo che si tratta di un nome valido in qualunque lingua stiano utilizzando.

Se è possibile pianificare lo spostamento del codice da una lingua a un'altra, potrebbe essere necessario un elenco di nomi vietati. Ad esempio, il mio documento sulle pratiche di codifica C proibisce l'utilizzo di nuova o classe come variabile, poiché ciò rende il codice più difficile da portare in C ++. In tal caso, è ragionevole impostare regole che facilitino quel lavoro, qualora fosse necessario,

Basta attenersi a CamelCase con minuscole lettere maiuscole. Funziona ovunque. Questo è chiamato alla ricerca del minimo comune denominatore tra sistemi incompatibili, e ti troverai spesso a farlo!