¿Debo seguir un estilo de codificación incorrecto solo para seguir las convenciones establecidas en mi lugar de trabajo?

102

He estado trabajando en mi trabajo durante aproximadamente un año. Principalmente trabajo en nuestra interfaz GUI que usa métodos de un backend C, pero generalmente no tengo que tratar con ellos excepto los valores de retorno. Nuestra GUI está estructurada de manera bastante razonable, dadas nuestras limitaciones.

Me han asignado la tarea de agregar una función a la parte de la línea de comandos del programa. La mayoría de estas funciones son como 300 líneas largas y difíciles de usar. Estoy tratando de reunir partes de ellos para obtener información específica de alarma, y estoy teniendo problemas para mantenerme organizado. Sé que estoy haciendo mis pruebas más complicadas al realizarlas en una sola función larga.

¿Debo mantener todo en una función enorme según el estilo de las funciones existentes, o debo encapsular las alarmas en sus propias funciones?

No estoy seguro de si es apropiado ir en contra de las convenciones de codificación actuales o si debo morder la bala y hacer que el código sea un poco más confuso para mí.

En resumen, estoy comparando

showAlarms(){
    // tons of code
}

contra

showAlarms(){
   alarm1();
   alarm2();
   return;
}

alarm1(){
    ...
    printf(...);
    return;
}

EDITAR: Gracias por el consejo de todos, decidí que diseñaría mi código factorizado, y luego les preguntaría qué querían, y si lo quieren todo en uno solo puedo cortarlo de mi código factorizado y convertirlo de nuevo en 1 gran función. Esto debería permitirme escribirlo y probarlo más fácilmente, incluso si lo desean todo el código en una sola definición.

ACTUALIZACIÓN: Terminaron siendo felices con el código factorizado y más de una persona me ha agradecido por sentar este precedente.

    
pregunta Justin 12.12.2016 - 22:38
fuente

10 respuestas

101

Esto es realmente entre tú y tus compañeros de equipo. Nadie más puede decirte la respuesta correcta. Sin embargo, si me atrevo a leer entre líneas, el hecho de que llame a este estilo "malo" da cierta información que sugiere que es mejor tomárselo con calma. Muy pocos estilos de codificación son realmente "malos". Hay algunos que yo no usaría, pero siempre tienen una rima o una razón para ellos. Esto sugiere, para mí, que hay más en la historia de lo que has visto hasta ahora. Preguntar alrededor sería una llamada muy sabia. Alguien puede saber algo que tú no sabes.

Me encontré con esto, personalmente, en mi primera incursión en la codificación de misión crítica en tiempo real. Vi código como este:

lockMutex(&mutex);
int rval;
if (...)
{
    ...
    rval = foo();
}
else
{
    ...
    rval = bar();
}
unlockMutex(&mutex);
return rval;

Siendo el brillante y brillante desarrollador de OO C ++ que era, inmediatamente los llamé a los riesgos de errores que tenían al bloquear y desbloquear los mutex de forma manual, en lugar de usar RAII . Insistí en que esto era mejor:

MutexLocker lock(mutex);
if (...)
{
    ...
    return foo();
}
else
{
    ...
    return bar();
}

Mucho más simple y es más seguro, ¿verdad ?! ¡Por qué es necesario que los desarrolladores recuerden desbloquear sus mutexes en todas las rutas de flujo de control cuando el compilador puede hacerlo por usted!

Bueno, lo que descubrí más tarde fue que había una razón procesal para esto. Tuvimos que confirmar que, efectivamente, el software funcionaba correctamente, y había una lista finita de herramientas que se nos permitió usar. Es posible que mi enfoque haya sido mejor en un entorno diferente, pero en el entorno en el que estaba trabajando, mi enfoque multiplicaría fácilmente la cantidad de trabajo involucrado en la verificación del algoritmo diez veces, porque simplemente incorporé el concepto C ++ de RAII en una sección del código. que se estaba cumpliendo con estándares que realmente eran más susceptibles al pensamiento de estilo C

Entonces, lo que me pareció un estilo de codificación malo y francamente peligroso para mí fue realmente bien pensado y mi "buena" solución fue la peligrosa que iba a causar problemas en el futuro.

Así que pregunta alrededor. Seguramente hay un desarrollador senior que puede trabajar contigo para entender por qué lo hacen de esta manera. O bien, hay un desarrollador senior que puede ayudarlo a comprender los costos y beneficios de un refactor en esta parte del código. De cualquier manera, pregunte por ahí!

    
respondido por el Cort Ammon 13.12.2016 - 18:27
fuente
84

Honestamente, ¿cree que tener funciones que son difíciles de usar, con 300 líneas, es solo una cuestión de estilo? Entonces, ¿seguir el mal ejemplo podría mantener al programa en general en un mejor estado debido a la consistencia? Supongo que no lo crees, de lo contrario no habrías hecho esta pregunta aquí.

Mi conjetura es que estas funciones son tan largas porque en nuestro negocio hay muchos programadores mediocres que simplemente acumulan características sobre características, sin importar la legibilidad, la calidad del código, la denominación adecuada, las pruebas unitarias, la refactorización, y nunca han aprendido a hacerlo. crear abstracciones adecuadas. Tienes que decidir por ti mismo si quieres seguir esa manada o si quieres ser un mejor programador.

Addendum, debido a los comentarios: "300 líneas" y "difícil de usar" son indicaciones sólidas IMHO para el código incorrecto. Según mi experiencia, es muy poco probable que exista alguna "razón técnica oculta" por la que tal código no pueda implementarse de una manera más legible, comparable al ejemplo de la respuesta de Cort Ammon. Sin embargo, estoy de acuerdo con Cort. Debería discutir esto con los responsables del equipo, no para encontrar razones oscuras por las que no se puede cambiar el código o este "tipo de estilo", sino para averiguar cómo se puede volver a redactar el código de forma segura sin romper las cosas. .

    
respondido por el Doc Brown 12.12.2016 - 23:00
fuente
42

No.

En el libro Pragmatic Programmer el autor habla sobre el Teoría de la ventana interrumpida .

Este estado teórico:

  

Considere un edificio con algunas ventanas rotas. Si las ventanas no se reparan, la tendencia es que los vándalos rompan algunas ventanas más. Eventualmente, pueden incluso entrar en el edificio, y si está desocupado, tal vez se convierta en ocupantes ilegales o incendios ligeros dentro.

     

O considerar un pavimento. Se acumula un poco de basura. Pronto, más basura se acumula. Eventualmente, las personas incluso comienzan a dejar bolsas de basura de restaurantes de comida para llevar allí o incluso a entrar en autos.

En el libro, el autor escribe un paralelo entre esta teoría y el código. Una vez que encuentra un código como este, se detiene y se pregunta a sí mismo esa misma pregunta.

Y la respuesta es: No.

Una vez que deje esta ventana rota, en nuestro caso, código incorrecto, se creará el efecto de que todos dejarán atrás las ventanas rotas.

Y un día el código se colapsará.

Proporcione una copia de Clean Code y Clean Coder para todos.

Y mientras está en el tema, una copia de TDD también es buena.

    
respondido por el linuxunil 12.12.2016 - 23:14
fuente
25

Sí, ve por ello. Estructura! = Estilo

Estás hablando de estructura, no de estilo. Las pautas de estilo no (generalmente) prescriben la estructura, ya que la estructura generalmente se elige por su idoneidad para un problema específico, no por una organización.

Ten cuidado

Solo debes estar seguro de que no estás causando consecuencias negativas en otras áreas que quizás no te hayan ocurrido. Por ejemplo,

  • Asegúrese de que no está complicando diferencias o combinaciones de códigos porque ha eliminado cualquier parecido con el código existente.
  • Asegúrese de que la excepción fluya correctamente y que los rastros de la pila no estén contaminados con una gran cantidad de tonterías ilegibles.
  • Asegúrese de que no está exponiendo accidentalmente puntos de entrada públicos que podrían causar problemas si se los llama directamente (no los coloque en el mapa o no los exporte).
  • No abarrote el espacio de nombres global, por ejemplo, si todas sus funciones más pequeñas requieren algún tipo de contexto global que se haya declarado previamente en el ámbito de la función local.
  • Asegúrese de mirar los registros y pregúntese si estaba en el equipo de soporte si los registros generados por su código serían confusos cuando se vean entretejidos con los registros de cualquier código que no toque.
  • Asegúrese de que do se adhiere al estilo existente, por ejemplo. incluso si están usando la notación húngara de la vieja escuela y te sangran los ojos, mantén la coherencia con el código general. Lo único más doloroso que leer la notación húngara es leer el código que utiliza una docena de tipos diferentes de notación, dependiendo de quién escribió qué.

Sé amable

Recuerda que eres parte de un equipo, y si bien el buen código es importante, también es muy importante que los miembros de tu equipo puedan mantener las cosas que escribiste cuando te vas de vacaciones. Trate de mantener un flujo que tenga sentido para las personas que están acostumbradas al estilo antiguo. ¡El hecho de que seas el chico más inteligente de la sala no significa que debas hablar por encima de las cabezas de todos!

    
respondido por el John Wu 13.12.2016 - 04:03
fuente
6

No veo esto como una convención de código. Veo esto como alguien que no entiende cómo escribir código de mantenimiento que sea fácil de entender. Dividiría su código en diferentes funciones a medida que sugiera y educe a su equipo sobre los beneficios de hacer esto al mismo tiempo que trato de comprender por qué creen que las funciones de 300 líneas son aceptables. Me interesaría mucho escuchar su razonamiento.

    
respondido por el Bernard 12.12.2016 - 22:59
fuente
5

La respuesta está en la revisión del código.

La verdadera pregunta es si si ingresas un código bien factorizado, ¿serás el único que estará dispuesto a trabajar con él?

Yo, como la mayoría de la gente aquí, creo que las funciones de 300 líneas son una abominación. Sin embargo, llevar a Windex a un vertedero no va a hacer mucho bien. El problema no es el código, son los codificadores.

Sólo tener razón no es suficiente. Necesitas vender gente en este estilo. Al menos al leerlo. Si no terminas como este pobre: despedidos porque tus habilidades están muy por encima de tus compañeros de trabajo

Comience con poco. Pregunte y averigüe si alguien más prefiere las funciones más pequeñas. Mejor aún, busque en el código base y vea si puede averiguar quién escribe los más pequeños (es posible que el código más feo sea el más antiguo y que los codificadores actuales estén escribiendo un código mejor). Hable con ellos sobre esto y vea si tiene un aliado. Pregunte si conocen a alguien más que sienta lo mismo. Pregunte si conocen a alguien que odie las funciones pequeñas.

Reúna a este pequeño grupo y hable sobre hacer cambios. Muéstrales el tipo de código que te gustaría escribir. Asegúrate de que puedan leerlo. Tome cualquier objeción en serio. Hacer los cambios. Obtenga su código aprobado. Ahora tienes el poder de una reunión detrás de ti. Un poco más de estos y puede producir un documento de una página que acepte explícitamente el nuevo estilo que ha introducido.

Las reuniones son cosas sorprendentemente poderosas. Pueden producir influencia. Clout es lo que usarás para luchar contra quienes se oponen a este movimiento. Y eso es lo que es esto en este punto. Un movimiento. Estás luchando por el derecho a mejorar el status quo. La gente teme el cambio. Tendrá que hablar dulce, engatusar, y prod. Pero con un poco de suerte, volverás a ser aceptado.

    
respondido por el candied_orange 13.12.2016 - 02:51
fuente
3

A veces tienes que seguir el flujo.

Como usted dijo, se le ha asignado la tarea de implementar una función en una base de código de trabajo existente.

Independientemente del desorden, y entiendo que es tentador limpiarlo. pero en el mundo de los negocios no siempre tienes la oportunidad de refactorizar el código.

Yo diría que simplemente haga lo que se le ha pedido que haga y siga adelante.

Si cree que vale la pena refactorizar o reescribir lo que necesita para discutirlo con el equipo.

    
respondido por el meda 13.12.2016 - 02:11
fuente
3

Antes de hacer la declaración de que las prácticas son malas, primero daría un paso hacia la comprensión de la razón de los grandes métodos y otras prácticas que podrían resultar malas.

Entonces, deberías asegurarte de que la cobertura de la prueba sea bastante alta o muy alta (hasta donde puedas sin una refactorización importante). Si no lo es, trabajaría para que la cobertura fuera realmente alta, aunque no haya escrito el código. Esto ayuda a crear una buena relación y el nuevo equipo tuyo te tomará más en serio.

Una vez que haya cubierto estas bases, nadie en su sano juicio lo desafiaría. Como elemento de bonificación, realice algunas evaluaciones comparativas y eso se agregará a su caso.

A menudo, la forma en que lo pronuncias contribuye en gran medida a cambiar la cultura del código. Predicar con el ejemplo. O incluso mejor, espere un fragmento de código que pueda escribir (refactor y prueba de unidad, y viola), lo oirán.

    
respondido por el skipy 13.12.2016 - 03:44
fuente
3

Este tipo de pregunta es básicamente " lee mis compañeros de equipo ". Las personas aleatorias en Internet no pueden hacer eso, por lo que todas las respuestas que obtendrás son simplemente opiniones personales de la gente sobre el estilo de codificación. El consenso es que los métodos más cortos son preferibles, pero parece que ya lo piensas tú mismo, por lo que no es necesario repetirlo.

Por lo tanto, la base de código actual parece usar un estilo de codificación diferente al que usted prefiere. ¿Qué debes hacer? Primero necesitas averiguar:

  1. ¿Es esta una decisión de diseño deliberada respaldada por su equipo actual?
  2. ¿Quieren que sigas este estilo?

Solo hay una forma de averiguarlo. Preguntar .

Puede haber múltiples razones para tener funciones largas. Podría ser porque el equipo cree que las funciones largas son mejores que las múltiples funciones cortas. También podría ser porque es un código heredado, y el equipo prefiere que el nuevo código siga un diseño más limpio. Por lo tanto, la elección de cualquiera de las dos podría llevarte a un problema como desarrollador, si no hablas con el equipo y entiendes su razonamiento.

    
respondido por el JacquesB 13.12.2016 - 11:12
fuente
1

Hay diferentes niveles de "estilo".

En un nivel, generalmente parte de las convenciones de codificación, esto significa dónde colocar espacios en blanco, líneas en blanco, corchetes y cómo nombrar las cosas (mayúsculas y minúsculas, guiones bajos, etc.).

En otro nivel está el modelo de programación, a veces cosas como evitar las estáticas o usar interfaces sobre clases abstractas, cómo exponer dependencias, tal vez incluso evitar algunas características del lenguaje esotérico.

Luego están las bibliotecas y los marcos en uso por el proyecto.

A veces habrá un límite máximo en el tamaño de la función. ¡Pero raramente hay un límite mínimo! Por lo tanto, debes averiguar cuáles de estas cosas son las potencias que se consideran importantes y tratar de respetarlas.

Debe averiguar si el equipo es adverso a refactorizar el código existente, lo que debe hacerse independientemente de agregar un nuevo código cuando sea posible.

Sin embargo, incluso si no quieren refactorizar el código existente, puede introducir algunas capas en abstracciones para el nuevo código que agrega, lo que significa que con el tiempo puede desarrollar una mejor base de código y tal vez migrar Código antiguo como lo requiere el mantenimiento.

    
respondido por el Erik Eidt 12.12.2016 - 23:05
fuente

Lea otras preguntas en las etiquetas