Quel est le code négatif?

Réponses:

500

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é.

Thilo
la source
257
La perfection est atteinte, non pas lorsqu'il n'y a plus rien à ajouter, mais lorsqu'il ne reste plus rien à prendre - Antoine de Saint-Exupéry
systempuntoout
7
#LOC est-il une bonne mesure de la qualité du code? Je pouvais "minifier" n'importe quel code C ou C ++ et réduire considérablement le nombre de lignes, mais ce serait un cauchemar à maintenir.
JBRWilkinson le
8
@systempuntout - et puis il y avait eu Einsten "(Une théorie scientifique) devrait être aussi simple que possible, mais pas plus simple"
Jonathan Day le
32
Rien ne va plus vite, n'est plus fiable, ou nécessite moins de maintenance que le code qui n'y est pas. "En cas de doute, détruisez-vous!"
TMN
4
@ JBRWilkinson: Je dirais qu'il existe un "point favorable" concernant la brièveté du code. Généralement, mieux c'est, plus court est, mais il arrive un moment où le code peut devenir trop concis et difficile à déchiffrer pour un autre programmeur.
GordonM
131

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.

Kyralessa
la source
30
Oui, c'est le problème avec n'importe quel type de métrique. Dès que vous les utiliserez pour juger de la performance des gens, ils commenceront à jouer les chiffres.
5
Quelqu'un a-t-il déjà utilisé le LOC comme métrique de performance? Je ne l'ai vu utilisé que pour des choses comme "quel bogue d'un projet parlons-nous ici?"
Michael Borgwardt le
5
@ Michael: oui. Malheureusement oui.
Michael Petrotta
4
parle-t-on du même Bill G. qui a une entreprise qui, selon cette métaphore, produit 10000 jets GTON? :)
Daniel Mošmondor le
37
Un programmeur qui a écrit le code pour les ordinateurs de bord de la navette spatiale m'a dit qu'il devait rendre compte du poids du logiciel! Le logiciel était réel (l’argent était payé pour cela); c'était sur la navette; le poids de tout ce qui est chargé dans la navette doit être pris en compte. Premier exemple de mesure de la productivité du programmeur en poids de code. (Zero n'était pas autorisé, il a donc spécifié 0,00001 gramme et tout était satisfaisant.)
Mark Lutton
118

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.

Geai
la source
10
Encore plus de preuves que compter les lignes de code est une métrique très jouable :-)
44
Ce programme BASIC est génial! Il est plutôt contrariant que l’enseignant ait disqualifié le programme. Après tout, les tables de recherche (auxquelles le programme ressemble un peu) se retrouvent certainement dans la programmation en situation réelle.
Noctis Skytower
6
Un enseignant avisé peut avoir accepté ce programme BASIC et l’avoir utilisé pour souligner l’importance d’obtenir un SRS correct. Cela me rappelle un entraîneur de baseball qui était tellement frustré par son équipe que pour leur montrer comment jouer, il a pris le bâton, obtenu trois frappes à la suite et pour ne pas être en reste, il a crié à son équipe ***** joue. Maintenant, prends la batte et joue correctement! ". Cela me rappelle aussi la personne qui a écrit "La création a vu le créateur et rougir" et qui a remporté le concours de rédaction sur "Le vin".
Nav
3
@Nav: Cela me rappelle une histoire similaire qui commence de la même manière. Ensuite, l'entraîneur lance une balle en l'air, balance et manque. Il le jette à nouveau dans les airs, sautille et manque. Il le jette dans les airs une troisième fois, saute et manque. Puis il dit à l’équipe: "Tu vois, C’est comme ça que tu devrais lancer!" (Je ne sais pas du tout ce que cette histoire pourrait avoir à voir avec le développement de logiciels.)
Jay
13
Je serais très contrarié si j'étais disqualifié pour cela. Un problème déterministe mérite une solution déterministe, non? Lorsque j'écris une application "Hello World", je ne la code pas pour vérifier si j'orthographie correctement "Hello".
Kirk Broadhurst
34

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.

Ira Baxter
la source
2
Je vois d'où vous venez, mais un code concis, facile à comprendre et à faible encombrement est rarement réalisé en une fois. Il est généralement écrit pour qu'il fonctionne (plusieurs lignes), optimisé pour la vitesse (un peu moins de lignes) et optimisé pour la maintenance / la lisibilité (moins de lignes). Le coût réel du long retour sur investissement est la deuxième et la troisième étape. Ils sont donc souvent ignorés. C'est comme "il est bon marché, rapide et bon - vous devez choisir deux".
2
En fait, l'optimisation de la maintenance / de la lisibilité par IME peut en réalité augmenter le niveau de possession , car la réécriture du code pour le rendre plus auto-documenté tend également à le rendre plus détaillé.
1
@Visage: "... toutes choses égales par ailleurs".
Ira Baxter
Je pense que le fait est que toutes les autres choses ne peuvent pas être égales entre un code concis et un code prolixe.
Tomas Narros
La raison pour laquelle la ligne moyenne de code coûte N $, c'est parce que vous passez d'abord votre temps à écrire des 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.
27

É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.

LucaB
la source
3
En outre, écrire moins de LOC signifie que vous pouvez faire moins d'erreurs et les repérer
facilement-
3
Ce n'est pas le cas pour Haskell et d'autres langages pouvant être compressés en bruit aléatoire. :)
Macke
1
Bien sûr, mon propos n’était pas de "compresser le code", mais d’écrire des algorithmes efficaces qui réduisent les coûts en moins de LOC :) +1 pour votre commentaire.
LucaB
9

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.

dthorpe
la source