¿Alguien más encuentra que nombrar las clases y los métodos es una de las partes más difíciles de la progtwigción?

Así que estoy trabajando en esta clase que se supone que solicita documentación de ayuda de un proveedor a través de un servicio web. Intento VendorDocRequester DocumentRetriever , VendorDocRequester , DocGetter , pero no suenan bien. Terminé navegando en dictionary.com durante media hora tratando de encontrar una palabra adecuada.

Comenzar a progtwigr con malos nombres es como tener un mal día de pelo en la mañana, el rest del día va cuesta abajo desde allí. ¿Sienteme?

    Lo que está haciendo ahora está bien, y le recomiendo que se quede con su syntax actual, siendo:

    contexto + verbo + cómo

    Utilizo este método para nombrar funciones / métodos, procesos almacenados de SQL, etc. Manteniendo esta syntax, mantendrá sus paneles Intellisense / Code mucho más claros. Entonces usted quiere EmployeeGetByID () EmployeeAdd (), EmployeeDeleteByID (). Cuando use una syntax gtwigticalmente correcta como GetEmployee (), AddEmployee () verá que esto se vuelve realmente complicado si tiene varios Gets en la misma clase, ya que los elementos no relacionados se agruparán.

    Me refiero a nombrar archivos con fechas, quiere decir 2009-01-07.log no 1-7-2009.log porque después de tener un montón de ellos, la orden se vuelve totalmente inútil.

    Una buena convención de nombres debería minimizar el número de nombres posibles que puede usar para cualquier variable, clase, método o función dada. Si solo hay un nombre posible, nunca tendrás problemas para recordarlo.

    Para funciones y para clases singleton, examino la función para ver si su función básica es transformar un tipo de cosa en otro tipo de cosas. Estoy usando ese término muy libremente, pero descubrirás que una gran cantidad de funciones que escribes esencialmente toman algo en una forma y producen algo en otra forma.

    En tu caso, parece que tu clase transforma una Url en un Documento. Es un poco extraño pensar de esa manera, pero perfectamente correcto, y cuando comiences a buscar este patrón, lo verás en todas partes.

    Cuando encuentro este patrón, siempre nombro la función x From y .

    Como su función transforma una Url en un Documento, yo lo nombraría

     DocumentFromUrl 

    Este patrón es notablemente común. Por ejemplo:

     atoi -> IntFromString GetWindowWidth -> WidthInPixelsFromHwnd // or DxFromWnd if you like Hungarian CreateProcess -> ProcessFromCommandLine 

    También puede usar UrlToDocument si se siente más cómodo con ese orden. Si dices x From y o y To x es probablemente una cuestión de gusto, pero prefiero el orden From porque de esa manera el comienzo del nombre de la función ya te dice qué tipo devuelve.

    Elija una convención y cúmplala. Si tiene cuidado de usar los mismos nombres que los nombres de su clase en sus funciones x From , será mucho más fácil recordar los nombres que utilizó. Por supuesto, este patrón no funciona para todo, pero funciona donde se escribe código que se puede considerar como “funcional”.

    Una lección que aprendí es que si no puede encontrar un nombre para una clase, casi siempre hay algo mal con esa clase:

    • no lo necesitas
    • hace demasiado

    A veces no hay un buen nombre para una clase o método, nos pasa a todos. Muchas veces, sin embargo, la inhabilidad de encontrar un nombre puede ser una pista de que hay algo mal con su diseño. ¿Su método tiene demasiadas responsabilidades? ¿Su clase encapsula una idea coherente?

    Tema 1:

     function programming_job(){ while (i make classes){ Give each class a name quickly; always fairly long and descriptive. Implement and test each class to see what they really are. while (not satisfied){ Re-visit each class and make small adjustments } } } 

    Tema 2:

     while(true){ if (any code smells bad){ rework, rename until at least somewhat better } } 

    No hay Thread.sleep (…) en ningún lado aquí.

    También paso mucho tiempo preocupándome por los nombres de todo lo que se pueda asignar a un nombre cuando estoy progtwigndo. Yo diría que vale la pena muy bien sin embargo. A veces, cuando estoy atascado lo dejo por un tiempo y durante un descanso para tomar café pregunto un poco si alguien tiene una buena sugerencia.

    Para su clase, sugeriría VendorHelpDocRequester .

    El libro Code Complete de Steve Mcconnell tiene un buen capítulo sobre cómo nombrar variables / clases / funciones / …

    Creo que esto es un efecto secundario.

    No es el nombre real lo que es difícil. Lo difícil es que el proceso de nombrar te hace enfrentar el horrible hecho de que no tienes idea de qué demonios estás haciendo.

    Apenas escuché esta cita ayer, a través del blog Signal vs. Noise en 37Signals, y ciertamente estoy de acuerdo con ella:

    “Solo hay dos cosas difíciles en informática: la invalidación de caché y el nombramiento de cosas”. – Phil Karlton

    Es bueno que sea difícil. Te obliga a pensar en el problema y en lo que se supone que debe hacer realmente la clase. Los buenos nombres pueden ayudar a conducir a un buen diseño.

    Convenido. Me gusta mantener mis nombres y variables de tipo tan descriptivos como sea posible sin ser demasiado largo, pero a veces hay un cierto concepto para el que no se puede encontrar una buena palabra.

    En ese caso, siempre me ayuda a pedirle a un compañero de trabajo que me dé su opinión, incluso si al final no me ayudan, generalmente me ayuda a explicarlo en voz alta y a poner las ruedas en mi sitio.

    Estaba escribiendo sobre las convenciones de nombres el mes pasado: http://caseysoftware.com/blog/useful-naming-conventions

    La esencia de esto:

    verbAdjectiveNounStructure – con Estructura y Adjetivo como partes opcionales

    Para los verbos , me atengo a los verbos de acción: guardar, eliminar, notificar, actualizar o generar. De vez en cuando, uso “proceso” pero solo para referirme específicamente a colas o atrasos de trabajo.

    Para los sustantivos , uso la clase u objeto con el que interactúo. En web2project, esto suele ser tareas o proyectos. Si es Javascript interactuando con la página, podría ser cuerpo o tabla. El punto es que el código describe claramente el objeto con el que interactúa.

    La estructura es opcional porque es única para la situación. Una pantalla de listado puede solicitar una Lista o una Matriz. Una de las funciones principales utilizadas en la Lista de proyectos para web2project es simplemente getProjectList. No modifica los datos subyacentes, solo la representación de los datos.

    Los adjetivos son algo completamente diferente. Se usan como modificadores del sustantivo. Algo tan simple como getOpenProjects podría implementarse fácilmente con un getProjects y un parámetro de conmutación, pero esto tiende a generar métodos que requieren bastante conocimiento de los datos subyacentes y / o la estructura del objeto … no necesariamente algo que desee alentar. Al tener funciones más explícitas y específicas, puede envolver y ocultar completamente la implementación del código que la usa. ¿No es ese uno de los puntos de OO?

    Más que simplemente nombrar una clase, crear una estructura de paquete adecuada puede ser un desafío difícil pero gratificante. Debe considerar separar las preocupaciones de sus módulos y cómo se relacionan con la visión de la aplicación.

    Considera el diseño de tu aplicación ahora:

    • Aplicación
      • VendorDocRequester (leer desde el servicio web y proporcionar datos)
      • VendorDocViewer (use requester para proporcionar documentos del proveedor)

    Me atrevería a adivinar que están pasando muchas cosas dentro de unas pocas clases. Si tuviera que refacturar esto en un enfoque más MVC-ified, y permitir que las clases pequeñas manejen tareas individuales, podría terminar con algo como:

    • Aplicación
      • VendorDocs
        • Modelo
          • Documento (objeto simple que contiene datos)
          • WebServiceConsumer (tratar con nitty gritty en el servicio web)
        • Controlador
          • DatabaseAdapter (maneja la persistencia usando ORM u otro método)
          • WebServiceAdapter (utiliza Consumer para tomar un documento y pegarlo en la base de datos)
        • Ver
          • HelpViewer (use DBAdapter para escupir la documentación)

    Luego, los nombres de sus clases dependen del espacio de nombres para proporcionar un contexto completo. Las clases en sí mismas pueden estar relacionadas intrínsecamente con la aplicación sin necesidad de decirlo explícitamente. ¡Los nombres de las clases son más simples y fáciles de definir como resultado!

    Otra sugerencia muy importante: hazte un favor y recoge una copia de los patrones de diseño de Head First. Es un libro fantástico y fácil de leer que te ayudará a organizar tu aplicación y escribir un código mejor. Apreciar los patrones de diseño te ayudará a comprender que muchos de los problemas que encuentras ya se han resuelto y podrás incorporar las soluciones en tu código.

    Leo Brodie, en su libro “Thinking Forth”, escribió que la tarea más difícil para un progtwigdor era nombrar las cosas bien, y afirmó que la herramienta de progtwigción más importante es un diccionario de sinónimos.

    Intente utilizar el diccionario de sinónimos en http://thesaurus.reference.com/ .

    Más allá de eso, no use la notación húngara NUNCA, evite las abreviaturas y sea coherente.

    Los mejores deseos.

    En breve:
    Estoy de acuerdo en que los buenos nombres son importantes, pero no creo que deba encontrarlos antes de implementarlos a toda costa.

    Por supuesto, es mejor tener un buen nombre desde el principio. Pero si no puede encontrar uno en 2 minutos, cambiarle el nombre más tarde le costará menos tiempo y es la opción correcta desde el punto de vista de la productividad.

    Largo:
    En general, a menudo no vale la pena pensar demasiado en un nombre antes de implementarlo. Si implementa su clase, llamándola “Foo” o “Dsnfdkgx”, al implementarla verá lo que debería haberle llamado.

    Especialmente con Java + Eclipse, cambiar el nombre de las cosas no es doloroso, ya que maneja cuidadosamente todas las referencias en todas las clases, te advierte sobre colisiones de nombres, etc. Y mientras la clase no esté aún en el repository de control de versiones, no lo hago. Pienso que hay algo de malo en cambiarle el nombre 5 veces.

    Básicamente, se trata de cómo piensas acerca de refactorizar. Personalmente, me gusta, aunque a veces molesta a mis compañeros de equipo, ya que creen que nunca deben tocar un sistema en funcionamiento . Y de todo lo que puede refactorizar, cambiar los nombres es una de las cosas más inofensivas que puede hacer.

    ¿Por qué no HelpDocumentServiceClient tipo de bocado, o HelpDocumentClient … no importa que sea un proveedor el punto es que es un cliente de un servicio web que se ocupa de los documentos de ayuda.

    Y sí, nombrar es difícil.

    Solo hay un nombre sensato para esa clase:

     HelpRequest 

    No permita que los detalles de la implementación lo distraigan del significado.

    ¡Invierta en una buena herramienta de refactorización!

    Me limito a lo básico: VerbNoun (argumentos). Ejemplos: GetDoc (docID).

    No hay necesidad de ser elegante. Será fácil de entender dentro de un año, ya sea usted u otra persona.

    Para mí no me importa cuánto tiempo un método o nombre de clase es tan largo como descriptivo y en la biblioteca correcta. Atrás quedaron los días en los que debe recordar dónde reside cada parte de la API.

    Intelisense existe para todos los idiomas principales. Por lo tanto, cuando utilizo una API de terceros, me gusta usar su intelisense para la documentación en lugar de utilizar la documentación ‘real’.

    Con eso en mente, estoy bien para crear un nombre de método como

    StevesPostOnMethodNamesBeingLongOrShort

    Largo, pero ¿y qué? ¡Quién no usa pantallas de 24 pulgadas en estos días!

    Tengo que aceptar que nombrar es un arte. Se vuelve un poco más fácil si su clase sigue un cierto “patrón de desigh” (fábrica, etc.).

    Esta es una de las razones para tener un estándar de encoding. Tener un estándar tiende a ayudar a crear nombres cuando es necesario. ¡Ayuda a liberar tu mente para usar para otras cosas más interesantes! (-:

    Recomiendo leer el capítulo correspondiente del Código Completo de Steve McConnell ( enlace de Amazon ), que entra en varias reglas para ayudar a la legibilidad e incluso a la capacidad de mantenimiento.

    HTH

    aclamaciones,

    Robar

    ¡No, la depuración es lo más difícil para mí! 🙂

    DocumentFetcher? Es difícil de decir sin contexto.

    Puede ayudar a actuar como un matemático y tomar prestado / inventar un léxico para su dominio sobre la marcha: acuerde palabras breves que sugieran el concepto sin deletrearlo todo el tiempo. Demasiado a menudo veo frases latinas largas que se convierten en acrónimos, lo que hace que necesites un diccionario para los acrónimos de todos modos .

    El lenguaje que usa para describir el problema es el que debe usar para las variables, métodos, objetos, clases, etc. En pocas palabras, los nombres coinciden con los objetos y los verbos. Si le faltan palabras para describir el problema, también le falta una comprensión (especificación) completa del problema.

    Si solo se trata de elegir entre un conjunto de nombres, debe ser impulsado por las convenciones que está utilizando para construir el sistema. Si ha llegado a un lugar nuevo, descubierto por convenciones anteriores, siempre vale la pena gastar un poco de esfuerzo para tratar de ampliar (de manera adecuada y consistente) para cubrir este nuevo caso.

    Si tiene dudas, duerma y elija el primer nombre más obvio a la mañana siguiente 🙂

    Si te despiertas un día y te das cuenta de que estabas equivocado, entonces cámbialo de inmediato.

    Pablo.

    Por cierto: Document.fetch () es bastante obvio.

    Encuentro que tengo más problemas en las variables locales. Por ejemplo, quiero crear un objeto de tipo DocGetter. Entonces sé que es un DocGetter. ¿Por qué necesito darle otro nombre? Normalmente termino dándole un nombre como dg (para DocGetter) o temp o algo igualmente descriptivo.

    No olvide que los patrones de diseño (no solo los de GoF) son una buena forma de proporcionar un vocabulario común y sus nombres deben usarse siempre que uno se adapte a la situación. Eso incluso ayudará a los recién llegados que estén familiarizados con la nomenclatura a comprender rápidamente la architecture. ¿Se supone que esta clase en la que estás trabajando actúa como un Proxy, o incluso una Fachada?

    ¿No debería ser la documentación del vendedor el objeto? Quiero decir, ese es tangible, y no solo como una antropomorfización de una parte de tu progtwig. Entonces, podrías tener una clase VendorDocumentation con un constructor que obtenga la información. Creo que si un nombre de clase contiene un verbo, a menudo algo ha salido mal.

    Definitivamente te siento. Y siento tu dolor Cada nombre que pienso me parece una basura. Todo parece tan genérico y, con el tiempo, quiero aprender cómo inyectar un poco de estilo y creatividad en mis nombres, haciendo que realmente reflejen lo que describen.

    Una sugerencia que tengo es consultar un diccionario de sinónimos. Word tiene uno bueno, al igual que Mac OS X. Eso realmente me puede ayudar a sacar mi cabeza de las nubes y me da un buen lugar para comenzar y también algo de inspiración.

    Si el nombre se explica a un progtwigdor laico, probablemente no haya necesidad de cambiarlo.