¿Cuáles son los hábitos de codificación más desconsiderados que has visto?
La codificación es una búsqueda creativa. Cometer errores está bien: elige sus herramientas, idiomas e idiomas, que pueden ser más o menos adecuados para abordar el problema. Tal vez un error se desliza dentro; Tal vez su algoritmo fue un ajuste incorrecto para el área problemática. Eso pasa. Así es la vida.
Pero cuando se trata de una codificación desconsiderada , ya no estamos hablando de errores honestos. Según mi definición del término, para ser realmente desconsiderado, el código en cuestión debe ser peor que no tener ningún código.
Entonces, ¿qué hace que el código sea desconsiderado?
- ¿Cuáles son algunos buenos hábitos a seguir?
- ¿Hay hábitos que pueden disminuir la inteligencia? Si existen, ¿qué son?
- ¿Cuáles son los 10 hábitos más dañinos para el cerebro?
- ¿Cuáles son los hábitos alimenticios de los extraterrestres?
- Para alguien que tiene dificultades para dejar los viejos hábitos, ¿cómo traduzco la nueva información que he aprendido en la práctica?
1. Actitud abusiva hacia los demás.
Algunos codificadores son activamente maliciosos. Por ejemplo, en una base de código en la que he trabajado, un programador había dejado algo como esto:
BOOL CMasonryAnalysis :: Validar (int x)
{
DWORD tp;
tp = (DWORD) x; // ¡Jesús maldito crist Hanno, un DWORD SIEMPRE es del tamaño de un entero! 1! Has estado programando por 12 años y ni siquiera lo sabes.
Se podría decir que los sentimientos no importan siempre que el código sea correcto. Estoy en desacuerdo. La cosa es que la lucha importa . El código y los comentarios le dirán, como programador, cómo funciona el proyecto, dónde está sólido y bien escrito, y dónde están los escollos. También te dirán cuando las cosas están muy mal.
La pieza de código anterior nos dice que a) los programadores que trabajaron en esto se despreciaban mutuamente, b) al menos uno de ellos era un fanático más interesado en validar su propio ego que en cambiar realmente el código a algo viable, yc) que Nosotros (ya que la persona que comenta demuestra una ignorancia de los tipos elementales) podemos esperar que surjan errores extraños si intentamos trasladar esto a otra plataforma.
Ese comentario no mejoró la comprensión. No fue de ayuda. Simplemente nos dijo que no podemos confiar en el código o las intenciones de los programadores. Pasaremos tiempo buscando errores donde no existan. Es un comentario dañino.
La programación necesita confianza. Los lectores de su código deben estar seguros de que hicieron todo lo posible para que funcione. Para ser de confianza, hay que mostrar respeto. Por lo tanto, el código fuente nunca debe ser personal, incitante o irrespetuoso hacia los compañeros de trabajo, y cualquier comentario hecho en críticas debe ser medido y constructivo .
De particular interés, una vez encontré una serie de comentarios incoherentes sobre el “FUCKING WINDOWS PIECE OF SHIT PLATTFORM”, que por supuesto no dio ninguna aclaración real. Pero me puso nervioso, porque ahora sabía que alguien estúpido y demasiado confiado había hecho cosas desconocidas al código.
2. “Solo necesita compilar, eso es todo!”
En un empleador anterior, teníamos una biblioteca en desarrollo que olía bastante fuerte a rutinas pegadas a copias. Informé al programador culpable sobre cómo hacer las cosas de manera diferente, demostrando cómo el código podría ser mucho más compacto y mucho más expresivo. Él sonrió, asintió e ignoró completamente el consejo.
Obviamente está bien cometer errores. Cuando un programador emplea con frecuencia un mal lenguaje, ese programador debe ser informado. Si, después de esta charla, el programador continúa utilizando el mismo lenguaje como si nada hubiera pasado, entonces eso cruza la línea y se vuelve desconsiderado. Hacer caso omiso de las normas o las preocupaciones de los compañeros de trabajo es mucho peor que solo una programación mediocre: les muestra que no los respalda.
Cuando alguien molesta persistentemente el carrito de manzana, eso causa problemas. No tiene que ser obvio; Incluso las pequeñas cosas importan. Cuando cada miembro del equipo trata de seguir su propia mente con respecto a la sangría, el estilo de la abrazadera, la elección de las bibliotecas, etc., obtiene resentimiento y fricción. Eso es malo.
Para ser un buen programador, revisa tu ego en la puerta. La confianza es buena y buena, pero un buen programador toma consejos.
3. “¡Mírame, soy más listo que tú!”
Cada problema tiene múltiples soluciones: algunas simples y elegantes, otras elaboradas. Algunos programadores están interesados en demostrar sus funciones grandes, um, de miembros, y prefieren la complejidad, a veces con creces.
Cuando un codificador comete este pecado, es inmediatamente perceptible.
El resultado rara vez falta para la ambición. Verá soluciones que son difíciles de seguir, con el uso liberal de todo tipo de características de lenguaje oscuro. Experimentará la alegría de los operadores ternarios apilados, desplazados de bits, punteros a punteros a punteros, punteros a funciones, lambdas, sobrecargas de operadores … cualquier cosa que demuestre cuántos trucos puede jugar el programador en el lenguaje. Pasarás tus noches estudiando minuciosamente los diagramas de flujo hechos por ti mismo, intentando en vano encontrar sentido en un lío de lógica intencionalmente confusa.
Una vez más, el egoísmo infundado es el culpable. En este caso, no es un caso de comportamiento abusivo o ignorar las mejores prácticas: no, en este caso, se trata de presumir. La cosa es que hacer una solución es más inteligente de lo que tiene que ser, es estúpido . En lugar de resolver un problema de manera eficiente, un programador desconsiderado es todo acerca de sí mismo y de lo inteligente que se cree ser. Una solución abordada de esta manera es casi siempre un desorden demasiado inflado e innecesariamente complejo que se aferra al proyecto como un tumor.
Si hay algo peor que un programador que reinventa la rueda, es verlo poner luces de neón y luces de bengala en él. No contribuye al producto y, en su lugar, estaría mucho mejor utilizando soluciones simples y probadas.
Para terminar, no es por falta de habilidad que viene el código desconsiderado. Viene del ego y la falta de voluntad para escuchar.
Creo en la programación como una actividad social y creativa, y por lo tanto, valoro mucho la consideración y el respeto mutuo. Un famoso escritor de CS, Edsger W. Dijkstra, dijo esto:
Haremos un trabajo de programación mucho mejor, siempre que abordemos la tarea con una apreciación total de su tremenda dificultad, siempre que nos apeguemos a lenguajes de programación modestos y elegantes, siempre que respetemos las limitaciones intrínsecas de la mente humana y nos acerquemos a la tarea Como programadores muy humildes.
Tenía un punto, creo.