Problema di CamelCase (PList o Plist)

Le regole per Pascal Casing in .NET sono le seguenti:

• gli acronimi e le abbreviazioni di una o due lettere sono tutti maiuscoli ( XPath , ACCurrent , VWBeetle )
• parole complete e abbreviazioni di tre o più lettere hanno una lettera maiuscola e il resto in minuscolo ( XmlDocument , AspLover , BmwDriver )
• nota che le parole di due lettere che non sono abbreviazioni sono maiuscole, non tutte maiuscole: StopAndGo , non StopAndGO
• nota anche che l'iniziale maiuscola di una parola (anche un nome di marca) non viene mai onorata a meno che non coincida con le regole precedenti: IPhone , non iPhone , Asp , non ASP , DotNet , non DotNET .

Poiché "P" è l'abbreviazione di "proprietà" e "elenco" è una parola completa, la corretta maiuscola è PList . Plist suggerirebbe che 'plist' fosse una parola, che non è. (E il lettore sa che deve essere P-list, non PL-ist, perché se 'ist' fosse una parola completa, dovrebbe essere PLIst .)

Nel caso degli elenchi di proprietà di OS X, vengono solitamente definiti ".plist" o "Elenco proprietà". Ti consigliamo di non utilizzare la versione abbreviata perché non è il nome effettivo del tipo di file, ma l'estensione.

.NET non è in realtà CamelCase, ma Pascal Casing; l'involucro del cammello ha tradizionalmente la prima lettera in minuscolo e altre maiuscole, mentre il caso Pascal ha la prima lettera in maiuscolo. È possibile rimuovere il resto di una parola e conservare la maiuscola (come in "PList"), ma non si dovrebbe comunque farlo, perché è meno descrittivo. Inoltre, lo stile di casing .NET richiede che qualsiasi acronimo composto da tre o più lettere sia in minuscolo dopo la prima lettera, in modo che "Strumento di visualizzazione grafica" sia "GdiTool", NON "GDITool".

La convenzione sul caso dei cammelli suggerisce che ogni parola distinta unita a un identificatore dovrebbe avere il suo primo carattere maiuscola. Quindi per gli identificatori public .NET, vorrei andare con PList.

(la convenzione in .NET per gli identificatori private deve iniziare con un carattere minuscolo, quindi per le variabili di classe o di routine sarebbe pList).

Sai che qualcosa non va quando ti preoccupi di queste banalità. Scegli quale ti conviene e torna a preoccuparti di far funzionare il codice.

Il mio modo di evitare di passare molto tempo a pensare a queste cose è semplicemente chiedermi come lo chiamerei in underscore, e sfortunatamente mi scontro un po 'con gli sviluppatori su questo. Ma posso almeno dire che richiede poca riflessione, e non penso che sia un argomento particolarmente soggettivo. Quindi, se lo fai come me, la domanda è come scrivere "p list" o "plist" nella convenzione di sottolineatura.

Scriveresti come p_list o plist ? Quindi diventa una traduzione piuttosto semplice da underscore a cammello che anche un robot può fare.

Simile cosa per "fanteria USA" come. Lo scriverei in questo modo?

usa_infantry -> UsaInfanty (machine translation)

O come questo?

u_s_a_infantry -> USAInfantry (machine translation)

Prendi "Renderer GL". Scriveresti in questo modo?

renderer_g_l -> RendererGL (machine translation)

O come questo?

renderer_gl -> RendererGl (machine translation)

È così che lo faccio comunque. Ad alcune persone non piace come lo faccio con le abbreviazioni dato che non inserisco tutte le lettere in maiuscolo se sono raggruppate (ignorando l'estetica "inglese") in favore di quella che sembra la traduzione più naturale del rep di sottolineatura, ma a Almeno posso dire che richiede la minima quantità di pensiero e quindi promuove la massima quantità di coerenza tra gli sviluppatori poco coordinati se applicano la stessa pratica. Nel frattempo vedo API popolari come QT con convenzioni che non sono per niente coerenti con le loro abbreviazioni, mentre posso almeno affermare che se gli sviluppatori usassero la mia tecnica di "underscore translation", avrebbero poca difficoltà con la coerenza nell'uso di camelCase.

Questo potrebbe essere argomentato come banalità, ad eccezione della parte di coerenza all'interno dei team. Se stai spedendo un SDK e le convenzioni di denominazione sembrano davvero persone diverse nominate tutto, allora questo si traduce in un problema di usabilità e familiarità a terze parti oltre a sembrare un po 'trascurato e poco professionale che non è così banale, che è finito diventare una fonte di reclami da parte di terzi che ha finito per diventare una fonte di argomenti a dispersione di tempo tra gli sviluppatori. E uno standard di codifica che è molto sfumato con un sacco di casi eccezionali è spesso destinato a non essere seguito così bene dagli sviluppatori a meno che non siano strettamente collaborati (e non ho sempre avuto la fortuna di lavorare con questi team). Quindi preferisco il più vicino possibile allo standard "no-brainer", e quest'idea di tradurre in convenzione di sottolineatura e poi tradurre roboticamente in camelCase o UpperCamelCase tende a ridurre la tendenza degli sviluppatori a variare un po 'nel modo in cui applica questa convenzione.

In particolare, ho sviluppato questo stile per CamelCasing in una vana speranza di porre fine a discussioni stupide sul modo in cui denominiamo le cose, in particolare quando sono abbreviate o acronimi, solo per trovare la mia soluzione senza freni ancora contestata da un punto di vista "estetico inglese" (perché non contestano questo per la convenzione di sottolineatura?). Oh bene, scrollando le spalle . È il meglio che sono riuscito a trovare per promuovere una maggiore coerenza nel modo in cui la mia squadra, e forse qualche piccolo barlume di speranza per il resto del mondo, usa la carcassa di cammello, perché ho notato molte meno dispute di questo tipo con underscore_convention ( non risolve tutto ma almeno non stiamo discutendo sugli acronimi in genere). Nel mio team avevamo persino identificatori SDK con la convenzione underscore e camelCase mescolati insieme, come FastRenderer_GL , che a mio parere sembra stupida e difficile da ricordare quando gli sviluppatori diventano così sfumati con le eccezioni personali che applicano ai loro identificatori che no l'altro capisce. Spero di non essere così dogmatico in questo senso, dal momento che il mio obiettivo principale è stato quello di farci concentrare sulla spedizione delle cose invece di discutere su come diamo un nome alle cose (anche se a volte inavvertitamente mi sento dogmatico nella mia ricerca per anti-dogmatismo).