Pourquoi « print » n'est pas une méthode, mais un crime contre le temps
\nSoyons honnêtes : chacun d'entre nous a écrit au moins une fois dans sa vie print("ici_on_ne_viendra_jamais") en espérant que cela fonctionne. Parfois, ça marchait. Mais dans les projets sérieux, cette approche transforme le code en sapin de Noël avec des guirlandes de logs. Le débogage Swift est un art, et aujourd'hui nous allons le décortiquer de A à Z. Vous apprendrez à cesser de deviner et à commencer à « débugger » professionnellement les applications iOS.
Cet article s'adresse à ceux qui écrivent en Swift, mais qui sentent que Xcode peut faire plus. Nous n'allons pas vous apprendre les bases – nous allons vous montrer comment le débogage de code Swift peut être rapide, efficace et même passionnant. C'est parti !
\n\n1. Points d'arrêt conditionnels : votre détective personnel
\nUn breakpoint ordinaire arrête l'exécution chaque fois qu'il atteint une ligne. Mais que faire si le bug ne se manifeste qu'au 1000ème appel d'une fonction ? Ou seulement quand userId == 42 ? C'est là que les points d'arrêt conditionnels en Swift viennent à la rescousse.
Cliquez avec le bouton droit sur le breakpoint → choisissez « Edit Breakpoint » → saisissez la condition.
\n\nExemple : attraper un bug dans une boucle
\nfor index in 0..<items.count {\n processItem(items[index]) // Bug quand index == 5\n}\nPlacez un breakpoint sur la ligne processItem et saisissez la condition : index == 5. Maintenant, le débogueur s'arrêtera exactement là où il le faut. Plus de touches F6 inutiles.
Blocs d'action : rendre le breakpoint plus intelligent
\nDans la même fenêtre d'édition, il y a un bouton « Add Action ». Vous pouvez :
\n- \n
- Exécuter
po variableName(print object) – affiche automatiquement la valeur de la variable. \n - Jouer un son (oui, vraiment !) – utile quand le débogage se fait en arrière-plan. \n
- Enregistrer un message dans le log – sans arrêter l'exécution. \n
Activez la case « Automatically continue after evaluating » – et vous obtiendrez un super-loggeur qui ne ralentit pas le fonctionnement de l'application.
\n\n2. LLDB : une console qui sait tout faire
\nDe nombreux développeurs ignorent la console de débogage, pensant qu'il n'y a que po et p. En réalité, LLDB (Low Level Debugger) est le couteau suisse du débogage Swift. Voici 5 commandes qui changeront votre vie :
- \n
po– affiche l'objet en appelantdescriptionoudebugDescription. Idéal pour les objets UIKit. \n p– affiche la valeur, mais sans appelerdescription. Utile pour les primitives. \n v– montre les variables dans le cadre actuel. Plus rapide que de regarder le panneau Variables. \n expression– exécute n'importe quel code Swift directement pendant la pause. Vous voulez modifier la valeur d'une variable ?expression self.title = "Nouveau titre". \n thread backtrace– affiche la pile d'appels. Si l'application a planté, c'est la première chose à faire. \n
Exemple concret : modifier l'UI à la volée
\nImaginez : vous vous êtes arrêté sur un breakpoint dans viewDidLoad. Dans la console, vous tapez :
expression self.view.backgroundColor = .red\nexpression self.view.layoutIfNeeded()\nEt voilà ! L'écran du simulateur se recolore instantanément en rouge. Vous pouvez ainsi tester des animations, des couleurs et des textes sans redémarrer.
\n\n3. View Debugging : regarder sous le capot de l'UI
\nLe bug de mise en page est un classique du genre. Bouton mal placé, label qui chevauche l'image, ou contraintes qui se comportent comme des guérilleros. View Debugging dans Xcode est la radiographie de votre interface.
\nAppuyez sur le bouton « Debug View Hierarchy » (il ressemble à trois carrés) dans le panneau inférieur. Vous verrez une scène 3D de tous les éléments UI. Vous pouvez tourner, zoomer, mettre en évidence les contraintes et voir leurs valeurs numériques.
\n\nTechnique : « Attrape la contrainte »
\nSi un élément n'est pas à sa place, sélectionnez-le dans la scène 3D et regardez la liste des contraintes. Les lignes rouges sont en conflit, les