Il y a trois choses ici:
Des principes
C'est un côté de la médaille. Dans une certaine mesure, j'estime qu'il est bon d'insister sur la correction des bogues (ou des mauvaises implémentations, même si elles "fonctionnent"), même si personne ne s'en aperçoit.
Regardez-le comme suit: dans votre exemple, le vrai problème n'est pas nécessairement le bogue, mais le fait qu'un programmeur pense que c'est une bonne idée d'implémenter la boucle de cette manière. Dès le premier instant, il était évident que ce n'était pas une bonne solution. Il y a maintenant deux possibilités:
Le programmeur n'a tout simplement pas remarqué. Eh bien ... un programmeur devrait développer une intuition sur le fonctionnement de son code. Ce n'est pas comme si la récursivité est un concept très difficile. En corrigeant le bogue (et en transpirant avec tout le travail supplémentaire), il apprend peut-être quelque chose et s'en souvient, ne serait-ce que pour éviter le travail supplémentaire à venir. Si la raison était qu'il tout simplement pas eu assez de temps, la direction peut apprendre que les programmeurs ne ont besoin de plus de temps pour créer un code de meilleure qualité.
Le programmeur l'a remarqué, mais l'a jugé "pas un problème". Si cela est laissé de côté, alors une culture de laisser-faire est développée qui finira par conduire à des bugs là où ça fait vraiment mal. Dans ce cas particulier, peu importe. Mais que se passe-t-il si le programmeur développe une application bancaire la prochaine fois et décide qu’une certaine constellation ne se produira jamais? Alors ça le fait. Mauvais moments.
Pragmatisme
Ceci est l'autre côté. Bien entendu , dans ce cas particulier, le problème ne serait probablement pas résolu. Mais attention, il y a du pragmatisme, puis du pragmatisme. Un bon pragmatisme suppose que vous trouviez une solution rapide, mais néanmoins solide et bien fondée, à un problème. En d'autres termes, vous évitez de trop dessiner, mais les éléments que vous implémentez sont toujours bien pensés. Le mauvais pragmatisme, c’est quand vous venez de pirater quelque chose qui fonctionne "exactement" et qui va casser à la première occasion.
Échouer vite, échouer dur
En cas de doute, échouez vite et fort.
Cela signifie, entre autres, que votre code remarque la condition d'erreur, pas l'environnement.
Dans cet exemple, le moins que vous puissiez faire est de faire en sorte que l'erreur d'exécution dure ("profondeur de la pile dépassée" ou quelque chose du genre) ne se produise pas, en la remplaçant par une exception matérielle de votre cru. Vous pouvez, par exemple, avoir un compteur global et décider de manière arbitraire que vous renflouez après 1 000 vidéos (ou un nombre suffisamment élevé pour ne jamais apparaître en utilisation normale et suffisamment bas pour fonctionner dans la plupart des navigateurs). Donnez ensuite à cette exception (qui peut être une exception générique, par exemple RuntimeException
en Java, ou une simple chaîne en JavaScript ou Ruby) un message explicite. Vous n'êtes pas obligé d'aller jusqu'à créer un nouveau type d'exceptions ou quoi que vous fassiez dans votre langage de programmation.
De cette façon, vous avez
- ... documenté le problème à l'intérieur du code.
- ... En fait un problème déterministe. Vous savez que votre exception se produira. Vous n'êtes pas à la merci des modifications de la technologie du navigateur sous-jacent (pensez non seulement au navigateur PC, mais aussi aux smartphones, tablettes ou technologies futures).
- ... il est facile de le réparer quand vous avez finalement besoin de le réparer. Votre message indique la source du problème, vous obtiendrez un retour en arrière significatif et tout le reste.
- ... toujours pas de perte de temps à gérer les erreurs "réelles" (rappelez-vous, vous ne vous attendez jamais à ce que l'erreur se produise).
Ma convention est de préfixer de tels messages d'erreur avec le mot "Paranoia:". Ceci est un signe clair pour moi et pour tous les autres que je ne m'attends jamais à ce que cette erreur se produise. Je peux clairement les séparer des "vraies" exceptions. Si j'en vois un comme celui-ci dans une interface graphique ou un fichier journal, je sais que j'ai un problème sérieux - je ne m'attendais pas à ce qu'il se produise, après tout. À ce stade, je passe en mode crunch (avec une bonne chance de le résoudre rapidement et assez facilement, car je sais exactement où le problème s'est produit, ce qui m'a évité beaucoup de débogage parasite).