coding-style - microsoft - k&r coding style
El argumento "Debería ser fácil para que un desarrollador junior lo entienda" (25)
¿Alguien realmente piensa que esta es una buena razón para "simplificar" tu código? Cuando un gerente le pide que haga que su código sea simple (en términos de las habilidades tecnológicas necesarias para comprenderlo) a costa de un código más detallado y desordenado, ¿qué debe hacer?
Bueno, creo que es razonable evitar el uso de construcciones de lenguaje "inteligentes" a menos que realmente mejoren el código. En ese momento, si un desarrollador junior lo ve, con suerte lo preguntaría en lugar de simplemente deslumbrarlo.
Aquí hay una forma alternativa de expresarlo: "Escribe tu código para que sea fácil entender que si te llaman a las 3 de la mañana y te piden que corrija un error, aún puedes entenderlo".
En serio, hazlo tan fácil de entender como sea posible. Eso no significa un comentario de cada dos líneas, sino un comentario en el que el objetivo de un fragmento de código no es obvio, y solo cuando la opción preferida de "bien hacerlo obvio" no funciona.
Bueno, si tiene la intención de mantener su código para siempre, nunca cambie de trabajo, nunca sienta la necesidad de trabajar en algo nuevo, y pueda asegurarle a todos que nunca será golpeado por un camión, entonces seguro que no hay necesidad de atontar ese código de rompecabezas.
Creo que es la forma del administrador de decirle cortésmente que su código es demasiado ofuscado / complejo / confuso / código de rompecabezas ... como quiera llamarlo. A veces nos involucramos tanto escribiendo nuestros códigos que olvidamos que alguien más tendrá que venir y leerlo más tarde.
Debería recordarle a su jefe que puede construir cohetes o gallineros, y que tendrá que pagarle lo mismo por cualquiera de los dos. Haz lo que dicen, pero en general, un entorno como ese se presta a las personas que buscan un nuevo entorno.
Depende del código. ¿Esto se envía en su producto insignia que requiere el uso de las funciones que su gerente desea que elimine por razones de rendimiento? Si la respuesta es sí, trataría de que su gerente le permita conservar el código y simplemente escriba un documento explicando en detalle la sección de código que es difícil de entender. Si se trata de una aplicación interna que necesita ser mantenida por muchas personas diferentes y las funciones complejas se pueden eliminar sin afectar negativamente al programa, elimínelas y elija batallas más importantes para luchar.
Es un acto de equilibrio ...
Si 3 personas de tu equipo pueden "leer" tu código y saber qué está haciendo ... no es necesario cambiarlo. Sin embargo, si eres la única persona que puede entender tu código (no importa qué tan inteligente / inteligente seas), tal vez deberías bajarlo unas cuantas muescas.
Otra guía para ayudar sería ''Prueba lo más simple que funciona''. Todas las últimas palabras de moda son buenas de saber, sin embargo, lo que es aún más importante es tener la habilidad para detectar dónde podría sobrevivir sin usarlas. No necesita pulverizar para pintar su código con IOC o Frameworks o Patrones de diseño ...
El lado del gerente de este argumento se echa mucho de menos en este hilo :) (y para el registro ... no soy uno). Su principal preocupación es que no quiere un área oscura de código en la que nadie más se atreva a aventurarse ... así que si puedes convencer a tu jefe de que algunas otras personas en el equipo pueden hacer una solución arbitraria (o mejor aún) .. muestre un error real arreglado por otra persona) - el administrador de identidad debería dejarlo sin trabajo. En desacuerdo con su jefe es otro arte :) .. pero usted puede hablar de cosas por lo general.
No tienes que ir todo el camino hacia atrás hasta el Denominador Común Más Bajo ... lograr un equilibrio.
Estoy de acuerdo al 100% con el argumento. Con una gran adición: capacite a sus desarrolladores junior hasta que comprendan su código ;-)
Estoy hablando de usar tecnologías "inusuales". En este caso es JQuery. Este problema surgió cuando estaba escribiendo un control de asistente para el registro de usuario. El menú de navegación debe personalizarse y el paso actual en el asistente debe tener una clase de CSS diferente en el menú. Esto significaba que necesitaba tener acceso al paso seleccionado actualmente al generar el menú. Mi solución fue generar el índice del paso actual en un campo html oculto que luego JQuery podría leer para personalizar el CSS.
Pensé que esto era mucho mejor y más limpio que usar la sintaxis de enlace de datos en ASP.NET que no tiene verificación en tiempo de compilación y estropea el diseño del html.
Las soluciones de enlace de datos son "estándar" mientras que JQuery es "inusual", lo que significa que es menos probable que sea entendido por un junior.
Cada vez estoy intentando más y más para proporcionar los datos necesarios para la IU en lugar de hackearlos en la IU con enlaces de datos, por lo que agregué el campo oculto con el índice de pasos actual.
Estoy muy en desacuerdo. Los desarrolladores junior terminarán siendo desarrolladores Senior. ¿Cómo? Al encontrar temas avanzados que no se enseñan en la escuela.
Mi base de código ahora hace un uso intensivo de los contenedores de Inversión de control . Nunca revertiría mi código al viejo estilo porque un desarrollador junior tenía problemas para crear IoC. En cambio, los sacaba a tomar una cerveza después del trabajo y la discutía. Cuanto más aprende el desarrollador junior, menos necesidad de mano hay que hacer.
Aquí hay una publicación en el blog sobre este tema.
Hay una diferencia entre el código del rompecabezas y el código complejo.
Descubrí que el mayor problema es que hay una gran diferencia entre "fácil de entender por lectura" y "bien factorizado", y que los dos objetivos a menudo están en tensión directa entre ellos. En el código bien factorizado, hay mucho más saltos entre clases y mucho despacho virtual, por lo que la ruta a través del código es muy no lineal.
Lo aprendí de la manera difícil y, en retrospectiva, descubrí que era la mejor manera. Deje que el ciclo se repita.
No estoy de acuerdo con el gerente: lo que debe ser simple es el código, no la tecnología utilizada para escribirlo.
Sin embargo, impongo un requisito estrechamente relacionado:
- La documentación interna establece claramente qué tecnologías se necesitan para comprender este código y proporciona referencias sobre lugares donde se pueden aprender esas tecnologías.
Por ejemplo, incluso como desarrollador sénior, encuentro que todos los códigos matriciales son desconcertantes. Pero si alguien me da una referencia a la parte correcta de Recetas Numéricas , puedo descifrar los detalles.
No. En el pasado, aprendí mucho al ver los trucos de desarrolladores más experimentados. Preferiría haber tenido la oportunidad de aprender algo nuevo de ellos que haberlos hecho pasar por cosas tontas.
Sí, la legibilidad y la facilidad para comprender el código son, en mi opinión, una gran parte de la mantenibilidad.
Scott Muc dijo:
"He descubierto que el mayor problema es que hay una gran diferencia entre" fácil de entender por lectura "y" bien factorizado ", y que los dos objetivos a menudo están en tensión directa entre sí. código, hay mucho más saltando entre las clases y un montón de despacho virtual, por lo que la ruta a través del código es muy no lineal ".
Citado por la verdad, y creo que este es uno de los mayores problemas con el código C ++ en general. Si usted es el que escribió el código, es bastante fácil encontrar un conjunto muy complicado de cosas que tenga en cuenta, tiene mucho sentido si ya lo conoce, funciona bien y, en general, se asemeja a un cristal de diamante, etc. . pero que, desde la perspectiva de alguien que está tratando de descubrir cómo llegó allí y por qué las cosas son como son y cómo funcionan las cosas, y cómo uno puede hacer cambios que encajan en el sistema existente y satisfacer nuevos requisitos, es casi completamente opaco e impenetrable.
¿Cómo ayuda este tipo de situación a la mantenibilidad? Esa situación es una de mis principales preocupaciones con los programadores de C ++. Es mucho mejor tener un lío de código C simple que puede ser pirateado que un cristal de diamante con un código increíblemente superfactorizado que casi nadie puede descifrar cómo modificar sensiblemente sin romper la estructura cristalina.
Si entorpeces tu código, estarás trabado trabajando con programadores principiantes ficticios que nunca estarán familiarizados con las técnicas avanzadas de codificación. Si hay algún código detallado que intente expresar un procedimiento inherentemente complejo que usted escribió, el desarrollador junior antes mencionado probablemente no podría ver el bosque para los árboles de todos modos. Y probablemente se equivoquen si tuvieran que expresar un concepto complejo si todo lo que sabían fueran construcciones básicas primitivas, mientras que si supieran cómo expresar lo que querían decir escueta y elegantemente, el código tiene más posibilidades de ser correcto.
Si está constantemente embotando su código o diseño, es una forma muy buena de asegurarse de que sus desarrolladores junior se mantengan en silencio. Desafíelos y úselos como una oportunidad de tutoría. Por supuesto, algunos nunca aprenderán, pero tienes problemas más grandes en ese punto.
Tampoco son solo jefes de pelo puntiagudo. Como desarrollador sénior, a menudo es difícil resistir el impulso de los desarrolladores más jóvenes de mamá. "Oh, haré esta parte porque es demasiado difícil para ellos", o les llevará demasiado tiempo, o se van a poner en la hierba.
Y, por último, asegúrate de encontrar un equilibrio entre el código idiomático que utiliza todo el poder de un idioma frente a un código idiomático que abusa de ese poder. No hay ninguna razón por la que deba anular el || operador solo para ejecutar sus argumentos en dos hilos separados. Al menos tonte el código un poco para tu ser más viejo, tonto y futuro.
Su objetivo no debe ser que su código sea fácil de entender para un desarrollador junior. En cambio, debería ser fácil de entender para un programador de mantenimiento.
Esto significa:
- La "complejidad" local está bien, cuando sea necesario. Si ven el código complejo sabrán que necesitan cavar más profundo.
- La complejidad oculta es mala. Si no puede ver que cambiar un fragmento de código tendrá efectos secundarios sutiles, mantener el código será una pesadilla.
- Las nuevas tecnologías que son visibles también están bien, cuando no se llevan al extremo.
Esto se debe a que aquellos que mantienen el código rara vez tienen la misma comprensión general del sistema. O el tiempo para desarrollarlo.
Sugiero mantener el código en un "nivel geek" y comentarlo bien para que los juniors puedan entender la intención detrás del código y al mismo tiempo aprender una mejor manera (o una forma correcta) de codificar, para que tengamos lo mejor de ambos. mundos.
Una forma de "simplificar" el código que realmente creo que es una práctica excelente es usar nombres de variables más largos y nombres de funciones más largos. Nombrar variables y funciones para que su propósito sea fácilmente comprensible es una tarea de ingeniería significativa, en mi humilde opinión, y requiere un esfuerzo extra por parte del autor original del código. Damian Conway tiene algunos excelentes ejemplos en "Mejores prácticas de Perl". Algunos ejemplos incluyen: Prefiero " final_total" to "sum "; prefiera " next_client" to "next_elem" previous_appointment" to "previous_elem" , prefiera " next_client" to "next_elem" . Prefiere "sales_records" a "datos" . Etc. También impulsa el uso de plantillas gramaticales (Noun-adjetivo) y se mantiene constante. No use max_displacement un lugar y luego use VelocityMax en otro. Las variables de índice también necesitan nombres reales:
sales_record[i] vs sales_record[cancelled_transaction_number]
Frecuentemente "refactorizo" mi código al final de un ciclo de desarrollo al encontrar nuevos nombres para todas mis funciones y variables. En un editor moderno, es trivial cambiarlos a todos, y es solo al final que realmente descubro para qué los utilicé. El código "estúpido" de esta manera no es el clásico C, pero es más fácil para mí cuando vuelvo meses más tarde preguntando si era WTF.
Asegúrese de que pueda entender lo que hace 6 meses después.
En caso de duda, COMENTA tu código. Para eso son los comentarios.
Conozco desarrolladores que escribieron código altamente ofuscado que pensaban que era avanzado pero que el resto del equipo consideraba ilegible e imposible de mantener. Parte de esto implicó el uso excesivo de características avanzadas del lenguaje (en C, el operador ternario y el operador de coma) y escribir en un idioma personal oscuro (por ejemplo, reemplazar el elemento ptr-> con (* ptr) .item en todas partes) que nadie más podría alguna vez ser capaz de mantener. El autor intentaba ser más astuto que el optimizador (lo cual, para ser justos, estaba lejos de ser bueno).
Nota: No estoy sugiriendo que "x = (p == NULL)?" Default ": p-> value;" es complicado, pero cuando alguien utiliza operadores ternarios que abarcan muchas líneas, están anidados y hacen un uso intensivo del operador de coma, el código se vuelve rápidamente ilegible.
En este tipo de caso, "embrutecer" el código hubiera sido una buena idea. El problema no eran los algoritmos avanzados ni las características avanzadas del lenguaje, sino el uso excesivo y inapropiado de las características avanzadas del lenguaje y un idioma personal oscuro.
Sin embargo, en el caso sobre el que pregunta, donde los cambios del gerente hacen que el código sea más difícil de leer y mantener, estoy de acuerdo con usted y los demás que han respondido. Solo quería señalar la alternativa que nadie más ha mencionado.
La cita anterior es apropiada aquí:
Hacer todo lo más simple posible, pero no más sencillo.
Sí. Es una razón muy válida para llevarlo a un nivel inferior. La realidad es que un número muy grande de desarrolladores (como en la mayoría) están en el nivel junior.
En cuanto a lo que debes hacer ... Di "Sí, señor" o "Sí, señora" y hazlo. Solo hay un jefe en esa relación.
ACTUALIZACIÓN: Como algunas personas parecen pensar que teniendo un desarrollador jr aprendiendo temas avanzados mientras navegan a través del código ofuscado quiero lanzar una cosa más aquí.
Cuando CUALQUIER desarrollador (jr o no) se encuentra con un código que no comprende, su primer enfoque es refactorizarlo en algo que sea comprensible. Esto se llama síndrome de "¡Vaya, ese código es una mierda, debo reescribirlo!". Estoy dispuesto a apostar que todos en este tablero lo han experimentado. Entonces, como propietario de un negocio, ¿quiero pagar para que se desarrolle el código cada vez que viene una nueva persona o quiero pagar para que se agreguen nuevas funciones?
Adivina a qué persona me voy a quedar por más tiempo.
Simplemente es imposible progresar o innovar en cualquier industria sin hacer cosas que otros no entienden. La innovación es necesariamente una blasfemia. ¿Por qué? Porque si estás haciendo cosas que tienen sentido para todos los que te rodean, lo más probable es que no seas el primero en hacerlo. ;)
Dicho esto, hay una diferencia significativa entre hacer algo que es difícil de entender, simplemente porque es un problema nuevo o complicado en lugar de hacer algo que es difícil de entender porque estás tratando de presumir o crees que confundir a la gente de alguna manera te ganará un trabajo seguridad (que nunca he visto funcionar, pero he oído que la gente lo intenta).
¿Deberías hacer las cosas fáciles de entender? Sí absolutamente, tanto como sea humanamente posible. Sin embargo, un programa que funciona y hace bien su trabajo es la prioridad más alta.
La queja del gerente nunca debería ser "no hagas esto porque nuestros muchachos menores no lo entienden", solo debería ser "hacer x en lugar de y siempre que sea factible porque x es más fácil de leer / entender". Esto también supone que xey son equivalentes (acepta la misma entrada y produce el mismo resultado).
No soporto cuando los gerentes hacen eso ... He tenido tres gerentes diferentes que me gritan por utilizar un código perfectamente normal tal como está diseñado para funcionar, no porque estuviera haciendo algo complicado, sino porque se sentían como fue demasiado esfuerzo para los otros muchachos de nuestro equipo ir a RTFM en el idioma que estábamos usando. Como estrategia de gestión, eso es totalmente al revés. Es como ser la Santa Iglesia Católica Romana e insistir en que los laicos son demasiado tontos como para confiar en la alfabetización.
Si quieres saber realmente lo ridículo que son algunos de estos gerentes, intenta esto: tuve un gerente que me gritó por declarar una variable como un tipo de "booleano" porque no sentía que los otros programadores pudieran manejarlo. En realidad, cuando le pregunté por qué, su respuesta fue "porque no hacemos eso aquí", lo cual es una falta de respuesta, pero lo interpreté como que significa "atontarlo". También me regañaban por eso y por prácticas similares, como si fuera obvio que los buenos hábitos de programación eran "malos" y que ya debería saber por qué, aunque nunca expresaron un estilo de programación preferido (formal o informalmente). Huelga decir que fue un mal trabajo.