Vos macros les plus utiles
AliGator
Membre, Modérateur
Hello,
Je commence un nouveau sujet pour partager quelques macros que j'utilise de plus en plus et que je trouve très utiles.
Par exemple, depuis que j'ai découvert la macro _Pragma(x) pour générer des #pragma à la volée uniquement quand la macro est déroulée, j'en ai trouvé des usages très pratiques :
Avantage de ces macros, c'est que ça génère un type de warning/message différent des autres, que l'on peut facilement filtrer en triant tes warnings par type, et en plus ça a un préfixe commun ([TODO] ou [FIXME] ou [NOTE]) qui permet en plus de savoir de quoi il retourne, de les isoler facilement.
Exemple d'utilisation :
Cela va me générer 3 warnings propres, et si j'exécute l'action testAction cela va même me mettre une UIAlertView pour indiquer à l'utilisateur que l'action n'est pas encore codée
/smile.png' class='bbc_emoticon' alt=':)' />
Je commence un nouveau sujet pour partager quelques macros que j'utilise de plus en plus et que je trouve très utiles.
Par exemple, depuis que j'ai découvert la macro _Pragma(x) pour générer des #pragma à la volée uniquement quand la macro est déroulée, j'en ai trouvé des usages très pratiques :
#define GENERATE_PRAGMA(x) _Pragma(#x)<br />
#define TODO(x) GENERATE_PRAGMA(message("[TODO] " #x))<br />
#define FIXME(x) GENERATE_PRAGMA(message("[FIXME] " #x))<br />
#define NOTE(x) GENERATE_PRAGMA(message("[NOTE] " #x))<br />
#define MAGIC_NUMBER FIXME(Replace magic number with constant)<br />
#define NOT_IMPLEMENTED(warningMessage...) [[[[UIAlertView alloc] initWithTitle:@"Not implemented" \<br />
message:[NSString stringWithFormat:@"%s",__PRETTY_FUNCTION__] \<br />
delegate:nil cancelButtonTitle:@"OK" otherButtonTitles:nil] autorelease] show]; \<br />
TODO(Implement this - warningMessage)
Avantage de ces macros, c'est que ça génère un type de warning/message différent des autres, que l'on peut facilement filtrer en triant tes warnings par type, et en plus ça a un préfixe commun ([TODO] ou [FIXME] ou [NOTE]) qui permet en plus de savoir de quoi il retourne, de les isoler facilement.
Exemple d'utilisation :
- (IBAction)testAction<br />
{<br />
NOT_IMPLEMENTED(This action should show the next screen);<br />
}<br />
- (void)centerHorizontally<br />
{<br />
TODO(Check if this method is called every time the view width change)<br />
CGRect rect = self.view.frame;<br />
rect.origin.x = (320 - rect.size.width) / 2; MAGIC_NUMBER<br />
self.view.frame = rect;<br />
}
Cela va me générer 3 warnings propres, et si j'exécute l'action testAction cela va même me mettre une UIAlertView pour indiquer à l'utilisateur que l'action n'est pas encore codée
Mots clés:
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Vers la fin du projet, j'mets un UIAlertView au démarrage...
Pour ma ToDoList, j'ai pris l'habitude d'une UIAlertView...
Mais j'vais voir de plus près ta macro...
Ca a l'air sympa ... je vais tester ça. Tu peux mettre le define pour NOT_IMPLEMENTED.
Merci.
C'est pour ça que je vais y jeter un oe“il...
En effet cela n'a rien à voir.
Mettre des UIAlertView ça a plusieurs inconvénients :
L'avantage de mes macros c'est que ça met des warnings, donc tu les vois à la compilation, et non pas à l'exécution. Donc tu peux pas les louper, et pas besoin d'exécuter ton appli et de passer par tous les chemins / cas d'usage pour vérifier que tu as implémenté tout ce qu'il te restait à faire !
Ah oui en effet oubli de ma part, bien vu ! J'ai édité mon post plus haut pour la rajouter
Alors oui et non : je met ça dans un fichier Macros.h. Et c'est ce fichier Macros.h que je #import dans mon fichier PCH.
Ce qui me permet d'avoir un fichier Macros.h partagé par mes projets, utilisé par mes templates de projet et aussi versionné.
1) Je peux les désactiver facilement
2) Justement, de par ma politique/volonté de zero-warnings, ça me force un peu à régler ces warnings qui sinon polluent un peu ma vue ^^
C'est un peu comme une TODO-List : quand tu fais une liste de toutes les choses que tu as à faire, tu peux le prendre du côté déprimant "purée j'ai tout ça à faire" ou tu peux le prendre du côté jouissif à chaque fois que tu enlèves des éléments de la liste "ahah ça c'est fait, ma liste diminue je vais en venir à bout"
Par expérience, si mon met pas ces TODO, on oublie toujours de faire des trucs. Même si on s'est dit dans un coin de notre tête "tiens faudra que je pense à fignoler ça un jour", au final on le fait jamais car ça passe à la trappe.
Ou alors on met des commentaires dans le code pour y penser, mais on les relis jamais (et comme, contrairement aux macros qui doivent contenir le mot exact TODO avec la syntaxe, dans les commentaire on peut un peu écrire ce qu'on veut, on risque fort de ne pas écrire le même mot clé dans tous les commentaires, parfois "TODO" parfois "TO-DO", parfois "[TODO]"...
Qui n'a jamais vu des code source avec des commentaires dedans du genre "Temporary Fix" ou "Patch temporaire pour contourner tel bug, à régler plus tard"... commentaires qui datent de 2 ans ou plus parce que finalement personne ne les a fixés et qu'au lieu d'une petite rustine temporaire "le temps de finir" c'est devenu la solution crade permanente.
Certes en mettant ce genre de macros type TODO dans le code cela génère plein de warnings. Mais justement ça te force à les régler. Alors que sinon ils passent forcément à la trappe, c'est assuré.
Ainsi tu peux spécifiquement encadrer la valeur ou l'expression qui nécessite d'être remplacée.
Voilà deux petites fonctions/macros que j'aime bien utiliser:
Et voici une amélioration des macros de @yoann:
Elles prennent en compte le fait que LogMessageF() prends un format comme dernier argument. Ce changement est plus qu'une amélioration c'est important, car si la NSString générée par ton format contient un % mal placé tu vas avoir des surprises.
Dans cette version tu n'auras pas ce problème. De plus, elles prennent moins de place.
L'avantage par rapport a la feuille de papier, c'est qu'on peut partager via la gestion de configuration et qu'on est certain que tout le monde va voir les TODO, ce qui n'est pas le cas dUn TODO.TXT planqué dans un coin.
En plus je ne connaissais pas _Pragma, j'ai bien fait de venir...
Une autre technique qui n'utilise pas les pragma c'est d'utiliser des commentaires comme ceci:
L'inconvénient c'est que tu n'as pas de warning pour ça, mais l'avantage c'est qu'il s'affiche dans le menu des symboles de ton fichier donc tu peux y aller directement.
- On ne va pas si souvent dans le menu des symboles. Enfin si, moi j'y vais souvent, mais ce n'est pas toujours le cas de mes collègues d'une part, et puis on ne pense pas à y aller POUR voir les TODO et FIXME
- Tu es obligé d'aller dans chaque fichier pour voir s'il a des TODO ou des FIXME, ce qui est injouable en pratique
- Note qu'avec les warnings aussi tu peux y aller directement
Bah tu peux toujours faire une recherche dans le projet
Car en pratique on sait très bien ce qui se passe au fur et à mesure de l'avancée d'un projet sinon... à la fin plus personne ne recherche les TODO ou FIXME pour penser à les corriger.
Bien vu :-)
J'ai fait les macro pour moi, de fait je sais comment les utiliser sans chercher plus loin :-)
Une amélioration intéressante serait d'avoir non pas le nom de la classe d'afficher mais classe d'origine + méthode (cà d éviter d'avoir le nom d'une sous classe) ou si on est pas dans une méthode mais une fonction, le nom de la fonction.
Si quelqu'un a une combine propre pour ça, je suis preneur.
C'est le principe de __FUNCTION__, __PRETTY_FUNCTION__ et __func__
Oui c'est le principe en effet (je n'avais cependant pas noté que cela faisait bien le distinguo avec les sous classe). NSLogger permet d'ailleurs de l'afficher d'origine, donc j'ai un peu revu mes macro en adaptant les corrections proposés.
Pour le moment j'ai ceci :
Le gros avantage de cette version est que les macro de log fonctionnent que je sois dans une méthode ou dans une fonction.
Maintenant je perd une chose vraiment intéressante de mes macros précédentes, je n'ai pas l'adresse de l'objet qui me parle.
Je suis donc à la recherche d'une méthode précompilo qui me permet de faire un "si le mot clef self est disponible dans le contexte, alors... sinon..."
Facile :
Voici donc un simple define qui permet d'identifier l'iPhone 5, en attendant mieux de la part d'Apple..
Je mettrai plutôt == 568 non ?
Car si un jour on a un iPhone de 640 de haut, il faudra modifier cette macro. ;-)
Mais à mon avis on est tranquille un bon bout de temps
Je ne connaissais pas cette règle.