print() ou débogueur
colas_
Membre
Buster Theo
Tu dois arrêter de debugger avec de print (sauf exception).
Tu gagnerais beaucoup de temps !
Tu dois arrêter de debugger avec de print (sauf exception).
Tu gagnerais beaucoup de temps !
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Oui je sais, mais ça me semble tellement pratique.
J'ai déjà essayé avec les breaks points, mais je trouve cela laborieux.
Avec les prints, je peux tester tout un tas de choses sur plusieurs fichiers, en même temps.
Et perso, je trouve cela hyper rapide...
Mais il faudrait quand même que je pousse un peu plus là -dessus.
Si tout le monde le dit, c'est qu'il doit y avoir une bonne raison.
En tout cas merci...
Bon ok, je m'incline et repars à l'école.
Je consulte actuellement cette page, le zoom sur l'image est excellente.
Je viens de comprendre (un peu neuneu le mec) que l'on pouvait poser les breakpoints après avoir lancer l'app. Je croyais qu'il fallait décider avant de la lancer, ce qui me posait un problème, car on a souvent besoin de tester plusieurs trucs en même temps...
Bref, merci pour ce forcing. Tu m'as convaincu. Respect.
Maintenant, il faut que je m'entraine, pas évident, y'en a partout..., mais c'est vrai, ça a l'air cool.
Il faut vraiment que tu insistes sur le debugguer
Surtout que tu peux en interactif, une fois que ton programme est en pause, regarder les valeurs de chaque variable : tu fais po myVar
Tu peux aussi explorer les vues et sous-vues, qui se superposent, etc en live.
Fais-nous confiance : c'est du temps et un Effort pour y passer, mais rentabiliser en une journée
Personnellement, je mélange les deux.
Car avec des calls async, ça fout parfois un peu le bordel (time outs pénibles notamment) si on reste trop longtemps breakpointé. D'ailleurs tant qu'on a pas compris l'asynchronisme, cela peut créer des faux positifs parfois.
Et les prints on l'avantage d'afficher un "historique".
On peut mettre des Breakpoints avec des logs détaillés et l'éditer pour faire en sorte que l'exécution du programme continue automatiquement. ça permet donc d'éviter les problématiques des appels asynchrones. De plus les breakpoints ont une flexibilité bien plus grande que les simples print puisqu'ils permettent de poser des conditions à l'arrêt, de déterminer au bout de combien de passage il peut se déclencher etc.
Pour compléter la réponse de Magiic: cliquez-droit sur une point d'arrêt: on peut l'éditer.
On peut par exemple faire un "print" d'une variable puis poursuivre l'exécution.
On peut aussi émettre un son. Par exemple, si on a une fuite, on peut le placer dans -dealloc ou deinit(), et vérifier que ça bippe bien quand le View Controller disparait.
Un avantage majeur des points d'arrêt sur les prints est qu'ils ne nécessitent pas de rebuilder le projet. Par ailleurs, le problème des prints est qu'il faut savoir à l'avance ce qu'on veut regarder. Tout ça représente une grosse perte de temps.
Merci à vous tous pour ce débat très intéressant.
Peut-être devrions-nous déplacer une bonne partie de ce post dans un nouveau post intitulé "Debug or Print"
Bref, voici le point de vue du néophyte.
Je suis d'accord, et j'adore :
Et oui :
Alors ça, ça a l'air super, mais je n'en suis pas là , mais je le note :
ça aussi, j'adore :
Après plusieurs heures de jeu avec le debugger, je dirais comme vous le dites, on a besoin des deux debug&print.
Le debugger semble épatant lorsqu'on le maitrise à fond, comme la maitrise des trucs dont vous parlez dans ce post.
En attendant, je m'en sert un peu, mais franchement, avec mes prints, pour l'instant je vais mille fois plus vite, et j'ai un pur suivi d'où j'en suis et comment les choses se passent.
Donc j'utilise toujours les prints, et je ne suis pas prêt d'arrêter, par contre je joue en même temps avec le debugger dès qu'un truc m'interpelle. Super, et encore merci pour les remarques.
Par contre c'est chaud dès que je rentre dans une fonction, des affichages relatifs (popups, anime, etc) restent bloquées. Il me manque certainement de la pratique.
Rassure-toi, ça m'arrive régulièrement de me faire surprendre. " Pourquoi il bouge plus lui ? Ah, oui, il est arrêté sur le point d'arrêt ! "
Puisque le sujet a été recentré :
Je garde mes NSLog() car notre breakpoints list (dans xcuserdata) est propre à chaque développeur et qu'on ne la commit pas.
Je peux faire une recherche rapide sur ce que j'ai loggué dans mon code (pas trouvé comment inclure dans la recherche des spécifités de logs des breakpoints) afin de retrouver plus rapidement le bout de code.
Et j'ai la date courante aussi dans un NSLog(), ce qui parfois peut-être intéressant.
Par contre, cela demande un rebuild/rerun, donc je manie les breakpoints aussi.
Ah bravo pour le nouveau post - Merci pour tous les barmans
Par contre, Larme, je ne comprend strictement rien de ce que tu racontes,
mais j'imagine qu'il s'agit de la création de ce nouveau post.
Si c'est le cas, j'en suis désolé...