¿Qué es el código negativo?

Respuestas:

500

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.

Thilo
fuente
257
La perfección se logra, no cuando no hay nada más que agregar, sino cuando no hay nada más que tomar - Antoine de Saint-Exupéry
systemmpuntoout
77
¿Es #LOC una buena medida de la calidad del código? Podría 'Minificar' cualquier código C o C ++ y reducir significativamente el conteo de líneas, pero sería una pesadilla mantenerlo.
JBRWilkinson
8
@systempuntout - y luego estaba Einsten's "(Una teoría científica) debería ser lo más simple posible, pero no más simple"
Jonathan Day
32
Nada funciona más rápido, o es más confiable, o requiere menos mantenimiento, que el código que no está allí. "En caso de duda, ¡dilo!"
TMN
44
@JBRWilkinson: Diría que hay un "punto óptimo" con respecto a la brevedad del código. En general, más corto es mejor, pero llega un momento en que el código puede volverse demasiado breve y no ser fácil de descifrar a otro programador.
GordonM
131

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.

Kyralessa
fuente
30
Sí, ese es el problema con cualquier tipo de métrica. Tan pronto como los use para juzgar el desempeño de las personas, comenzarán a jugar los números.
55
¿Alguien ha usado alguna vez LOC como medida de rendimiento? Solo lo he visto usado para cosas como "¿de qué error de proyecto estamos hablando aquí?"
Michael Borgwardt
55
@Michael: sí. Por desgracia sí.
Michael Petrotta
44
¿estamos hablando del mismo Bill G. que tiene una compañía que por esa metáfora produce 10000 aviones GTON? :)
Daniel Mošmondor
37
¡Un programador que escribió el código para las computadoras a bordo del transbordador espacial me dijo que tenía que tener en cuenta el peso del software! El software era real (se pagó dinero por él); estaba en el transbordador; el peso de todo lo cargado en el transbordador debe tenerse en cuenta. Primer ejemplo de medición de la productividad del programador por peso de código. (Cero no estaba permitido, por lo que especificó 0.00001 gramos y todo fue satisfactorio.)
Mark Lutton
118

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.

Arrendajo
fuente
10
Más pruebas de que contar líneas de código es una métrica muy jugable :-)
44
¡Ese programa BÁSICO es brillante! Es bastante molesto que el maestro descalifique el programa. Después de todo, las tablas de búsqueda (con las cuales el programa es algo similar) definitivamente se pueden encontrar en la programación del mundo real.
Noctis Skytower el
66
Un maestro sabio puede haber aceptado este programa BÁSICO y utilizarlo para resaltar la importancia de obtener un SRS correcto. Me recuerda a un entrenador de béisbol que se sintió tan frustrado con su equipo que, para mostrarles cómo jugar, tomó el bate, recibió tres strikes seguidos y no se quedó atrás, le gritó a su equipo "¡Mira! Así es como bas ***** están jugando. ¡Ahora toma el bate y juega correctamente! ". También me recuerda a la persona que escribió "la creación vio al creador y se sonrojó" y ganó el concurso de ensayos sobre "vino".
Nav
3
@Nav: Me recuerda una historia similar que comienza de la misma manera. Entonces el entrenador lanza una pelota al aire, se balancea y falla. Lo lanza al aire otra vez, oscila y falla. Lo lanza al aire por tercera vez, se balancea y falla. Luego le dice al equipo: "¡Mira, así es como deberías lanzar!" (No tengo idea de qué podría tener que ver esta historia con el desarrollo de software).
Jay
13
Estaría bastante molesto si fuera descalificado por esto. Un problema determinista merece una solución determinista, ¿verdad? Cuando escribo una aplicación 'Hello World', no la codifico para verificar si estoy deletreando 'Hello' correctamente.
Kirk Broadhurst
34

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.

Ira Baxter
fuente
2
Veo de dónde vienes, pero el código conciso y fácil de entender de huella pequeña rara vez se logra de una sola vez. Por lo general, lo escribe para que funcione (muchas líneas), optimice la velocidad (un poco menos de línea) y optimice el mantenimiento / legibilidad (aún menos líneas). El costo real con el largo retorno de la inversión es el segundo y tercer paso, por lo que a menudo se omiten por completo. Es como "hay barato, rápido y bueno: puedes elegir dos".
2
En realidad, IME, la optimización para el mantenimiento / la lectura en realidad puede aumentar el LOC, ya que reescribir el código para hacerlo más autodocumentado tiende a hacerlo también más detallado.
1
@Visage: "... todas las demás cosas son iguales".
Ira Baxter
el punto es, creo, que todas las demás cosas no pueden ser iguales entre código conciso y código detallado.
Tomás Narros
La razón por la que la línea de código promedio cuesta $ N es porque primero pasa su tiempo escribiendo 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.
27

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.

LucaB
fuente
3
Además, escribir menos LOC significa que puede cometer menos errores y detectarlos fácilmente-
LucaB
3
No es cierto para Haskell y otros idiomas que se pueden comprimir a ruido aleatorio. :)
Macke
1
Claro, mi punto no era "comprimir código", sino escribir algoritmos eficientes que hagan menos en menos LOC :) +1 para tu comentario.
LucaB
9

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.

dthorpe
fuente