[bonne pratique] garder les NSLog
Anis
Membre
bonjour j'ai fait un prog dans lequel j'i ai mis certain NSLog pour m'indiquer dans le debugger certaine chose qui ne serait utile qu'a moi.
Comment sa se passe au niveau du device, le device prend t'il en compte les NSLog (& les NSAssert)?
Dois-je "encommenter" ces ligne?
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Ce qui est parfois pratique. D'ailleurs tu peux voir les logs de toutes les applis sur ton iDevice.
En général ce que je fais c'est que je n'utilise jamais NSLog. Je préfère utiliser des frameworks de log comme CocoaLumberjack et ma petite surcouche pour gérer des modules de log, comme ça au lieu de J'écris, grâce à mes macros & CLJ :
Et comme ça mes logs ont un niveau (Error, Warning, Info, Verbose), ont un "module" (LogModules.Network, LogModules.UI, ...), et dans mon .h où je liste les "LogModules" que je veux, je met un niveau pour chaque. Comme ça je peux très facilement en changeant ma config dans ce fichier faire taire complètement tous les logs du LogModule.UI, et garder les logs du LogModule.Network qui sont au niveau Error mais pas en dessous, ...)
Quand je m'apprête à publier mon appli sur l'AppStore, ça me prend 5 secondes pour passer tous mes LogModules en LOG_LEVEL_OFF pour tous les faire taire et basta. Bien plus modulaire que les NSLog qui sont inconditionnels, et n'ont pas de notion de level ni de module.
Sinon, t'as la méthode ChatNoir : replace all NSLog par //NSLog avant de releaser.
Ben quoi ?
Moi, bourrin ?!
C'est une autre question. Les assertions provoquent des exceptions, ce qui se traduit par un plantage chez l'utilisateur.
Aussi, les assertions doivent être désactivés quand on compile en mode Release.
Justement, dans les dernières versions de Xcode, il existe une option de compilation Enable Foundation Assertions, qui est activée en mode Debug, mais pas en Release.
@Ali
est-ce qu'on peut imaginer que le même symbole " par exemple myLogError() " puisse faire référence à différentes fonctions selon les classes utilisées ?
Dans ce cas, on pourrait imaginer que dans la classe MyClass, myLogError() renvoie vers quelque chose du type myLogError(MyClassName, ...).
On pourrait alors désactiver/activer les logs classe par classe.
Est-ce que tu peux nous montrer à quoi ressemble tes fonctions NFLog ?
J'ai déjà le mécanisme des niveaux de logs chez moi mais cette idée de log par module (ou, mieux, par classe) m'intéresse. J'utilise, comme conseillé ici, CocoaLumberJack.
Merci !
La methode ChatNoir est la plus aproprié pour moi actuellement mais l'utilisation des log de Ali est tres interessante. Je pense que j'utiliserais cette methode prochainement.
Imaginons Que l'on laisse tout les logs, qui ne servent qu'a nous, sur le device en release, est-ce-que cela ralentira le CPU?
Des trucs intéressants sur les Macro possibles :
http://forum.cocoacafe.fr/topic/9378-vos-macros-les-plus-utiles/?hl=%2Bmacro+%2Butiles
Perso, au final, j'utilise ça :
En commentant quand j'en veux pas le #define DEBUG_TYPE_DE_DEBUG.
J'en ai pas mal de DEBUG_HTTP (pour débugguer mon code en rapport avec le WebService, etc.) à DEBUG_BLE, etc.
Oui, ça prend du temps, puisqu'il faut écrire du texte dans un fichier. En français, logging se traduit par journalisation. ça sert à conserver une trace du fonctionnement. Donc, en release, on ne devrait logguer que les choses inattendues. ça doit surtout te servir à comprendre les circonstance d'un bug quand un utilisateur te signale un problème.
Pour ceux qui l'ignorent peut-être, on peut consulter les logs sur le device avec cette appli :
https://itunes.apple.com/us/app/console/id317676250?mt=8
Par exemple pour tout ce qui touche à ma base CoreData, j'utilise mon LogModules.CoreData pour tous les logs associés, que je règle à plus ou moins verbeux selon mes besoins (plus verbeux si je suis en train de débuguer la partie CoreData, moins sinon...). Si j'avais à régler le niveau pour chacune de mes classes modèle (mes sous-classes de NSManagedObject), j'en aurais un sacré paquet à modifier, alors qu'en pratique elles sont toutes regroupées fonctionnellement...
Pour les macros en question, y'a déjà un sujet dédié comme indiqué par Larme