Convención de nomenclatura más corta para los tipos

Question

Estoy desarrollando un marco y algunos de los objetos tienen nombres realmente largos. Realmente no me gusta esto, pero tampoco me gustan los acrónimos. Estoy tratando de encontrar un nombre más corto para "EventModelSocket", básicamente un contenedor alrededor de la clase de socket .Net que implementa varios eventos y métodos para enviar archivos, objetos, etc. Algunos de los objetos tienen nombres realmente largos debido a esto. , como "EventModelSocketObjectReceivedEventArgs", por ejemplo.

He intentado de todo, desde un diccionario de sinónimos, un diccionario hasta estar sentado aquí durante horas pensando.

Cuando te encuentras con situaciones como esta, ¿cuál es la mejor manera de nombrar algo?

Answer 1

Inserta algo en el espacio de nombres.

Por ejemplo:

EventModelSocketObjectReceivedEventArgs 

convierte

EventModel.Sockets.ReceivedEventArgs 

Answer 2

Bueno, ¿los nombres largos duelen algo?

(editar) otros dos pensamientos:

• uso var en C# 3.0 - que ahorrará la mitad del ancho

• si está utilizando el tipo varias veces en un archivo, considere un tipo de alias si es molesto que:

  using Fred = Namespace.VeryLongNameThatIsBeingAnnoying;

Answer 3

que para un uso a largo nam mi. Con intellisense tecleando el nombre no es tan importante, a menos que esté usando un monitor de 15 pulgadas.

Si tuviera que reducir el nombre podría ir con EvtMdlSck, solo haga que el trabajo sea más corto pero aún se entienda. Aunque esa no es mi preferencia.

Answer 4

me acaba de sugerir el uso de la denominación más concisa que describe el objeto. Si EventModelSocketObjectReceivedEventArgs hace eso, sigue adelante. Mis 2 centavos.

Answer 5

Hace años, cuando estaba en una clase de programación, el profesor citaba la estadística de que un fragmento de código se lee típicamente 600 veces por cada vez que se modificaba. Hoy en día, supongo que esto ya no es cierto, particularmente en entornos TDD donde hay mucha refactorización. Sin embargo, creo que una determinada pieza de código todavía se lee muchas más veces de las que se escribe. Por lo tanto, creo que la máxima que debemos escribir para la legibilidad sigue siendo válida. La forma completa de una palabra en un nombre es más legible, ya que el cerebro no tiene que hacer la conversión. La comprensión es más rápida y más precisa.

Las herramientas que tenemos hoy lo hacen tan fácil con autocompletado y similares. Debido a esto, uso palabras completas en nombres de variables ahora, y creo que es una buena forma de hacerlo.

Answer 6

Si necesita hacer tantos esfuerzos para encontrar un nombre alternativo, ya tiene el nombre correcto. Los nombres de objeto/método/propiedad deben documentarse por sí mismos. Si no describen su propósito exacto, tienen un nombre equivocado. No hay nada de malo con los nombres largos si dan una idea más clara del propósito de ese objeto.

En esta era de intellisense y monitores grandes, realmente no hay excusa para no ser tan descriptivo como sea posible al nombrar.

Answer 7

Algunas críticas en su denominación ...

¿Por qué su componente tiene la palabra "modelo" en su nombre - ¿No es eso un poco redundante.

Dado que su componente parece ser un concentrador de mensajería de algún tipo, por qué no incluir Mensaje en su nombre. ¿Qué pasa con MessageSender?

Para resolver su problema crearía una interfaz y le daría un nombre genérico como MessageSender y una implementación que es donde se incluye la tecnología dentro del nombre como RandomFailingSocketMessageSender.

Si se quiere obtener un buen ejemplo de esto echar un vistazo a las bibliotecas de Java o .Net ..

desde Java. interfaz - clase/implementaciones ... Mapa - HashMap, LinkedHashMap. Lista - LinkedList

Los detalles con respecto a la tecnología o el marco utilizado, por ejemplo, palabras como "Socket" o quizás usar un ejemplo artificial "MQSeries" no deberían ser parte del nombre de la interfaz.

MessageSender parece en mi humilde opinión resumir el propósito de su componente. Parece extraño que lo que envía "archivos" y "eventos" no incluya esas dos palabras descriptivas. Las cosas que su uso en su nombramiento es superfluo y en mi humilde opinión no coincide con su descripción del componente.

Answer 8

No elimine las vocales o algo así de loco.

Estoy con la gente del "palo con el nombre largo".

Una idea es que si los nombres son tan incómodos, tal vez se necesite un replanteamiento más profundo del sistema.

Answer 9

En general, creo en los nombres de clase que describen con precisión su función, y eso está bien tener nombres largos. Si crees que los nombres son realmente largos, lo que yo sugeriría es encontrar un concepto que sea bien conocido por tu equipo de programación y abreviarlo. Entonces, si "Sockets modelo de evento" es un concepto que todo el mundo conoce, entonces abreviarlos a EMS. Si tiene un paquete que trata exclusivamente de Sockets de modelos de eventos, a continuación, agréguelos a EMS en todas las clases internas de ese paquete. La clave aquí es asegurarse de que el nombre esté completo para cualquier persona que pueda no estar familiarizado con el concepto y abreviado para cualquiera que lo sea.