Dovresti utilizzare identificatori internazionali in Java/C#?

Question

C# e Java consentono quasi tutti i caratteri nei nomi di classi, nomi di metodi, variabili locali, ecc.È una cattiva pratica usare caratteri non ASCII, mettendo alla prova i limiti di editor e strumenti di analisi scadenti e rendendo difficile la lettura ad alcune persone, o l’arroganza americana è l’unico argomento contro?

Answer 1

Mi atterrei all'inglese, semplicemente perché di solito non si sa mai chi sta lavorando su quel codice e perché alcuni strumenti di terze parti utilizzati nell'avanzamento della creazione/test/monitoraggio dei bug potrebbero avere problemi.Digitare äöüß su una tastiera non tedesca è semplicemente una PITA, e credo semplicemente che chiunque sia coinvolto nello sviluppo di software dovrebbe parlare inglese, ma forse è solo la mia arroganza di non madrelingua inglese.

Ciò che chiami "arroganza americana" non è se il tuo programma utilizza o meno nomi di variabili internazionali, è quando il tuo programma pensa che "Währung" e "Wahrung" siano le stesse parole.

Answer 2

Direi che dipende interamente da chi sta lavorando al codice base.

Se hai un piccolo gruppo di sviluppatori che condividono tutti una lingua comune e non prevedi di aver bisogno di qualcuno che non parli la lingua per lavorare sul codice, vai avanti e usa i caratteri che desideri.

Se hai bisogno che persone di diverse culture e lingue lavorino sul codice, probabilmente è meglio attenersi all'inglese poiché è il denominatore comune per quasi tutti nel mondo.

Answer 3

Se la tua azienda non parla inglese e pensi che il Domain Driven Design abbia qualcosa in sé, allora c'è un altro aspetto:Come possiamo, come sviluppatori, utilizzare la stessa lingua di dominio della nostra attività senza alcun sovraccarico di traduzione?

Ciò non significa solo traduzioni tra lingue, ad esempio inglese e norvegese, ma anche tra parole diverse.Dovremmo usare esattamente le stesse parole della nostra attività per le nostre classi di entità e i nostri servizi.

Ho trovato più semplice arrendermi e usare la mia lingua madre.Ora che il mio codice utilizza le stesse parole, è più semplice conversare con i miei esperti di dominio.E dopo un po' ti ci abitui, proprio come ti sei abituato a programmare senza la notazione ungherese.

Answer 4

Lavoravo in un team di sviluppo che si puliva felicemente il culo con qualsiasi convenzione di denominazione (e del resto qualsiasi altra codifica).Che tu ci creda o no, dover fare i conti con le ä e ö nel codice è stato un fattore che ha contribuito alle mie dimissioni.Anche se sono finlandese, preferisco scrivere codice con le impostazioni della tastiera americana perché le parentesi graffe e quadre sono una seccatura da scrivere su una tastiera finlandese (prova alt destro e 7 e 0 per le parentesi graffe).

Quindi dico di restare con i caratteri ASCII.

Answer 5

Ecco un esempio di dove ho utilizzato identificatori non ASCII, perché l'ho trovato più leggibile rispetto alla sostituzione delle lettere greche con i loro nomi inglesi.Anche se non ho θ o φ sulla tastiera (ho fatto affidamento sul copia e incolla).

Tuttavia queste sono tutte variabili locali.Terrei gli identificatori non ASCII fuori dalle interfacce pubbliche.

Answer 6

Dipende:

• Il tuo team è conforme a eventuali standard esistenti che richiedono l'utilizzo di ASCII?
• Il tuo codice verrà mai riutilizzato o letto in modo fattibile da qualcuno che non parla la tua lingua madre?
• Prevedi uno scenario in cui dovrai chiedere aiuto online e quindi non sarai in grado di copiare e incollare il tuo esempio di codice così com'è?
• Sei sicuro che l'intera suite di strumenti supporti la codifica del codice?

Se hai risposto "sì" a una qualsiasi delle domande precedenti, mantieni solo ASCII.In caso contrario, vai avanti a tuo rischio e pericolo.

Answer 7

SE riesci a superare gli altri prerequisiti ne avrai quindi uno in più (IMHO più importante): quanto è difficile digitare il simbolo.

Sulla mia normale tastiera en-us, l'unico modo che conosco per digitare la lettera ç è tenere premuto alt e premere 0227 sul tastierino numerico oppure copiare e incollare.

Questo sarebbe un ENORME grosso ostacolo nel modo di digitare velocemente.Non vuoi rallentare la tua codifica con cose banali come questa se non sei costretto a farlo.Le tastiere internazionali possono alleviare questo problema, ma cosa succede se devi programmare sul tuo laptop che non ha una tastiera internazionale, ecc.?

Answer 8

Parte del problema è che il linguaggio Java/C# e le sue librerie si basano su parole inglesi come if E toString().Personalmente non vorrei passare dalla lingua non inglese all'inglese durante la lettura del codice.

Tuttavia, se il database, l'interfaccia utente e la logica aziendale (incluse le metafore) sono già in una lingua diversa dall'inglese, non è necessario tradurre in inglese tutti i nomi dei metodi e le variabili.

Answer 9

Mi atterrei ai caratteri ASCII perché se qualcuno nel tuo team di sviluppo utilizza un SDK che supporta solo ASCII o desideri rendere il tuo codice open source, potrebbero sorgere molti problemi.Personalmente non lo farei anche se non hai intenzione di coinvolgere nel progetto qualcuno che non parla la lingua, perché hai un'impresa e mi sembra che chi ha un'impresa vorrebbe che la sua attività si espandesse , che al giorno d’oggi significa trascendere i confini nazionali.La mia opinione è che l'inglese è la lingua del regno e, anche se dai un nome alle tue variabili in una lingua diversa, ha poco o nessun senso utilizzare caratteri non ASCII nella tua programmazione.Lascia che sia il linguaggio a gestirlo se stai gestendo dati UTF8:il mio programma iPhone (che coinvolge tonnellate di dati utente tra il telefono e il server) ha il supporto completo UTF8, ma non ha UTF8 nel codice sorgente.Sembra proprio che si apra un barattolo di vermi così grande quasi senza alcun beneficio.

Answer 10

C'è un altro rischio nell'usare caratteri non ASCII, anche se probabilmente sarà fastidioso solo nei casi più oscuri.I caratteri consentiti sono definito in termini di metodi Character.isJavaIdentifierStart(int) E Character.isJavaIdentifierPart(int), che sono definiti in termini di Unicode.Tuttavia, la versione esatta di Unicode utilizzata dipende dalla versione della piattaforma Java, come specificato nella documentazione di java.lang.Character.

Poiché le proprietà dei caratteri cambiano leggermente da una versione Unicode a quella successiva, è possibile (ma probabilmente molto improbabile) che si possano avere identificatori validi in una versione di Java, ma non in quella successiva.

Answer 11

Come già sottolineato, a meno che i nomi dei metodi non corrispondano principalmente alla lingua, è un po' strano cambiare costantemente lingua durante la lettura.

Per le lingue scandinave e il tedesco, di cui posso parlare e quindi parlare, consiglierei almeno di utilizzare sostituzioni standard, ad es.

ä/æ -> ae, ö/ø -> oe, å -> aa, ü -> ue

eccetera.nel caso in cui altri potrebbero avere difficoltà a digitare le lettere originali senza modifiche alla tastiera/mappa dei tasti.Pensa se all'improvviso dovessi lavorare con una codebase in cui gli sviluppatori utilizzassero una terza lingua (ad esempio includendo il francese ç) e non lo facessero..Nella mia esperienza, passare da più di 2 mappe dei tasti per digitare in modo efficiente sarebbe doloroso.