Domanda

Domanda piuttosto semplice: quando ho un oggetto persistente, di solito ha una proprietà chiamata ID (per le classi astratte).

Quindi .. è l'ID o ID della convenzione di denominazione?

ad es.

public int ID { get; set; }

o

public int Id { get; set; }

evviva :)

PS. Questo è per .NET btw. FXCop conformat sarebbe un bonus.

È stato utile?

Soluzione

Di solito vado con Identificatore . Se voglio davvero mantenerlo breve (come parte di un identificatore più lungo, ad esempio), utilizzo Id, a meno che non sia un parametro o un membro privato.

Le Linee guida per la denominazione di .NET Framework dicono questo:

  

Un acronimo è una parola che si forma dalle lettere di parole in un termine o una frase. Ad esempio, HTML è l'acronimo di Hypertext Markup Language. È necessario includere gli acronimi negli identificatori solo quando sono ampiamente conosciuti e ben compresi. Gli acronimi differiscono dalle abbreviazioni in quanto un'abbreviazione abbrevia una singola parola. Ad esempio, ID è un'abbreviazione per identificatore. In generale, i nomi delle librerie non devono usare abbreviazioni.

     

Le due abbreviazioni che possono essere utilizzate negli identificatori sono ID e OK. Negli identificatori con involucro Pascal dovrebbero apparire come Id e Ok. Se utilizzati come prima parola in un identificatore incastonato nel cammello, dovrebbero apparire rispettivamente come id e ok.

Altri suggerimenti

Qualunque cosa ti piaccia, sii coerente. ID non è una parola, è un'abbreviazione di identità. Come scrivere abbreviazioni è qualcosa di cui le persone discutono da molto tempo. Per esempio. è

getResourceURL

o

getResourceUrl

in realtà entrambi possono essere trovati in uso in diversi framework. Un altro abbr popolare. con un problema simile è UTF8.

È importante essere coerenti, perché altrimenti le persone devono sempre cercare la corretta capitalizzazione per ogni metodo, se ogni metodo lo gestisce in modo diverso.

Ho una mia convenzione per questo. Se l'abbr. è alla fine del nome, è tutto in maiuscolo, se è da qualche altra parte, segue le regole di notazione del cammello. Per es.

getResourceURL
urlOfResource
compareUrlToString

Perché? Mi piace abbr. essere capitalizzato. Molte persone si aspettano che l'URL o l'UTF siano maiuscoli. Tuttavia, se nel mezzo di un nome, distrugge il vantaggio della notazione cammello. Il vantaggio della notazione cammello è che vedi dove una nuova parola inizia con la maiuscola. Quindi confronta:

compareURLToString
compareUrlToString

Nel primo caso, non vedo immediatamente l'URL è una parola e To è la prossima. La T potrebbe far parte dell'URL (URLT) ed essere un abbr diverso, quindi userò il secondo modulo. Se è alla fine, tuttavia, non avrà alcun ruolo, nessun'altra parola segue, quindi preferisco la forma maiuscola. Rispetto questa convenzione in tutto il mio codice.

Le linee guida dicono " Id " ;.

Fortunatamente i ragazzi .Net sono stati così gentili da darci "linee guida per la denominazione" e non "leggi sulla denominazione" ;), quindi fondamentalmente se ritieni fortemente che infrangere una regola indicativa aggiunga più valore che seguirla, allora in ogni caso infrangila, nessuno ti riterrà responsabile se capisce le tue ragioni (come se fornisce più leggibilità e accentua il significato del nome)

Nel mio negozio utilizziamo "ID" anche se le linee guida dicono "Id", ma nessuno si sente davvero in colpa per questo.

Come altri hanno sottolineato, Id è giusto secondo le convenzioni .NET, ma in qualche modo non sembra giusto, quindi molte persone usano l'ID (e continuano a vivere).

Non so quale sarà il contenuto del tuo campo (numeri, stringhe, guide), ma se vuoi saltare il problema puoi semplicemente usare un'altra convenzione .NET per gli identificatori di oggetti: Nome

Usiamo ID internamente, perché Id mi sembra parlare di psicologia, ma FxCop si lamenta, poiché ID non è un acronimo, è un'abbreviazione (per Identity / Identifier). Secondo la regola FxCop, solo gli acronimi che sono lunghi due caratteri possono essere tutti maiuscoli. Tutto il resto dovrebbe essere il caso corretto.

Inseriamo un attributo SuppressMessage nella proprietà ID e tutti sono contenti.

" ID " è una delle abbreviazioni codificate nelle regole di denominazione di FxCop che sono sempre considerate errate, anche se fanno parte di altre parole. L'unico modo in cui ho scoperto di sostituirlo è l'aggiunta di " ID " agli acronimi come ():

<Dictionary>
<Acronyms>
   <CasingExceptions>
        <Acronym>ID</Acronym>
  </CasingExceptions>
</Acronyms>
</Dictionary>

Ha funzionato con FxCop 1.36. Post scriptum In generale, penso che "Id" è un'alternativa migliore ma a volte è impossibile cambiare un nome se viene generato in base a file XML (o servizi Web) che non controlliamo

Preferisco ID, anche in combinazione con altre parole (ad es. CustomerID), ma a rigor di termini è contro le convenzioni di denominazione regolari.

Da queste parti vediamo cose come " Id " o altri acronimi come una parola e " Id " è facile perché nel settore bancario abbiamo molte strane combinazioni di lettere. Quindi la trattiamo come una parola, solo con la prima lettera maiuscola, ed è così che alla fine siamo stati definiti nel nostro documento sulle convenzioni di codifica interna.

Ma la linea di fondo è: scegliere quale convenzione è più comoda per il team di sviluppatori e altre persone che guardano il codice sorgente e rispettano.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top