¿Cómo nombras funciones / variables / etc cuando no puedes pensar en un buen nombre? [cerrado]

13

Cuando está definiendo una función / variable / etc. y no está seguro de cómo nombrarla, ¿cómo la nombra? ¿Cómo se te ocurre un nombre?

Si usa un nombre temporal como una tarjeta de lugar hasta que le dé su nombre real, ¿qué nombre temporal usa?

actualizar

He estado usando cosas como WILL_NAME_LATER, NEEDS_NAMEo TO_BE_NAMED. Esperaba que hubiera una convención adoptada, en realidad esperaba que si usaba esta convención adoptada, mi IDE resaltaría el nombre hasta que lo cambiara.

naming variables functions

— JD Isaacks
fuente

Tenga cuidado al usar mayúsculas para nombres de variables. Por convención popular, significa una variable global.

— Spong

@sunpech, lo sé, también uso esa convención de nomenclatura para constantes. Pero creo que la capitalización hace que se destaque, así que no me olvide de cambiarle el nombre. No lo dejo llamado así por mucho tiempo.

— JD Isaacks

3

Para todos los que están diciendo, nunca debería tener un problema para encontrar un nombre ... Incluso Jon Skeet a veces no puede: stackoverflow.com/questions/521893/…

— JD Isaacks

@JohnIsaacks Creo que deberías negrita temporal . Demasiadas personas están leyendo esta pregunta y convirtiendo el código en algo sagrado. Honestamente, sí, puedes escribir código descuidado ESPECIALMENTE cuando intentas avanzar hacia algo más importante. No estamos grabando código en piedra aquí.

— Spong

1

Supongo que la convención para algo como esto sería agregar un TODO en el código, con la explicación de por qué necesita actualizarlo. Muchas herramientas pueden analizar esos TODOS y mostrar una lista de todas las cosas que quedan por hacer.

— Eduardo Scoz

29

Es casi imposible no poder pensar en un nombre para un artefacto que desea diseñar. Puede que no te guste el nombre que se te ocurra porque no es conciso o sexy, pero si piensas demasiado, terminarás con un artefacto mal nombrado.

Digamos que tiene algo que lo ayuda a construir objetos, pero no sabe que esto generalmente se llama fábrica. Solo llámalo ObjectCreator. Suena obtuso, pero al menos está claro.

Digamos que tiene un diccionario que convierte los nombres de host en direcciones IP. Simplemente adelante y llámelo HostnamesToIpAddresses. Claro que es largo, pero dice exactamente lo que hace.

La incapacidad de encontrar un nombre para algo significa que no sabes lo que está haciendo, lo que también significa que tienes un problema mayor ante ti.

— Mark Canlas
fuente

8

Siempre quiero abofetear a las personas que se quejan de que los identificadores son demasiado largos (cuando son solo tres o cuatro palabras). ¡No deberíamos estar limitados por nuestra velocidad de escritura, y si lo estamos, debemos mirar ABCD y aprender a escribir!

— dash-tom-bang

1

+1 por "The inability to come up with a name for something means you don't know what it is doing". Creo que este es realmente un punto importante. Darse cuenta de esto lo ayuda a encontrar ambigüedades y falta de claridad en el código.

— BiAiB

34

Siempre trato de dar grandes nombres a mis variables y funciones .

Si no puedo pensar en un gran nombre, me conformaré con un buen nombre .

Si no puedo encontrar un buen nombre, usaré un nombre correcto .

Nunca, en 15 años de programación profesional, he sido incapaz de encontrar un nombre decente.

— Portman
fuente

66

+1 por ser, como, poético.

— Spong

1

... sin embargo, hace 15 años y 6 meses, nació Microsoft Bob.

— VirtuosiMedia

12

Si no puede pensar en un buen nombre en una variable o función, no entiende lo que está haciendo o tiene un diseño deficiente. De cualquier manera, abofetear un nombre arbitrario como "x" (a menos que se trate de coordenadas) no resolverá su dilema; solo empeorará las cosas y el dolor será mayor.

— gablin
fuente

8

Estoy en desacuerdo. Los desarrolladores no siempre tendrán una comprensión completa de la terminología del negocio. Diablos, incluso el cliente puede no ser capaz de transmitir la terminología durante la recopilación de requisitos, ¡mucho menos incluso comprender su propio negocio! Pero esto no impide que se produzca software. No impide que se creen prototipos. O incluso el código se descartó por falta de comprensión. Pero el código en estas situaciones aún necesita ser producido y entregado.

— Spong

3

@sunpech Disculpe, pero esto da un poco de miedo. ¿Estás tratando de decirnos que es común escribir código aleatorio sin saber lo que realmente hace? Si no sabe algo, haga un esfuerzo para descubrirlo y evitará problemas en el futuro.

— Adam Byrtek

@ AdamByrtek No, no me refiero a eso. Lo que digo es que no siempre depende del desarrollador y del equipo tener la mejor comprensión de lo que un cliente quiere. Algunos clientes tienen dificultades para explicar qué es lo que quieren o no saben qué es lo que quieren. El código incorrecto sucede. Los problemas suceden en proyectos desde malos requisitos hasta plazos poco realistas. Esa es la realidad No hay un mundo perfecto en el que un desarrollador tenga resueltas todas las incógnitas, donde los clientes sean perfectos y los plazos sean precisos. El código generado para los prototipos está destinado a ser desechado. Pero la codificación aún tiene que suceder.

— Spong

continúa ... No estamos hablando de hacer el código de producción o el código final justo antes de un check-in. Estamos hablando de cómo nombrar algo de lo que aún no entendemos por completo, para comenzar inicialmente con algo que no está claro posiblemente por una buena razón (ejemplo: nadie en el equipo lo comprende aún, tal vez no incluso el cliente). Pero las cosas deben avanzar aún según lo que se sabe.

— Spong

1

@sunpech: El único lugar que realmente he visto fooy barutilizado en el código es en pequeños fragmentos de código utilizados para mostrar un concepto. Claro, también me tropiezo cuando pienso nombres, pero nunca he terminado en una posición tan mala donde fooha sido la única opción razonable. Si eso sucediera, entonces realmente no sé qué demonios estoy haciendo y necesito volver al tablero de dibujo y pseudocódigo en su lugar hasta que sepa qué hacer.

— gablin

5

Esta pregunta y especialmente sus respuestas me asustan sin sentido. Alguien tendrá que mantener ese código en el que acabas de nombrar una variable "Copa", ya sabes. ¡Si no tienes suerte, ese alguien serás tú!

Tienes una variable. Es una cosa Representa una cosa, de todos modos. Y las cosas tienen nombres. ¡Así es como sabes que son cosas! ¿Realmente me estás diciendo que debes nombrar una cosa después de otra porque no puedes encontrar el nombre de la cosa real?

Los iteradores deben llamarse i. Los iteradores anidados son probablemente un error, pero si los necesita, avance por el resto de las vocales, en orden (a, e, o, u, y que Dios me ayude, sí, a veces y).

Aparte de eso, ¡simplemente llame a lo que es y termine!

— Dan Ray
fuente

99

Debo protestar! Claramente, el iterador interno debería llamarse j y el que está dentro de ese k . ¡La tradición matemática de larga data te está mirando por encima del hombro!

— Frank Shearar el

Huh Nunca he hecho j y k. Sin embargo, veo que es sensato.

— Dan Ray

8

Una de las razones por las que Dijkstra era tan natural para la informática era que su nombre incluía las tres variables iteradoras más comunes en el orden correcto.

— glenatron

3

@glenatron: ¡Finalmente, una forma de recordar cómo se escribe ese nombre!

— configurador el

4

Si no puedo encontrar un gran nombre de inmediato, utilizo un nombre "correcto" temporalmente, luego sigo codificando. Al menos será algo que describa adecuadamente el artículo, incluso si no es perfecto . Casi siempre, cuando termine de escribir el primer borrador de ese fragmento de código en particular, se me habrá ocurrido un nombre más perfecto. A través del proceso de codificación, mis intenciones con esa variable en particular se vuelven más claras. (Por otro lado, a veces se me ocurre que la variable to estaba mal concebida para empezar y la borro a favor de otra cosa).

— Nick Spreitzer
fuente

3

Lo llamo lo que creo que debería hacer la función, algo que más o menos transmite la intención. Una vez que se escribe el cuerpo de la función, me parece obvio cómo llamarlo y vuelvo a cambiarle el nombre si es necesario.

— Adam Lear
fuente

1

Esto no siempre funciona, especialmente cuando el desarrollador puede no estar familiarizado con la terminología o incluso la intención de la empresa / industria. Algo más genérico y obvio debe usarse para transmitir que necesita ser definido y cambiado más adelante. El OP parece estar preguntando cuándo se desconoce la intención y qué debe usarse inicialmente . Si el nombre es algo que más o menos transmite intención, entonces un buen nombre ya no está lejos.

— Spong

1

@sunpech En serio, incluso cuando comencé en un trabajo con un dominio bastante específico, no he tenido problemas para encontrar un nombre de función. Tal vez solo necesito escribir más funciones. :)

— Adam Lear

1

@sunpech: ¿Cómo puedes escribir una función sin saber lo que hace?

— configurador

44

@sunpech: no dije eso. Acabo de decir que no puedes escribir una función sin saber lo que está haciendo. No es posible. Nunca lo he visto suceder, y no veo cómo podría suceder. Tal vez estoy siendo tonto, pero cuando nombras una función DoFoo (), ¿qué demonios pones dentro de ella?

— Configurador

2

@sunpech: Nunca dije que los nombres tengan que ser 'buenos' desde el principio. Simplemente no veo cómo entraría en una situación en la que desea crear una función pero no sabe lo que va a hacer.

— Configurador

2

Foo y bar . Como todavía no hay significado detrás de nombrar funciones / variables, uso alguna combinación de Foo y / o Bar con lo que sea que esté tratando de definir.

Hace que sea más fácil buscar / encontrar más adelante cuando entiendo mejor cómo debe llamarse.

Ver también Foobar en wikipedia .

Los términos foobar, foo, bar y baz a veces se usan como nombres de marcador de posición (también conocidos como variables metasintácticas) en la programación de computadoras o en la documentación relacionada con la computadora. Se han utilizado para nombrar entidades como variables, funciones y comandos cuyo propósito no es importante y solo sirven para demostrar un concepto. Las palabras en sí mismas no tienen significado en este uso. Foobar a veces se usa solo; foo, bar y baz a veces se usan en ese orden, cuando se necesitan múltiples entidades.

— esponja
fuente

1

Prefije su función con algo y asígnele el mejor nombre por ahora. Por ejemplo, una función que guarda todos los productos para el usuario seleccionado en la base de datos podría ser RENAME_SaveAllProductsForTheSelectedUserToTheDatabase()

— Código difícil
fuente

Por supuesto, en este caso, solo debe nombrar la funciónSaveAllProductsForTheSelectedUserToTheDatabase()

— configurador

1

Como llamo a estas variables difíciles de nombrar, hago un //TODO find a better namecomentario para poder volver más tarde y cambiarle el nombre.

Por lo general, cuando comienzo a usar la variable / función / clase, encuentro un nombre mejor para ellos.

— usuario1041
fuente

0

¡Es mejor poner un buen nombre pronto mientras tenga el código en mente, que esperar hasta más tarde cuando deseará haberlo nombrado bien!

— Jon Onstott
fuente

0

Casi nunca tengo problemas para encontrar nombres buenos y descriptivos ... pero a veces los nombres se vuelven bastante redundantes, ya que los nombres de clase y variables son muy similares. WebClient webclient = nuevo Webclient (uri); ...y similares.

— Zaz
fuente

0

A veces uso zzzz temporalmente.

Una buena regla para ayudarte es esta:

¿Devuelve un valor booleano y no tiene efectos secundarios? Luego, use un adjetivo (comience con is, was) pero nunca en el futuro.
¿Devuelve un tipo diferente y no tiene efectos secundarios? Luego use un sustantivo.
¿No devuelve nada más que hacer algo? Luego usa un verbo.
¿Es una clase? Entonces usa un sustantivo.

— ctrl-alt-delor
fuente

-1

En el pasado, usaba mucho bob , pero esta sería la única variable no nombrada correctamente en la función / script porque de lo contrario el código se vuelve ilegible rápidamente.

(Bob es una resaca de uni días - salirse con las variables de llamada bob y fred)

Estoy feliz de usar i para un contador.

Es mejor usar nombres significativos, incluso si no son cortos y rápidos.

— Dan
fuente

He trabajado con un tipo que usaba nombres como ese para sus aplicaciones y clases dentro de sus aplicaciones. Quizás no hace falta decir que su código era generalmente muy pobre.

— dash-tom-bang

2

@ dash-tom-band: Creo que su código fue generalmente muy bob.

— configurador

Si puedo escribir mi nombre en alguna notación húngara para una enumeración, generalmente lo hago, incluso si es un poco exagerado. TPropertyEnhancmentTypeEditor = (PETEObtuse, PETEAwful, PETEDispicable);

— Peter Turner

-1

Si no tengo ni idea de cómo nombrar la variable, lo que no ha sucedido en más de veinte años ... nombres de viejas novias, o mujeres que desearía que fueran novias. El último código con esos identificadores se eliminó de la producción hace unos años.

— David Thornley
fuente

-2

WorkMagic o Abracadabra.

— Probador101
fuente

-2

bla , pero solo temporalmente. Siempre vuelvo y les cambio el nombre a buenos nombres de variables.

— Jason Berkan
fuente

1

Nunca uses esto. Nada mal.

— Dinámico

-2

Doit (), a (), b (c) xxxx () ....

Por supuesto, se refactorizan ... por lo general

— Sangha Preet
fuente

-3

Tiendo a usar cosas en mi escritorio.

taza
Alt
Foo
b / a / c (basura de una sola letra)
alk (basura pronunciable de varias letras)

También me inclino por los nombres genéricos (al menos para las funciones):

intercambiar
proceso
reviseVar
gitano

Sin embargo, esto es para cosas temporales. Yo juro no lo hace en el repositorio, y mucho menos la producción.

...

— Josh K
fuente

Siempre me siento sucio, pero a veces el nombre más aparente para un método es "Ir" o "DoIt". Siempre que puedo encontrar un nombre mejor, pero a veces realmente es "hacer el trabajo que el nombre del programa implica que está por ocurrir". Eso, sin embargo, es demasiado largo para usarlo para el nombre de una función. :)

— dash-tom-bang

@ dash-tom-bang: Por alguna razón, se runve mucho mejor que go. Tal vez sea porque a todos nos gustaría que nuestros programas sean más rápidos.

— configurador