¿Vale la pena preocuparse por las pautas de la convención de nombres?

13

Nombro mis variables usando las convenciones .Net:

  • camelCase para variables y campos (tiendo a usar _camelCase para campos privados en una clase)
  • PascalCase para métodos, propiedades y clases

El único lugar en el que me desvío es en las constantes y las enumeraciones donde en realidad prefiero el estilo Java SCREAMING_CAPS.

La base de código de mi compañía está llena de un estilo de notación pseudohúngara de VB6 y VBScript, si no es húngaro en toda regla, es decir,

  • s o str para cadenas
  • yo o int para Ints
  • d para decimal (o, a veces, doble)
  • o u obj para cualquier tipo de objeto

Cada vez que veo ese estilo de código utilizado en el código de otra persona (incluso en el código de campo nuevo, no solo en el código heredado) me estremezco, y me niego a usar ese estilo. En el pasado, comencé a estandarizar las convenciones de nomenclatura de .Net, que simplemente se ignoran: las personas que escriben en notación húngara continúan haciéndolo, aquellos de nosotros que no nos quieren siguen usando nuestro propio estilo; Tengo un poco de miedo de que si sí se estandariza (lo que sigo presionando, pero a nadie más parece importarle), estará en notación húngara y no en la forma recomendada y luego lo haré ser forzado a escribir código como ese.

¿Estoy haciendo una montaña de una colina en lo que respecta a esto? ¿No debería importarme si el código está lleno de identificadores redundantes y no de nombres descriptivos, y continúo usando mi propio camino y presioné para que se convierta en el estándar?

    
pregunta Wayne Molina 19.05.2011 - 14:58

8 respuestas

7

Lo único que debe preocuparte es que estás trabajando en un equipo donde a las personas no les importa limpiar un poco las cosas. Eso es muy triste.

Haz lo que haces, continúa usando el estilo moderno e invita a las personas (pero no les obligues) a que también lo adopten. Tomará tiempo, por supuesto. Después de un tiempo, verá si va a alguna parte y qué puede hacer a continuación.

P.S. ¿Qué tal si organizamos una reunión sobre este tema e invitamos a todos los involucrados? Luego recibirá toda su atención, denotará el problema y presentará su enfoque. Les dará algo en qué pensar. Quizás por tus intentos locales no te estén tomando muy en serio.

    
respondido por el user8685 19.05.2011 - 15:04
3

Creo que deberías preguntarte si la notación húngara está afectando o no tu rendimiento / calidad personal, o si es más sólo dañar tu ego. Por ego, quiero decir que las cosas generalmente funcionan bien, pero nunca querrías que alguien a quien respetas desde fuera viera el código vergonzosamente obsoleto. Si bien creo que esa preocupación tiene su propio mérito, tiene que compararlo con el impacto de calidad / productividad que tomarán todos los que tuvieron que cambiar.

Esto es una especie de pregunta técnica sobre la deuda, ya que está claro que este estilo húngaro no tiene sentido en .Net (con la excepción de las interfaces con "I", pero eso es para otro momento), sin embargo, este podría ser el tipo de deuda técnica con la que su equipo puede vivir hasta que desaparezca de forma natural .

    
respondido por el Morgan Herlocker 19.05.2011 - 15:22
2

El mejor argumento en contra de la notación húngara, además de los IDE modernos, que tienen muchos métodos para mostrar el tipo, la visibilidad y más elementos de una variable con el color, con pequeños símbolos y con información sobre herramientas mientras aspiran, es tomarlo en serio .

  • Fomente más distinción (b) ool (f) loat (c) har (l) ong (s) hort (conflictos con String? no: (S) tring), (v) oid.
  • Fomentar la codificación de la visibilidad. Soy de Javaland, y espero que también se ajuste a .net: (pri) vate, (pub) blic, (pro) tected (def) ault debe usarse.
  • .net tiene final / const? ¡Haz que sea un prefijo! ¿Oigo "volátil"?
  • ¿Por qué int y long necesitan un prefijo, pero diferentes objetos no? Eso no es lógico. Crear un abbrev.tab. donde cada nuevo objeto obtiene una abreviatura distinta.
  • Las variables que pueden ser nulas y similares, que nunca deben ser nulas, también pueden tener el prefijo. Las personas inteligentes ponen toda la DbC en el prefijo de una variable.

En serio: en la refactorización, puedes cambiar una variable de int a long, de String a char. No deberías necesitar cambiar el nombre, también.

En los IDE, los nombres a menudo se ordenan en un recuadro al lado. ordenados por nombre, donde es fácil de encontrar. Si la mayoría de las variables comienzan con o o i, es molesto para los ojos llegar a la parte significativa del nombre.

Los caracteres adicionales perturban la semántica de la variable. Un entero 'sane' obtiene 'i_sane', que se parece más a 'demente'.

La notación húngara fue útil en los idiomas, que carecen de un sistema de tipos. No lo necesitas, si el compilador impone tipos específicos. Si decoras tu lamento acerca de la notación húngara con un empático "sí, para los programadores mayores, ¡tenía sentido en el pasado usarlo! ', Esos programadores mayores pueden ser vanos y prefieren no ser identificados como antiguos.

Pero tienes que tener cuidado, para que la técnica funcione. Tal vez usted pueda bajar su voz cuando habla de "programadores de edad avanzada", para hacerles sentir, cuan cuidadoso es sobre ellos, cuánto necesitan la atención. Para que una tercera persona en la habitación lo reconozca, que está tratando de ocultar algo, lo que por supuesto aumentará su curiosidad.

    
respondido por el user unknown 19.05.2011 - 15:29
2

Compre una copia de Guías de diseño de marcos y colóquelas en el escritorio de su gerente (o quien esté controlando el estilo de codificación) . Asegúrese de colocar una nota publicitaria que apunte claramente a la introducción, en la que resalte la importancia de la coherencia. Para seguir manejando el punto, obtenga una copia de Clean Code y coloque un marcador allí en la sección relativa a las convenciones de codificación .

    
respondido por el Michael Brown 19.05.2011 - 15:50
1

En algunos aspectos, este es un tema subjetivo, y es uno de esos debates de programación (¿ortografía?) que entretengo por un tiempo y luego evito. Si bien creo que la notación húngara es un pecado que debería ser desterrado, creo que la coherencia es más importante.

En ese sentido, haré todo lo posible para convencer a un equipo de que use nombres de variables centradas en el dominio en lugar de convenciones de nombres basadas en tipos, pero si todo se complica, me retiraré para aceptar un estándar de nombres que todos deben cumplir con una base de código común.

No estoy a favor de algún estándar de mandato genérico impuesto por un grupo de estándares, pero los equipos de software desarrollan su propio estándar y, lo que es más importante, se adhieren a él.

    
respondido por el rupjones 19.05.2011 - 15:08
1

Con el resharper, el cambio de nombre de las variables es tan rápido que puedo deshacer las convenciones de nomenclatura consideradas tan rápidamente, que no tengo que dejar las antiguas convenciones mal dirigidas.

Si no tiene herramientas de refactorización, entonces, estoy de acuerdo con los otros comentaristas que han sugerido seguir la convención existente del código base tanto como pueda, incluso si estaba equivocado. (Hasta cierto punto, hay convenciones de nomenclatura de variables que se convertirán en generadores de errores si los dejas)

    
respondido por el MatthewMartin 19.05.2011 - 23:16
0

La mayoría de sus preocupaciones son válidas y le facilitarían la vida a un nuevo desarrollador y probablemente a su cordura. La única convención que todos deben adoptar son los nombres descriptivos. Debería poder llegar a un consenso al respecto sin cambiar drásticamente los estilos dependiendo de lo malos que sean. Para todo lo demás, espere hasta que esté a cargo o reemplace a los miembros actuales con nuevos desarrolladores que piensen y se sientan como usted.

    
respondido por el JeffO 19.05.2011 - 15:47
0

Mis desviaciones:

  • _PublicPropertyBacker
  • _private_property_backer
  • _privateMember
  • CONSTANT_MEMBER
  • privateFunction
  • param_
  • botón privado okBU; // etc. limite 3 caracteres
  • struct SOMESTRUCT // para estructuras de Pinvoke

Regiones de código genérico y diseño de archivo:

  • miembros
    • (privado | interno | protegido | público) X [estática] X [const / readonly]
  • propiedades
    • (privado | interno | protegido | público) X [estática] X [solo lectura]
  • constructores
    • (privado | interno | protegido | público) X [estática]
  • Comandos // cualquier cosa con retorno nulo o estado devuelto
    • (público | protegido | interno | privado) X [estática]
  • Controladores de eventos / privado /
    • (Control | Remoto | Servicio | Otro) Eventos
  • Funciones // consulta el estado, no debería tener efectos secundarios
    • (público | protegido | interno | privado) X [estática]
respondido por el Mark 13.07.2011 - 07:51

Lea otras preguntas en las etiquetas