Je lisais l'article de Wikipedia sur Douglas McIlroy et trouvais une citation qui mentionne
"Le véritable héros de la programmation est celui qui écrit le code négatif."
Qu'est-ce que ça veut dire?
Réponses:
Cela signifie réduire les lignes de code, en supprimant les redondances ou en utilisant des constructions plus concises.
Voir par exemple cette célèbre anecdote de l’équipe de développeurs d’Apple Lisa:
Lorsque l'équipe de Lisa a insisté pour finaliser son logiciel en 1982, les responsables de projet ont commencé à demander aux programmeurs de soumettre des formulaires hebdomadaires indiquant le nombre de lignes de code qu'ils avaient écrites. Bill Atkinson a pensé que c'était idiot. Pour la semaine au cours de laquelle il avait réécrit les routines de calcul de région de QuickDraw pour être six fois plus rapide et 2000 lignes plus courtes, il a mis "-2000" sur le formulaire. Après quelques semaines supplémentaires, les responsables ont cessé de lui demander de remplir le formulaire, et il s'est volontiers conformé.
Une citation de Bill Gates selon laquelle mesurer la productivité des programmeurs par lignes de code équivaut à mesurer le progrès de la construction d’un aéronef en termes de poids.
J'aimerais ajouter que la métrique LOC a encouragé l'utilisation de langages trop longs et a délibérément réinventé la roue pour respecter les quotas.
Quand j'étais au lycée - et oui, nous avions des ordinateurs dans les années 70, bien que nous devions les fabriquer en peau de bête à 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 produirait le plus petit produit de lignes de temps code. Autrement dit, si votre programme prenait, par exemple, 100 lignes de code et durait 5 secondes, votre score était de 500. Si quelqu'un d'autre écrivait 90 lignes de code et courait pendant 6 secondes, son score était de 540. Un score bas gagne, comme le golf.
Cela m'a semblé être un système de pointage brillant, récompensant à la fois la concision et la performance.
Mais l’entrée répondant techniquement aux critères de gain a été disqualifiée. Le problème consistait à 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 que l'algorithme devrait être évident pour quiconque possède 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, alors le codage des "lignes négatives" est sûrement un gagnant.
Cela signifie, en tant que conseil pratique, qu'un petit code qui accomplit le travail est bien meilleur qu'un gros code qui fait la même chose, toutes choses étant égales par ailleurs.
Xlignes. Ensuite, sur plusieurs itérations, réduisant le produit final par Ylignes. Ainsi, les (X-Y)lignes restantes semblent être très coûteuses car le carnage de la refactorisation a coupé tous les obstacles.
Écrire le même programme en moins de code est un objectif pour tout le monde.
Si un programme nécessitait 200 LOC au code et que je l'écrivais en 150, j'écrivais -50 LOC. J'ai donc écrit un code négatif.
La réponse de Thilo est probablement la plus exacte historiquement, mais la métaphore de "code négatif" peut également inclure les performances et l'utilisation de la mémoire - récompensant les efforts déployés pour différer l'exécution ou l'affectation de quelque chose jusqu'à ce que ce soit réellement nécessaire.
Cette mentalité de "procrastination paie" a produit de tels axiomes irrésistibles 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, il se peut que vous n'ayez jamais à le faire "(faisant référence au report d'opérations coûteuses jusqu'à ce que cela soit réellement requis)
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 sorte que le "problème persistant" soit catégoriquement impossible, vous ne perdez pas de temps ni de code pour traiter le problème persistant # 3. Vous avez éliminé le code en optimisant la conception.