¿Debo mantener las convenciones de nomenclatura incorrectas?

Question

Actualmente estoy trabajando en un sitio que pasó por Dios sabe cuántas manos de desarrolladores. Una de las cosas que no me gusta es que todas las tablas de la base de datos tienen el prefijo "tbl_" y todos los campos "fld_".

he comenzado a trabajar en una nueva característica y me encuentro ante el siguiente problema: si mis nuevas tablas de continuar con la vieja convención, o no?

Creo que debería, pero me siento estúpido hacerlo :)

Answer 1

Me gustaría mantener la misma convención .. Independientemente de si es malo o no, al menos, sería coherente. Y la consistencia será muy importante para el próximo desarrollador que se apodere del código.

Answer 2

Ir con la que nunca costos ruta menos, en dinero y recursos. Si no va a ahorrarle dinero para revisar y volver a labrar el suelo, no lo haga. Aprieta los dientes y avanza.

Answer 3

Si un estilo constante a través de la aplicación Me gustaría seguir la convención de nombres que hará que sea mucho más fácil en la próxima desarrollador.

Answer 4

Tiendo a mirar la escala involucrada. La consistencia de una mala convención de nomenclatura, para mí, es preferible a una multitud de diferentes en la misma base de código o base de datos.

Si hay un puñado de mesas y que con seguridad se puede cambiar, mi sentimiento es hacer el cambio. Pero cualquier cosa de escala o una aplicación en la que solo esté haciendo una corrección de errores probablemente no valga el tiempo y el esfuerzo necesarios.

Answer 5

"Si no está roto, no lo arregles"

Answer 6

Creo que se debe preferir la consistencia y seguir la convención ya se está utilizando.

Piensa en los desarrolladores pobres que vienen detrás de ti y tienen que lidiar con dos convenciones de nombres diferentes (la original y la nueva), ninguno de los cuales les gusta a los nuevos desarrolladores.

Answer 7

Siendo un contratista, me enfrento mucho con este problema. Aquí es mi 2 centavos:

Si no está roto, entonces el cliente está desperdiciando su dinero teniendo a cambiar eso. A menos que esté reescribiendo toda la aplicación, por lo general sigo con los antiguos (malos) estándares (al menos de esa manera, no tiene parte de la aplicación con una convención y otras partes usando algo diferente, esto mantiene el código legible por otra desarrolladores).

Answer 8

Bienvenido al mundo del mantenimiento. ;)

¿Quién puede decir que la próxima persona que trabaja en el sitio no despreciará la manera que lo hizo cosas?

Answer 9

Tiene dos opciones.

1. Cambia todas las convenciones de nomenclatura incorrecta por nuevas.
2. Utilice las convenciones antiguas.

Alguien mirará este código más adelante y deberá ocuparse de cualquier diferencia que cree. Eso significa que debe ser consciente de que otras personas se ven afectadas por esta decisión. Haga lo correcto si tiene tiempo, haga lo feo si no tiene el tiempo ... pero manténgalo constante.

Answer 10

Cualquier convención de nomenclatura es mejor que no/convención de nomenclatura incoherente.

Answer 11

Digo que lo cambie si hay una diferencia significativa entre el código anterior y el nuevo. Por ejemplo, si el camino anterior era terriblemente sin salida y la nueva forma es completamente independiente, entonces inicie una nueva convención.

Es bueno ser visualmente consistente si el nuevo material es estructural y semánticamente consistente, pero si lo que está haciendo es una ruptura limpia de lo que vino antes, entonces es incluso más importante que las cosas se vean diferentes.

Answer 12

Como todos dijeron, quédate con la mala convención ya que no la estás escribiendo desde cero. Sin embargo, use "buenas prácticas" si existe una necesidad apremiante (es decir, el usuario final se verá negativamente afectado de lo contrario). Por ejemplo, si la "mala convención" hace que los usuarios de la API utilicen el boxeo, cambie el valor de las cadenas y otro impacto de la interpretación en gran medida; no agregue al problema! El objetivo final del software y las API no es facilitar la vida de los desarrolladores; pero el usuario final. Los desarrolladores que permanecen en el negocio por mucho tiempo son muy conscientes de esto y usted quiere ser uno de esos desarrolladores.