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 código negativo".
Qué significa eso?
Respuestas:
Significa reducir líneas de código, eliminando redundancias o utilizando construcciones más concisas.
Vea, por ejemplo, esta famosa anécdota del equipo original de desarrolladores de Apple Lisa:
Cuando el equipo de Lisa estaba presionando para finalizar su software en 1982, los gerentes de proyecto comenzaron a exigir a los programadores que 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. Para la semana en la que había reescrito las rutinas de cálculo de 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 semanas más, los gerentes dejaron de pedirle que completara el formulario, y él aceptó con gusto.
Hay una cita de Bill Gates en el sentido de que medir la productividad del programador por líneas de código es como medir el progreso de la construcción de aviones por peso.
Quisiera agregar que la métrica LOC ha alentado el uso de idiomas excesivamente largos y reinventa deliberadamente 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 maestros de matemáticas organizó un concurso de programación. Las reglas eran que el programa ganador sería el que produjera la salida correcta, y que tuviera el producto más pequeño de las líneas de código de tiempo de ejecución. Es decir, si su programa tomó, digamos 100 líneas de código y ejecutó durante 5 segundos, su puntaje fue de 500. Si alguien más escribió 90 líneas de código y ejecutó 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 la concisión y el rendimiento.
Pero la entrada que técnicamente cumplía con los criterios ganadores fue descalificada. El problema era imprimir una lista de todos los números primos menores que 100. La entrada descalificada fue algo así (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 estudiante que escribió esa entrada señaló que no solo era breve y muy eficiente, sino que el algoritmo debería ser obvio para cualquiera con un conocimiento mínimo de programación, haciendo que el programa sea altamente mantenible.
Es irónico. Si le cuesta $ N por línea codificada promedio, entonces codificar "líneas negativas" seguramente es 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.
Xlíneas. Luego, durante varias iteraciones, reduciendo el producto final por Ylíneas. Entonces, las (X-Y)líneas restantes parecen ser muy costosas porque la carnicería de la refactorización ha cortado toda la ruina.
Escribir el mismo programa en menos código es un objetivo para todos.
Si un programa tomó 200 LOC para codificar, y lo escribí en 150, escribí -50 LOC. Entonces escribí un 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 el rendimiento y el uso de la memoria, recompensando los esfuerzos para diferir la ejecución o la asignación de algo hasta que sea realmente necesario.
Esta mentalidad de "la dilació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 al aplazamiento 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 problema / dominio de entrada de modo que el "problema fijo # 3" sea categóricamente imposible, entonces no tiene que perder tiempo o código para tratar el problema fijo # 3. Has eliminado el código optimizando el diseño.