¿Debería uno evitar ciertas construcciones de programación (y otras) por el mantenimiento?

Question

Estoy trabajando en un proyecto no personal, por lo que es seguro decir que el programador de mantenimiento no soy yo, de lo contrario no tendría que hacer esta pregunta.

Ahora hay algunas construcciones (delegados, expresiones lambda) que me gustaría probar en mi código, no para hacer el código intencionalmente más difícil de leer, sino porque se prestan a la situación (y menos código para escribir como bien), y practicar el uso de ellos también desde que soy nuevo en el lenguaje.

Sin embargo, no estoy seguro de si el programador de mantenimiento conocerá cada construcción, ya que muchos de nosotros no venimos de aC# de fondo, y no estoy seguro si está tan entusiasmado con programar como yo o solo tratar es como un trabajo diario normal. Así que mis preguntas son:

• se debe evitar ciertas construcciones de programación para mejorar maintainabilily?

• Si la respuesta a la pregunta anterior es sí, ¿entonces está el subconjunto de construcciones que se debe evitar usar?

• ¿Es la responsabilidad del programador de mantenimiento aprender un idioma completamente?

Answer 1

Estoy en contra de mínimo común denominador de codificación. Somos profesionales, parte de lo que se debería esperar de nosotros es aprender cosas que no sabemos.

Por otro lado, también estoy en contra de la codificación de la gloria. Utilice los constructos más simples que pueden hacer el trabajo: el código de depuración es dos veces más difícil que escribirlo, ¡así que será mejor que solo escriba código la mitad de ingenioso que sea capaz de hacerlo!

Answer 2

Creo que la regla general es asegurarse de que su código sea legible con muchos comentarios, especialmente en lugares donde está haciendo algo que no es directo.

Evitar ciertas construcciones como delegados y expresiones lambda no debería ser el camino a seguir, si se utilizan de manera correcta y sensata, características de lenguaje como esas pueden reducir en gran medida la complejidad de su código y hacerlo más conciso y expresivo. Después de todo, esa es la belleza de LINQ, ¿no es así? ;-)

Creo que deberías concentrarte en hacer tu trabajo lo mejor que puedas, ya sea que los otros programadores no tengan todos los conocimientos necesarios para comprender que tu código está fuera de tu control o no. Si ese programador de mantenimiento se va, y alguien más entra, ¿entonces qué? No debe adaptar su código para adaptarlo al programador de mantenimiento, adapte su código para que se adapte al problema que tiene la tarea de resolver.

Answer 3

Creo que incluso si está escribiendo en su propio proyecto, vale la pena seguir lo más posible las expresiones comunes/estándar en cualquier idioma que esté utilizando.

Me he topado con esta trampa yo mismo - escribí un código que hizo algo "inteligente", no lo documenté lo suficiente, e introduje un error grave cuando volví a cambiar el código unos meses más tarde.

Mi regla general: utilice el "lenguaje central" tanto como sea humanamente posible, y cuando se aparte de esto, documente su enfoque a fondo. Evite explotar el azúcar sintáctico para acortar su código a menos que sea un modismo realmente estándar (por ejemplo, propiedades en C#).La legibilidad debería prevalecer sobre la velocidad de tipeo todo el tiempo.

Si está esperando que los codificadores de mantenimiento se hagan cargo de su trabajo, todo esto es doblemente cierto. Usted no puede esperar que los codificadores de mantenimiento sean competentes en múltiples paradigmas en la mayoría de las organizaciones. Por lo tanto, si, por ejemplo, comience a usar construcciones de programación lógica/funcional como lambdas en su código orientado a objetos, entonces es como escribir un capítulo en alemán en un libro en inglés. Es posible que desee que sus lectores sean entusiastas multilingües, pero lo más probable es que no lo sean.

Answer 4

Creo que especialmente las expresiones lambda hacen que el código sea más fácil de leer en todo caso. En lugar de tener múltiples for-each's con muchos condicionales, una lambda limpia casi puede leerse.

Desde mi experiencia, las cosas que hacen que el código sea difícil de leer son argumentos Func genéricos ingeniosos ... A menudo solo eliminan dos funciones fáciles de leer y las reemplazan por una genérica difícil de leer.

Por lo tanto, es más importante en mi libro tener métodos con buenos nombres que evitar ciertos constructos. Pero no te preocupes porque no los conocen, deben aprenderlos de todos modos.