¿Es esta convención de nomenclatura inversa una mala idea (es decir, contraria a los estándares de la industria)?

Question

Siempre he invertido nombres para que se agrupen naturalmente en intellisense. Me pregunto si esta es una mala idea.

Por ejemplo, tengo una tienda de mascotas y tengo páginas de facturación que agregan, editan, eliminan y almacenan páginas para mostrar, previsualizar y editar. Para obtener la URL de estos, me gustaría llamar a los métodos (en una clase adecuada como GlobalUrls.cs

InvoicingAddUrl() 
InvoicingEditUrl() 
InvoicingDeleteUrl() 

StoreDisplayUrl() 
StorePreviewUrl() 
StoreEditUrl() 

Esto los grupos muy bien en intelisense denominación más lógica sería:.

AddInvoiceUrl() 
EditInvoiceUrl() 
DeleteInvoiceUrl() 

DisplayStoreUrl() 
PreviewStoreUrl() 
EditStoreUrl() 

¿Es mejor (mejor, más de una forma estándar de la industria) para agruparlos para intellisense, o lógicamente?

Answer 1

Agrupar en Intellisense es solo un factor en la creación de un esquema de nombres, pero lógicamente la agrupación por categoría en lugar de función también es una práctica común.

La mayoría de las "convenciones" de nombres dictan el uso de caracteres, mayúsculas, guiones bajos, etc. Creo que es una cuestión de preferencia personal (compañía, equipo u otro) si usa el formato NounVerb o VerbNoun para los nombres de sus métodos.

Éstos son algunos recursos:

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

preguntas relacionadas:

• 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

No es intrínsecamente malo. Tiene la ventaja de ser más fácil de identificar el tipo durante el escaneo, y agrupa las opciones en Intellisense como usted dijo. Siempre y Si usted y todos los demás integrantes de su equipo eligen una forma de hacer las cosas y se mantienen coherentes al respecto, no debería haber grandes problemas.

Answer 3

No creo que sea una buena idea desarrollar un estándar de codificación alrededor de una herramienta (al menos no como la primera consideración). Aunque la mayoría de los IDEs tendrán Intellisense en estos días, y la mayoría de las personas usarán dichos IDE, creo que lo primero y más importante es que el estándar de codificación sea hacer que el código sea legible y navegable por sus propios méritos.

Optaría por la mayoría de los nombres lógicos, personalmente. Cuando escribo código y tengo algún objeto al que estoy a punto de llamar una función de miembro, generalmente estoy pensando en qué función de miembro llamar en función de la acción que voy a hacer, porque ya sé el objeto I ' m manipulando Así que mi primer impulso sería comenzar a escribir "Agregar" si quería agregar algo, y ver lo que Intellisense me mostró. Esto es, por supuesto, subjetivo.

Nunca he visto a nadie usando su agrupación alfabética de Intellisense en cualquier lugar, al menos no en un código que no valga la pena utilizar como base de comparación porque era tan horrible en otros aspectos.

Dicho esto, si es su estándar, haga lo que quiera, la consistencia es la parte importante.

Answer 4

Según los métodos enumerados, es posible que pueda refacturar Facturación y Almacenar en sus propias clases, lo que estaría más cerca de la mítica forma "estándar de la industria".

Dicho esto, cualquier cosa que su equipo de programación pueda acordar para nombrar las convenciones debería estar bien. Lo importante es ser coherente dentro del proyecto.

Answer 5

comprobar cómo los nombres militares cosas. Por ejemplo, las MRE son comidas, listas para comer. Lo hacen por orden de clasificación, eficiencia y no cometer errores. Están listos para ignorar las convenciones de nomenclatura estándar del idioma (es decir, inglés) que se usan fuera de su organización porque no están impresionados con la calidad de las operaciones fuera de su organización. En el ejército, la calidad de las operaciones es literalmente una cuestión de vida o muerte. Además, al hacer las cosas a su manera, tienen una forma de identificar quién está adentro y quién está fuera de la organización. Cualquier persona que no pueda o no quiera aprender el modo militar, que es diferente pero no imposiblemente difícil, no es su primera opción para el reclutamiento o la promoción.

Por lo tanto, si está impresionado con la calidad estándar del software, siga haciendo lo que hacen los demás. Pero, si desea hacerlo mejor que en el pasado, o mejor que su competidor, entonces le sugiero que busque otros campos para las lecciones aprendidas de la manera difícil, como el militar. Luego haga algunas elecciones para su organización, que no son imposibles sino que son para usted y su competitividad. Puede elegir nombres de big-endian (la información más significativa es la última) o los nombres de little-endian de estilo militar (la información más importante es lo primero), o puede usar el estilo dominante que probablemente usan sus competidores, que está haciendo lo que le apetezca cada vez que lo desee.

En lo personal, prefiero el nombre húngaro (Apps) de little-endian, que fue ampliamente visto como superior cuando salió, pero luego perdí el favor porque la designación húngara (Sys) destruyó la ventaja debido a una mala traducción de la idea básica y debido a las abreviaturas rampantes. La intención original era comenzar un nombre con el tipo de cosa que es, y luego volverse cada vez más específico hasta que terminas con una calificación única. Este es también el orden en el que se encuentran la mayoría de las dimensiones de matriz y calificadores de objetos, por lo que en la mayoría de los lenguajes de little-endian fluye en el esquema más grande del lenguaje.

Estás en algo. Marcha hacia adelante.