¿Utiliza convenciones particulares para nombrar variables complementarias?

Question

A menudo me encuentro tratando de encontrar buenos nombres para pares complementarios de variables; donde dos variables denotan conceptos opuestos, dos participantes en algún tipo de duólogo, y así sucesivamente.

Esto podría explicarse mejor mediante un ejemplo de contador: mantengo una aplicación que imprime dos gráficos como parte de un anuncio impreso. Se almacenan en la base de datos como TopLogo y LowerLogo , que tengo que detener y volver a comprobar cada vez que los uso porque estoy esperando top para complementar bottom , y lower deben complementar upper .

Hay algunos ejemplos obvios que creo que funcionan bien:

cliente / servidor
source / target para copiar / mover datos o archivos de una variable a otra
mínimo / máximo

pero hay algunos conceptos que simplemente no se prestan a tales esquemas de nombres ordenados. Por ejemplo, al buscar en los registros, ¿"última" significa "final" o "anterior"? Hace poco vi un código que usaba firstPage , previousPage , nextPage y finalPage para evitar el ambicioso lastPage completamente, lo que pensé que era muy bueno, de ahí esta pregunta.

¿Tiene algún par de nombre de variable particularmente ordenado que quiera compartir con nosotros? (Los puntos de bonificación si tienen la misma longitud, lo que hace que el código sea mucho mejor en las fuentes monoespaciadas).

Answer 1

Al igual que con todo tipo de convenciones de estilo de código, coherencia es lo que debe esforzarse por lograr.

Me gustaría que el equipo de desarrollo esté de acuerdo con " estándar " pares de prefijos para escenarios comunes como " origen / destino " o " de / a " y luego seguir con ellos para todo el proyecto. Siempre que cada desarrollador sea consciente de lo que significa un prefijo particular en el código base, es más fácil evitar malentendidos.

Las excepciones a la regla se deben aclarar en la documentación si la variable forma parte de una API pública, o en comentarios dentro del código, si su visibilidad está restringida a una sola clase o método.

Answer 2

En mis bases de datos encontrará muchas tablas temporales de estado válido (" historial ") que contienen un par de columnas denominadas start_date y end_date . No hay puntos de bonificación para mí, entonces, porque prefiero usar el "final" que se usa comúnmente que intentar encontrar una alternativa intuitiva con la misma cantidad de caracteres que la palabra "comenzar".

Tiendo a preferir estos términos genéricos, incluso cuando los términos más específicos del contexto pueden ser viables, por ejemplo. prefiriendo employee_start_date sobre employee_hire_date (qué sucedió si su empleo comenzó por una razón distinta a la contratación formal, por ejemplo, su compañía fue el objeto de una adquisición). Dicho esto, prefiero person_birth_date en lugar de person_start_date :)

Answer 3

Mientras que uno intenta ser semánticamente coherente en los casos obvios, por ejemplo, el máximo va con el mínimo, y no " el más bajo " - en un código OO bien estructurado (que no es todo el código, lo sé) el problema desaparece con un buen IDE. Las clases son cortas, los métodos son cortos y las variables son pocas en cada método. Por lo tanto, no importa cómo se llaman los pares de variables siempre que estén claros. Es posible que su código no parezca profesional, pero la calidad real está en el código, no en el aspecto de su código.

El problema desaparece aún más si hay un buen JavaDoc o cualquiera que sea el sistema de documentación, y si tienen buenos nombres de clase que los acompañan. Por ejemplo, si tiene una instancia de una clase de Connection y tiene un método llamado setDestination , está bien, pero si sabe que setDestination toma un parámetro llamado < code> destination y es de la clase Server , estás bien ... aunque es posible que prefieras llamarlo target , aimHere , placeToSendTheData o lo que sea (y los nombres correspondientes, fuente , comingFromHere y placeToGetTheDataFrom ). Además, el sistema de documentación dice para qué sirve , y eso no tiene precio.

Esta próxima cosa puede sonar estúpida y estoy seguro de que me rechazarán aquí en StackOverflow, pero los nombres de variables de sonido no profesionales únicos tienen una gran ventaja: sé que mis variables tienen nombres como placeWeWantTheDataToGo (y el IDE se encarga de escribirlo), pero el " serio " los tipos que hacen el JDK nunca nunca usarían nombres tan tontos. Entonces sé inmediatamente que la variable es mía. Por cierto, cuando trabajé con desarrolladores en España e Italia, escribieron códigos con nombres de variables en español (no siempre, pero generalmente). Esto provoca el mismo efecto: podemos ver rápidamente que la clase Conexion es nuestra, pero la clase Connection no lo es.

[Además, en lugar de escribir los nombres de las variables, asigne una cadena constante en algún lugar de su código y utilícela, de modo que si la llamaron más baja o más baja en lugar de baja, todavía está bien.]

Answer 4

Sí, intento nombrar conjuntos complementarios de variables de manera sistemática para que la simetría sea clara. No siempre es fácil; A veces, ni siquiera es posible. Bueno, no es posible usar las reglas que me impongo, lo que significa que generalmente trato de tener los nombres de la misma longitud. El ejemplo 'superior' y 'inferior' me volvería loco (suponiendo que ya no lo soy, lo que está lejos de ser cierto); Probablemente use 'superior' y 'inferior' porque son de la misma longitud; 'top' y 'bottom' me frustrarían también por la diferencia de longitud.