›

[bonne pratique] garder les NSLog

AnisAnis Membre
dans Objective-C, Swift, C, C++ #1

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?


Réponses

  • AliGatorAliGator Membre, Modérateur
    #2
    Oui les NSLog sont conservés. Ca écrit dans la console et les fichiers de log, même en Release.
    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
    NSLog(@Error in request: %@", error);
    
NSLog(@Showing authentication view to user now);
    J'écris, grâce à  mes macros & CLJ :
    NFLogError(LogModules.Network, @Error in request: %@", error);
    
NFLogInfo(LogModules.UI, @Showing authentication view to user now);
    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.
  • LeChatNoirLeChatNoir Membre, Modérateur
    #3

    Sinon, t'as la méthode ChatNoir : replace all NSLog par //NSLog avant de releaser.


     


    Ben quoi ?


    Moi, bourrin ?!


  • CéroceCéroce Membre, Modérateur
    #4


    (& les NSAssert)?


     




    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.

  • colas_colas_ Membre
    septembre 2013 modifié #5

    @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 !


  • AnisAnis Membre
    #6

    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?

  • LarmeLarme Membre
    septembre 2013 modifié #7

    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 :




    
#define	DEBUG_TYPE_DE_DEBUG
    

    

    
#ifdef DEBUG_TYPE_DE_DEBUG
    
#   define DLogTypeDeDebug(fmt, ...) {NSLog((@%s  fmt), __PRETTY_FUNCTION__, ##__VA_ARGS__);}
    
#else
    
#   define DLogTypeDeDebug(...)
    
#endif

    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.


  • CéroceCéroce Membre, Modérateur
    #8


    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?




     


    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.

  • FKDEVFKDEV Membre
    #9

    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

  • AliGatorAliGator Membre, Modérateur
    septembre 2013 modifié #10

    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 ?

    Oui c'est imaginable, mais pas pratique. Car il faudrait définir ensuite un niveau de log par classe, or des classes on en a un sacré paquet dans une application. C'est pour ça que j'ai préféré les modules.

    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 ;)
Connectez-vous ou Inscrivez-vous pour répondre.