Questa convenzione di denominazione a ritroso è una cattiva idea (cioè contraria agli standard del settore)?

Question

Ho sempre ribaltato i nomi in modo che si raggruppino naturalmente in intellisense. Mi chiedo se questa è una cattiva idea.

Ad esempio, gestisco un negozio di animali e ho pagine di fatturazione per aggiungere, modificare, eliminare e memorizzare pagine visualizzate, anteprima, modifica. Per ottenere l'URL per questi, vorrei chiamare i metodi (in una classe adatta come GlobalUrls.cs

InvoicingAddUrl() 
InvoicingEditUrl() 
InvoicingDeleteUrl() 

StoreDisplayUrl() 
StorePreviewUrl() 
StoreEditUrl() 

Questo li raggruppa bene in intellisense di denominazione più logica sarebbe:.

AddInvoiceUrl() 
EditInvoiceUrl() 
DeleteInvoiceUrl() 

DisplayStoreUrl() 
PreviewStoreUrl() 
EditStoreUrl() 

E ' meglio (meglio essere, più di un modo standard del settore) per raggrupparli per intellisense, o logicamente?

Answer 1

Il raggruppamento in Intellisense è solo un fattore nella creazione di uno schema di denominazione, ma il raggruppamento logico per categoria piuttosto che per funzione è una pratica comune.

La maggior parte delle "convenzioni" di denominazione dettano l'utilizzo di caratteri, casing, underscore, ecc. Penso che sia una questione di preferenza personale (azienda, squadra o altro) se si utilizza la formattazione NounVerb o VerbNoun per i nomi dei metodi.

Ecco alcune risorse:

• Microsoft - General Naming Conventions
• Wikibooks C# Programming/Naming
• Akadia .NET Naming Conventions

Domande correlate:

• Naming Conventions - Guidelines for Verbs, Nouns and English Grammar Usage
• Do vs. Run vs. Execute vs. Perform verbs
• Events - naming convention and style

Answer 2

Non è intrinsecamente male. Ha il vantaggio di essere più facile da identificare il tipo durante la scansione e raggruppa le opzioni insieme in Intellisenso come hai detto tu ou e tutti gli altri membri del tuo team scelgono un modo di fare le cose e rimangono coerenti al riguardo, non dovrebbero esserci grandi problemi.

Answer 3

Non credo sia una buona idea sviluppare uno standard di codifica attorno a uno strumento (almeno come prima considerazione). Anche se la maggior parte degli IDE avrà Intellisense in questi giorni, e la maggior parte delle persone useranno detti IDE, penso che prima di tutto uno standard di codifica dovrebbe essere quello di rendere il codice leggibile e navigabile sui propri meriti.

Preferirei la maggior parte dei nomi logici, personalmente. Quando scrivo codice e ho qualche oggetto su cui sto per chiamare una funzione membro, di solito sto pensando a quale funzione membro chiamare in base all'azione che sto per fare, perché conosco già l'oggetto I ' m manipolando. Quindi il mio primo impulso sarebbe iniziare a digitare "Aggiungi" se volessi aggiungere qualcosa, e vedere cosa Intellisense mi ha mostrato. Questo è, ovviamente, soggettivo.

Non ho mai visto nessuno usare il proprio gruppo alfabetico, Intellisense ovunque - almeno non nel codice che non vale la pena usare come base per il confronto perché era così orribile in altri modi.

Detto questo, se è il vostro standard, fate quello che volete: la coerenza è la parte importante.

Answer 4

In base ai metodi elencati, è possibile effettuare il refactoring di Fatturazione e Store nelle proprie classi, il che sarebbe più vicino al mitico modo "standard del settore".

Detto questo, qualunque cosa il vostro team di programmazione possa concordare sulla convenzione di denominazione dovrebbe andare bene. L'importante è essere coerenti all'interno del progetto.

Answer 5

verificare come i nomi militari cose. Ad esempio, i MRE sono Pasti, pronti da mangiare. Lo fanno a causa dell'ordine, dell'efficienza e non fanno errori. Sono pronti a ignorare le convenzioni standard di denominazione della lingua (vale a dire l'inglese) utilizzate al di fuori della loro organizzazione perché non sono impressionate dalla qualità delle operazioni al di fuori della loro organizzazione. Nell'esercito, la qualità delle operazioni è letteralmente una questione di vita o di morte. Inoltre, facendo le cose a modo loro hanno un modo di identificare chi c'è dentro e chi è al di fuori dell'organizzazione. Chi non è in grado o non vuole imparare la via militare, che è diverso ma non impossibile, non è la prima scelta per il reclutamento o la promozione.

Quindi, se siete impressionati dalla qualità standard del software là fuori, quindi con tutti i mezzi continuate a fare quello che fanno tutti gli altri. Ma, se desideri fare meglio di quanto hai fatto in passato, o meglio del tuo concorrente, allora suggerisco di guardare ad altri campi per le lezioni apprese nel modo più duro, come ad esempio l'esercito. Quindi fai delle scelte per la tua organizzazione, che non sono impossibili ma che sono per te e per la tua competitività. Puoi scegliere i nomi big-endian (le informazioni più significative arrivano per ultime) oi nomi little-endian in stile militare (le informazioni più significative vengono prima), oppure puoi usare lo stile dominante che probabilmente i tuoi concorrenti usano, cosa che fa qualsiasi cosa tu voglia ogni volta che ne hai voglia.

Personalmente, preferisco la denominazione ungherese little-endian (Apps), che è stata ampiamente vista come superiore quando è stata pubblicata, ma poi ha perso il favore perché la denominazione ungherese (Sys) ha distrutto il vantaggio a causa di una traduzione errata dell'idea di base e a causa di abbreviazioni sfrenate. L'intento originale era di iniziare un nome con che tipo di cosa fosse, quindi diventare sempre più specifico fino a quando non si termina con una qualifica unica. Questo è anche l'ordine in cui sono presenti la maggior parte delle dimensioni dell'array e dei qualificatori oggetto, quindi nella maggior parte delle lingue la denominazione little-endian scorre nello schema più grande della lingua.

Sei pronto a qualcosa. Avanti, marzo.