Estaba leyendo el artículo de Wikipedia sobre Douglas McIlroy y encontré una cita que menciona
"El verdadero héroe de la programación es el que escribe un código negativo".
¿Qué significa eso?
Estaba leyendo el artículo de Wikipedia sobre Douglas McIlroy y encontré una cita que menciona
"El verdadero héroe de la programación es el que escribe un código negativo".
¿Qué significa eso?
Significa reducir líneas de código, eliminando redundancias o utilizando construcciones más concisas.
Vea, por ejemplo, esta anécdota famosa del equipo de desarrolladores original de Apple Lisa:
Cuando el equipo de Lisa estaba presionando para finalizar su software en 1982, los gerentes de proyecto comenzaron a requerir que los programadores enviaran formularios semanales que informaban sobre la cantidad de líneas de código que habían escrito. Bill Atkinson pensó que eso era una tontería. Durante la semana en la que reescribió las rutinas de cálculo de la región de QuickDraw para que fueran seis veces más rápidas y 2000 líneas más cortas, puso "-2000" en el formulario. Después de unas pocas semanas más, los gerentes dejaron de pedirle que llenara el formulario y él cumplió con gusto.
Hay una cita de Bill Gates en la línea de medir la productividad del programador por líneas de código, es como medir el progreso de la construcción de aviones por peso.
Me gustaría agregar que la métrica LOC ha alentado el uso de lenguajes demasiado largos y el reinicio deliberado de la rueda para cumplir con la cuota.
Cuando estaba en la escuela secundaria, y sí, teníamos computadoras en los años 70, aunque tuvimos que sacarlas de pieles de animales con cuchillos de piedra, uno de los profesores de matemáticas organizó un concurso de programación. Las reglas eran que el programa ganador sería el que produjera el resultado correcto y que tuviera el producto más pequeño de líneas de código en tiempo de ejecución. Es decir, si su programa tomó, digamos 100 líneas de código y duró 5 segundos, su puntaje fue de 500. Si alguien más escribió 90 líneas de código y corrió durante 6 segundos, su puntaje fue de 540. El puntaje bajo gana, como el golf.
Me pareció un sistema de puntuación brillante, que recompensaba tanto la concisión como el rendimiento.
Pero la entrada que técnicamente cumplió con los criterios ganadores fue descalificada. El problema fue imprimir una lista de todos los números primos menores de 100. La entrada descalificada fue algo como esto (la mayoría de los estudiantes usaban BASIC en ese entonces):
100 print "2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, 59, 61,"
110 print "67, 71, 73, 79, 83, 87, 89, 91, 97"
El alumno que escribió esa entrada señaló que no solo era breve y muy eficiente, sino que el algoritmo debería ser obvio para cualquier persona con un mínimo conocimiento de la programación, lo que hace que el programa sea altamente mantenible.
Es irónico. Si le cuesta $ N por línea codificada promedio, la codificación de "líneas negativas" es seguramente un ganador.
Esto significa, como consejo práctico, que el código pequeño que realiza el trabajo es mucho mejor que el código grande que hace lo mismo, todas las demás cosas son iguales.
Escribir el mismo programa en menos código es un objetivo para todos.
Si un programa tomó 200 LOC para codificar, y lo escribo en 150, escribí -50 LOC. Así que escribí código negativo.
La respuesta de Thilo es probablemente la más precisa históricamente, pero la metáfora del "código negativo" también puede incluir rendimiento y memoria. uso: recompensar los esfuerzos para diferir la ejecución o asignación de algo hasta que realmente sea necesario.
Esta mentalidad de "procrastinación paga" produjo axiomas irónicos como "No hacer nada siempre es más rápido que hacer algo", "El código más rápido es el código que nunca se ejecuta", y "Si puedes posponerlo el tiempo suficiente, es posible que nunca tenga que hacerlo "(refiriéndose a la postergación de operaciones costosas hasta que sea realmente necesario)
Una técnica para realizar un código negativo es desafiar los supuestos iniciales y las definiciones del problema. Si puede redefinir el dominio de entrada / problema de manera tal que el "problema persistente # 3" sea categóricamente imposible, entonces no tiene que perder tiempo ni código para tratar el problema # 3. Has eliminado el código optimizando el diseño.
Lea otras preguntas en las etiquetas terminology code-metrics