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

Una buena convención de nomenclatura 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.

De funciones y clases singleton, que examinar la función para ver si su función básica es transformar un tipo de cosa en otro tipo de cosa. Estoy usando ese término muy libremente, pero usted descubrirá que un GRAN número de funciones que usted escribir esencialmente tomar algo en una forma y producir algo en otra forma.

En su caso, parece que su clase transforma una Url en un Documento. Es un poco raro pensarlo de esa manera, pero perfectamente correcto, y cuando empiezas a buscar este patrón, lo verás en todas partes.

Cuando encuentro este patrón, siempre nombro la función xFromy .

Dado que su función transforma una Url en un documento, I lo llamarí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 puedes usar UrlToDocument si te sientes más cómodo con ese pedido. Si usted dice xFromy o yTox 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 le dice qué tipo devuelve.

Elige una convención y apégate a ella. Si tiene cuidado de usar los mismos nombres que su los nombres de clase en su xFromy funciones, será mucho más fácil recordar los nombres que has utilizado. Por supuesto, este patrón no funciona para todo, pero funciona donde estás escribiendo código que se puede pensar como "funcional"."

Una lección que he aprendido, es que si no puedes 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 incapacidad para llegar a un nombre puede ser una pista a algo mal con su diseño. ¿Su método tiene demasiadas responsabilidades? ¿Su clase encapsula una idea coherente?

Hilo 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 
         }
    }
}

Hilo 2:

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

No hay hilo.dormir(...) en cualquier lugar aquí.

También paso mucho tiempo preocupándome por los nombres de cualquier cosa a la que se le pueda dar un nombre cuando estoy programando. Aunque diría que vale la pena. A veces cuando estoy atascado lo dejo por un tiempo y durante una pausa para el café pregunto un poco si alguien tiene una buena sugerencia.

Para tu clase sugeriría VendorHelpDocRequester.

El libro Code Complete de Steve Mcconnell tiene un buen capítulo sobre 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.

En realidad acabo de escuchar 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: invalidación de caché y nombrar cosas." - Phil Karlton

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

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

En ese caso, siempre me ayuda pedirle a un compañero de trabajo que aporte información, incluso si en última instancia no ayudan, por lo general me ayuda al menos a explicarlo en voz alta y hacer que mis ruedas giren.

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 verbos, me atengo a los verbos de acción: guardar, eliminar, notificar, actualizar o generar. De vez en cuando, uso "proceso", pero solo para hacer referencia específicamente a las colas o los retrasos de trabajo.

Para sustantivos , utilizo la clase o objeto con el que se interactúa. En web2project, esto suele ser Tareas o Proyectos. Si es Javascript interactuando con la página, puede ser body o table. El punto es que el código describe claramente el objeto con el que está interactuando.

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 el subyacente datos, sólo la representación de los datos.

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

Más que nombrar una clase, crear una estructura de paquetes apropiada 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.

Considere el diseño de su aplicación ahora:

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

Me atrevería a suponer que hay mucho que hacer dentro de unas pocas clases. Si usted fuera a refactorizar esto en un enfoque más MVC-ifed, y permitir que las clases pequeñas para manejar tareas individuales, usted podría terminar con algo como:

• Aplicación
  • VendorDocs
    • Modelo
      • Documento (objeto plano que contiene datos)
      • WebServiceConsumer (tratar con nitty gritty en el servicio web)
    • Controlador
      • DatabaseAdapter (manejar la persistencia usando OR u otro método)
      • WebServiceAdapter (utilizar Consumidor para agarrar un documento y pegarlo en la base de datos)
    • Vista
      • HelpViewer (use DBAdapter para escupir la documentación)

Entonces los nombres de las clases dependen del espacio de nombres para proporcionar el contexto completo. Las clases en sí pueden estar inherentemente relacionadas con la aplicación sin necesidad de dilo explícitamente. Los nombres de clase son más simples y fáciles de definir como resultado!

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

Leo Brodie, en su libro "Thinking Forth", escribió que la tarea más difícil para un programador era nombrar bien las cosas, y afirmó que la herramienta de programación más importante es un tesauro.

Intente usar el tesauro en http://thesaurus.reference.com/.

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

Mis mejores deseos.

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

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

Long:
En general, a menudo no vale la pena pensar demasiado en un nombre antes de implementarlo. Si usted implementa su clase, nombrándolo "Foo"o " Dsnfdkgx", mientras que la implementación de ver lo que debería haber nombrado.

Especialmente con Java+Eclipse, cambiar el nombre de las cosas no es ningún problema, ya que maneja cuidadosamente todas las referencias en todas las clases, le advierte de colisiones de nombres, etc. Y mientras la clase aún no esté en el repositorio de control de versiones, no creo que haya nada malo en cambiarle el nombre 5 veces.

Básicamente, es una cuestión de cómo piensas sobre la refactorización. Personalmente, me gusta, a pesar de que molesta a mis compañeros de equipo a veces, ya que creen en nunca toque un sistema en ejecución. Y de todo lo que puedes refactorizar, cambiar nombres es una de las cosas más inofensivas que puedes hacer.

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

Y sí nombrar es difícil.

Solo hay un nombre sensible para esa clase:

HelpRequest

No dejes que los detalles de la implementación te distraigan del significado.

Invertir en una buena herramienta de refactorización!

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

No hay necesidad de ponerse elegante. Será fácil de entender dentro de un año, ya sea usted o alguien más.

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

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

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

StevesPostOnMethodNamesBeingLongorshort

Largo - pero entonces qué. ¿Quién no utiliza pantallas de 24 pulgadas en estos días!

Estoy de acuerdo en que nombrar es un arte. Se vuelve un poco más fácil si su clase está siguiendo un cierto "patrón de desigh" (fábrica, etc.).

Esta es una de las razones para tener un estándar de codificación. Tener un estándar tiende a ayudar a encontrar nombres cuando es necesario. Ayuda a liberar su mente para utilizar para otras cosas más interesantes! (-:

Recomiendo leer el capítulo relevante del Código Completo de Steve McConnell ( Amazon link) que incluye varias reglas para facilitar la legibilidad e incluso la mantenibilidad.

HTH

Salud,

Rob

No, la depuración es lo más difícil para mí! :-)

DocumentFetcher? Es difícil decirlo sin contexto.

Puede ayudar a actuar como un matemático y pedir prestado/inventar un léxico para su dominio a medida que avanza: conformarse con palabras simples cortas que sugieren el concepto sin deletrearlo cada vez. Con demasiada frecuencia veo frases latinas largas que se convierten en acrónimos, lo que hace que necesite un diccionario para los acrónimos de todos modos.

El idioma que utiliza para describir el problema, es el idioma que debe utilizar para las variables, métodos, objetos, clases, etc. Libremente, los sustantivos coinciden con los objetos y los verbos con los métodos. Si le faltan palabras para describir el problema, también le falta una comprensión completa (especificación) del problema.

Si solo se trata de elegir entre un conjunto de nombres, entonces debe ser impulsado por las convenciones que está utilizando para construir el sistema. Si has llegado a un nuevo lugar, descubierto por convenciones anteriores, entonces siempre vale la pena gastar un poco de esfuerzo en tratar de extenderlos (correctamente, consistentemente) para cubrir este nuevo caso.

En caso de duda, piénselo 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.

Paul.

POR cierto: Documento.fetch() es bastante obvio.

Encuentro que tengo el mayor problema en las variables locales. Por ejemplo, quiero crear un objeto de tipo DocGetter. Así que 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 no descriptivo.

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

¿No debería ser la documentación del proveedor el objeto? Quiero decir, que uno es tangible, y no sólo como una antropomorfización de una parte de su programa. Por lo tanto, puede tener una clase VendorDocumentation con un constructor que obtiene 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 se me ocurre me parece basura. Todo parece tan genérico y finalmente quiero aprender a inyectar un poco de estilo y creatividad en mis nombres, haciéndolos reflejar realmente lo que describen.

Una sugerencia que tengo es consultar un Tesauro. Word tiene una buena, al igual que Mac OS X. Eso realmente puede ayudarme a sacar mi cabeza de las nubes y me da un buen lugar de partida, así como algo de inspiración.

Si el nombre se explicara a un programador lego entonces probablemente no hay necesidad de cambiarlo.