Questo è un po 'pedante, ma ho visto alcune persone usare Id come in:
private int userId;
public int getUserId();
e altri usano:
private int userID;
public int getUserID();
Uno di questi è un nome migliore rispetto all'altro? Perché? Ho visto questo fatto in modo molto incoerente nei grandi progetti. Se dovessi fissare uno standard con cui la maggior parte delle persone dovrebbe avere familiarità? Qual è lo standard convenzionale?
La regola più importante da seguire in questi casi è la coerenza: fai come fanno tutti gli altri.
Ad esempio, guarda le API XML della tua lingua per vedere come lo fanno.
Classi di nomi Java come SAXParser e < a href="http://docs.oracle.com/javase/1.4.2/docs/api/org/w3c/dom/DOMException.html"> DOMException , classi di nomi .NET come XmlDocument .
In base a ciò, direi "ID" in Java, "Id" in C #.
Tuttavia, ho visto che Java EE 6 ha un'annotazione di nome @Id (vedi documentazione ), quindi sembra che Java consideri" Id "come una parola normale.
La coerenza è il re; scegli l'uno o l'altro, ma fallo costantemente ovunque.
Detto questo, preferisco la prima variazione, perché non viola CamelCase (facendo questo significa che hai due regole di stile da ricordare, non solo una).
A volte vengono utilizzate due lettere maiuscole a causa di questo , ma un ID è in realtà solo una forma di identificazione degli ID.
TL; DR: Nel contesto delle librerie di classi .NET, Microsoft consiglia di utilizzare Id. Questo è leggermente contro-intuitivo, poiché è un raro esempio di un'abbreviazione che è permessa / raccomandata (le abbreviazioni sono generalmente disapprovate).
Se stiamo parlando di convenzioni di libreria di classi C # o .NET, Microsoft ha alcuni denominazione abbastanza ben definiti linee guida disponibili. Sono ben pensati, con molte spiegazioni su una varietà di problemi - in realtà, ogni sviluppatore dovrebbe impiegare del tempo per leggere l'intero Linee guida per la progettazione sezione.
Quando si tratta di acronimi , la regola generale è: per gli acronimi di due lettere, si tende a tenerli maiuscoli (dove è applicabile il caso Pascal), quindi ad es. IOStream potrebbe essere il nome di una classe. Per un acronimo più lungo, si riduce il resto dell'acronimo, ad es. XmlDocument o HtmlParser . Questa è in realtà una regola per lo più non ambigua (non c'è confusione su dove finisce la prima parola e inizia la prossima, a meno che non si incatenano acronimi di due lettere), e ci si abitua molto rapidamente.
Quindi, è ID o Id? Bene, secondo Microsoft, potrebbe non essere quello che pensi:
Acronyms differ from abbreviations in that an abbreviation shortens a single word. For example, ID is an abbreviation for identifier. In general, library names should not use abbreviations.
The two abbreviations that can be used in identifiers are ID and OK. In Pascal-cased identifiers they should appear as Id, and Ok. If used as the first word in a camel-cased identifier, they should appear as id and ok, respectively.
Aneddoticamente, non sono sicuro quando questa distinzione iniziò a comparire nelle linee guida, ma alcuni anni fa (circa 3.0 / 3.5) la tendenza generale alla denominazione nelle librerie di classi passò da ID a Id.
Ho letto una spiegazione molto buona in alcuni documenti delle convenzioni di codifica. CamelCase deve sempre essere usato per acronimi e abbreviazioni, perché è più facile distinguere i confini delle parole (confrontare XmlIdWriter con XMLIDWriter ).
Come possiamo vedere nella funzione predefinita di JavaScript getElementById (); L'ID è scritto nel caso Camel ...
Utilizza 'id' se si utilizza con un carattere di sottolineatura. Esempio: user_id
Usa 'Id' se nominando una var senza alcun Underscore per differenziare le diverse parole. Esempio: userId
Se è una variabile a parola singola, dovrebbe essere in minuscolo completo, se più parole var usano quindi caso Camel inferiore. Esempio: thisIsExample
Ma altamente non consiglierei 'ID' tutto in CAPS perché generalmente usiamo tutte le maiuscole per definire COSTANTI.
Per prima cosa, evita l'abbreviazione.
In secondo luogo, se l'abbreviazione è ben nota, raccomando di usare la custodia del cammello.
Questo perché non hai bisogno di considerare il significato di ciò. tratta solo come una parola normale
Leggi altre domande sui tag coding-style variables naming