Microclub
Microclub

« Conditions Yoda », « Gestion d’exception Pokémon » et autres classiques de programmation

Rolf Ziegler

(traduction de « Yoda Conditions », « Pokémon Exception Handling » and other programming classics sur dodgycoder.net/ )

Voici les meilleures réponses à une question posée sur StackOverflow.com par  John K :

Quelles sont les expressions de jargon de programmation que vous avez notées dans vos équipes ou remarquées sur Internet ?

Les Conditions Yoda

Utiliser if(constante == variable)
au lieu de if(variable == constanet),
comme dans if (4 == foo).

« Yoda » parce que c’est comme dire « si bleu est le ciel » ou « si grand est l’homme »

A l’origine les conditions Yoda ont peut-être été introduites pour éliminer les erreurs potentielles de la forme
if(count=5) (qui génère une assignation C, le test nécessitant ==). En écrivant if(5=count), l’erreur est détectée à la compilation.

La gestion d’exception Pokémon

Attrapez-les tous !

Quand vous devez juste les attraper tous:.

try
{
// do something
}
catch
{
// catch em all
}

Les accolades Egyptiennes

Le style d’accolades où l’accolade ouvrante se met à la fin de la première ligne

if (a == b) {
  printf("hello");
}

Ce style est utilisé dans le livre de Kernighan and Ritchie « Le Langage C », donc beaucoup l’appellent le « style » K&R.

Voyez la Wikipédia sur les styles d’indentation sur les styles Whitesmiths, GNU ou Pico.

Les commentaires Ninja

Aussi appelés commentaires invisibles. commentaires secrets ou « sans commentaires ».

La Convention de Nommage Schtroumpf

Quand presque toutes les classes ont le mêmes préfixe

Le typage enchaîné

(« stringly typed » en anglais, jeu de mot sur « strongly typed », typage_fort) Une implémentation qui dépend sans nécessité des chaînes de caractère alors que des alternatives plus agréables pour les programmeurs et les outils de refactoring existent. Par exemple des paramètres de méthodes acceptant des chaînes alors que des types plus appropriés devraient être utilisés. Le code trop enchaîné est habituellement difficile à comprendre et explose à l’exécution sur des erreurs qu’un compilateur aurait normalement trouvé.

Le Refucktoring

Variante du refactoring popularisé par Martin Fowler dans son livre du même nom, c’est le processus consistant à prendre un bout de code bien conçu et, par une série de petites modifications réversibles, le rendre totalement non maintenable par quiconque d’autre que vous-même.

Le Fear Driven Development

(Développement Piloté par la Peur) : lorsque la gestion de projet ajoute de la pression, par exemple en virant quelqu’un.

Types de fonctionnalités

  • La Licorne : une fonctionnalité planifiée si tôt qu’elle peut tout aussi bien être imaginaire.
  • La Barack Obama: une fonctionnalité qu’on aimerait bien ajouter au projet, mais on n’y sera probablement jamais autorisés.

Les differents types de rapports de bug

  • Le rapport complaisant : un bug soumis par un utilisateur qui croit qu’il en connait beaucoup plus sur le système que ce qu’il en sait vraiment. Rempli de détails techniques irrelevants et contenant des suggestions (toujours fausses) sur ce qu’il pense être la cause du problème et ce que l’on devrait faire pour le corriger.
  • Le rapport de junkie: un rapport si profondément incompréhensible que celui qui l’a soumis devait fumer du crack. La version la plus douce est le rapport enfumé, où l’émetteur a du en prendre une de trop…
  • Le rapport « haussement d’épaule » : un rapport de bug sans message d’erreur ni manière de le reproduire et juste une vague description du problème. Contient généralement la phrase « ça ne fonctionne pas ».
  • Le « dernier message de Fermat » : un message dans un forum ou un système de suivi de problèmes où l’auteur prétend avoir trouvé un moyen simple de contourner le bug mais ne dit jamais comment et ne revient jamais pour l’expliquer, même si d’autres se sont cassés la  tête sur le bug pendant des années.
  • Le « flottant » : dans un  système de suivi de problèmes, le ou le bug reste « flottant » en haut de la pile mais n’est jamais assigné à un développeur, peut-être parce qu’il y a un moyen de le contournerl.

Les differents types de bugs

  • Le Heisenbug : un bug qui disparaît ou change ses caractéristiques quand on essaie de l’étudier
  • Le Bugson de Higgs : un bug hypothétique dont on pense qu’il existe d’après un petit nombre d’entrées de logs éventuellement reliées et de vagues rapports de bugs anecdotiques d’utilisateurs, mais difficile si ce n’est impossible à reproduire sur une machine de dev parce que vous ne savez pas s’il est vraiment là, et si oui ce qui le cause. Pour trouver ces bugs, il faut investir dans un Large Hadron Debugger…
  • Le Hindenbug : un bug détruisant les données de manière catastrophique. Souvent c’est un humain.
  • Le contre-bug : un bug que vous montrez à la personne qui l’a causé lorsque cette personne vous montre un bug.
  • Le Bloombug : un bug qui rapporte accidentellement de l’argent.
  • Le Schrödinbug : se réfère à une fonctionnalité qui fluctue apparemment entre boguée et correcte (comme le chat de Schrödinger, à la fois vivant et mort), jusqu’à ce que quelqu’un regarde le code (ouvre la boîte) , moment dès lequel la fonctionnalité devient boguée de façon permanente.
  • Le Bug Monstre du Loch Ness Monster Bug : un bug qui ne peut pas être reproduit ou n’a été vu que par une seule personne.
  • Le Bug OVNI : un bug rapporté par des clients qui, même lorsqu’on leur montre que le bug n’existe pas, continuent à le rapporter encore et encore croyant qu’il est réel.
  • Le Mandelbug  : un bug dont les causes sont si complexes que son comportement apparaît chaotique ou même non déterministe. Nommé d’après Benoît Mandelbrot, découvreur des fractales.
  • Le bug en sac de papier brunBrown : un bug dans un logiciel public si gênant que son auteur se cache la tête dans un sac de papier brun pendant quelques temps
  • Le bug de l’apprenti sorcier : un bug dans un protocole qui, dans certaines circonstances, cause l’envoi de multiple messages dont chacun redéclanche le même bug
  • Le bug de la copine folle : un bug dont l’effet immédiat est invisible, l’application semblant à première vue fonctionner normalement et vous disant qu’elle fonctionne normalement.
  • Le bug Excalibur : celui que tous les employés de l’entreprise ont tenté de résoudre, mais aucun n’a été assez valeureux pour y arriver.
  • Le printf indispensable : lorsqu’une ligne de debug est indispensable pour que le code fonctionne. Le programme bogue si on l’enlève.

Les differents types de code

  • Le code Spaghetti : code avec trop de GOTO, d’exceptions, de  threads ou d’autres constructions de branchements non structurés. Le flux du programme ressemble à un plat de spaghetti emmêlés.

  • Le code Spaghetti avec boules de viande : Une tentative de code orienté objet, mais où le résultat final reste dépendant de code procédural emberlificoté (spaghetti.
  • Le code Baklava : code avec trop de couches. Appelé aussi code Lasagne.
  • Le code Ravioli : code orienté objet constitué d’un grand nombre de petits copmposants mal liés.
  • Le code Saucisse : Une fois que vous avez examiné ce code en détail pour voir de quoi il est fait, vous ne voulez plus jamais l’utiliser.
  • Le code Jenga : l’ensemble s’effondre dès que vous y touchez.
  • Le code Hydre : code qui ne peut être corrigé. Chaque correction provoque deux nouveaux bugs. Il faut le réécrire.
  • Code sparadrap : tout code transformé en commentaire mais toujours inclus dans la version courante.
  • Le code putain : code problématique qui fait que l’application se couche souvent.
  • Le rouge à lèvres de cochon : code comportant beaucoup de vieux code historique ou spaghetti caché derrière des classes enveloppes (wrappers). Il apparait aux nouveaux développeurs comme bien conçu, élégant, orienté objet. Ce n’est que lorsqu’ils travaillent dessus qu’ils réalisent à quel point il est moche.
  • Le code hypothécaire : code volontairement si compliqué que vous seul pouvez le maintenir, forçant votre employeur à vous garder, ce qui vous permet de payer votre hypothèque.
  • Le code Ghetto : portion de code particulièrement inélégante et suboptimale, mais qui cependant satisfait les spécifications.
  • le code Couteau Suisse : code qui souffre de spécifications rampantes (feature creep) : il fait plein de choses, mais ne fait rien bien.
  • Code NP rusé : un algorithme dont la complexité est trop dure à comprendre par le simple mortel.
  • Code NP hilarant : un algorithme dont la complexité est une plaisanterie, littéralement comme le BogoSort par exemple, ou métaphoriquement,
  • NP Hilarious Code – An algorithm whose complexity is « a joke », literally (as in BogoSort) or metaphorically.
  • Le code « coupé-gaspillé » (Cut-and-waste) : lorsque quelqu’un a coupé/collé du code touvé en ligne (souvent depuis un blog) dans un code de production. le résultat est souvent beaucoup de temps perdu à traquer un bug obscur d’un code qui avait sans doute du sens dans le contexte d’origine, mais pas dans notre application. Aussi appelé « Blog Driven Development » (BDD).
  • Le code « vélo du quartier » : un module ou bout de code que tous les programmeurs de la boîte ont touché.
  • Le code traces de gomme : code qui a été écrit puis refactoré de nombreuses fois, laissant du vieux code dans son sillage. Comme lorsqu’on efface du papier plusieurs fois, on ne voit plus les traces du crayon mais la grosse tache de la gomme.
  • Le code « objetfusqué » : code orient objet qui a été abstrait à tellement de niveaux que plus personne ne peut le comprendre.
  • Code Bernacle: tout bout de code (souvent une méthode statique) qui a été ajouté à une classe à laquelle il n’appartient pas vraiment, en raison de l’absence d’un autre endroit logique où le mettre.
  • Code en pilotage automatique : code écrit par un programmeur qui était en « pilotage automatique » ou ne réfléchissait pas vraiment à ce qu’il faisait.
  • Protoduction : un prototype qui finit en production

voir aussi : le « Jargon File »

6 réflexions sur “« Conditions Yoda », « Gestion d’exception Pokémon » et autres classiques de programmation”

Laisser un commentaire

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.