Qu'est-ce que le code négatif?
Je lisais l'article Wikipedia sur Douglas McIlroy et j'ai trouvé une citation qui mentionne
"Le vrai héros de la programmation est celui qui écrit du code négatif."
Qu'est-ce que ça veut dire?
Cela signifie réduire les lignes de code, en supprimant les redondances ou en utilisant des constructions plus concises.
Voir par exemple ceci anecdote célèbre de l'original Apple Lisa developer team:
Lorsque l'équipe Lisa tentait de finaliser son logiciel en 1982, les chefs de projet ont commencé à exiger des programmeurs qu'ils soumettent des formulaires hebdomadaires indiquant le nombre de lignes de code qu'ils avaient écrites. Bill Atkinson pensait que c'était idiot. Pendant la semaine où il avait réécrit les routines de calcul de région de QuickDraw pour être six fois plus rapides et 2000 lignes plus courtes, il a mis "-2000" sur le formulaire. Après quelques semaines de plus, les gérants ont cessé de lui demander de remplir le formulaire, et il s'est volontiers conformé.
Il y a une citation de Bill Gates dans le sens de mesurer la productivité du programmeur par des lignes de code, c'est comme mesurer le progrès de la construction d'un avion en poids.
Je voudrais ajouter que la métrique LOC a encouragé l'utilisation de langages trop longs et délibéré réinventer la roue pour respecter le quota.
Quand j'étais au lycée - et oui, nous avions des ordinateurs dans les années 70, bien que nous devions les fabriquer avec des peaux d'animaux à l'aide de couteaux en pierre - l'un des professeurs de mathématiques a organisé un concours de programmation. Les règles étaient que le programme gagnant serait celui qui produirait la sortie correcte, et qui aurait le plus petit produit de lignes de temps d'exécution de code. Autrement dit, si votre programme a pris, disons 100 lignes de code et a fonctionné pendant 5 secondes, votre score était de 500. Si quelqu'un d'autre a écrit 90 lignes de code et a fonctionné pendant 6 secondes, son score était de 540. Le score le plus bas gagne, comme le golf.
Cela m'a frappé comme un système de notation brillant, récompensant à la fois la concision et la performance.
Mais l'entrée qui répondait techniquement aux critères gagnants a été disqualifiée. Le problème était d'imprimer une liste de tous les nombres premiers inférieurs à 100. L'entrée disqualifiée ressemblait à ceci (la plupart des étudiants utilisaient BASIC à l'époque):
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"
L'étudiant qui a écrit cette entrée a souligné que non seulement il était court et très efficace, mais l'algorithme devrait être évident pour quiconque ayant une connaissance même minimale de la programmation, ce qui rend le programme hautement maintenable.
C'est ironique. Si cela vous coûte N $ par ligne codée moyenne, le codage des "lignes négatives" est certainement un gagnant.
Cela signifie, comme conseil pratique, que le petit code qui accomplit le travail est bien meilleur que le gros code qui fait la même chose, toutes choses étant égales par ailleurs.
Écrire le même programme dans moins de code est un objectif pour tout le monde.
Si un programme a pris 200 LOC pour coder et que je l'écris en 150, j'ai écrit -50 LOC. J'ai donc écrit du code négatif.
La réponse de Thilo est probablement la plus précise historiquement, mais la métaphore du "code négatif" peut également inclure les performances et l'utilisation de la mémoire - récompensant les efforts pour différer l'exécution ou l'allocation de quelque chose jusqu'à ce qu'il soit réellement nécessaire.
Cette mentalité de "procrastination payante" a produit des axiomes ironiques tels que "ne rien faire est toujours plus rapide que de faire quelque chose", "le code le plus rapide est le code qui ne s'exécute jamais" et "si vous pouvez le retarder suffisamment longtemps, vous n'aurez peut-être jamais à le faire "(se référant au report d'opérations coûteuses jusqu'à ce qu'elles soient réellement nécessaires)
Une technique pour réaliser un code négatif consiste à remettre en question les hypothèses et définitions initiales du problème. Si vous pouvez redéfinir le problème/domaine d'entrée de telle sorte que le "problème persistant n ° 3" soit catégoriquement impossible, alors vous n'avez pas à passer du temps ou du code à traiter le problème persistant n ° 3. Vous avez éliminé le code en optimisant la conception.