Organisation des classes dans Xcode
muqaddar
Administrateur
Salut,
Bon, je bosse toujours sur mon iVinophile... et d'autres projets.
Dites-moi, vous n'êtes jamais trop à l'étroit sur un écran de portable pour développer quand on atteint un certain nombre de classes ? Ni à l'étroit dans votre tête ? Parfois, j'ai des "absences" et je me demande quelle ligne j'étais en train de chercher ne serait-ce que pour un copier-coller de code...
Vivement mon iMac car j'en ai marre de scroller...
Bref, quelles sont vos façons de faire pour l'organisation de vos classes dans Xcode lorsque le projet devient conséquent, c-a-d environ 100 classes.
Bon, je bosse toujours sur mon iVinophile... et d'autres projets.
Dites-moi, vous n'êtes jamais trop à l'étroit sur un écran de portable pour développer quand on atteint un certain nombre de classes ? Ni à l'étroit dans votre tête ? Parfois, j'ai des "absences" et je me demande quelle ligne j'étais en train de chercher ne serait-ce que pour un copier-coller de code...
Vivement mon iMac car j'en ai marre de scroller...
Bref, quelles sont vos façons de faire pour l'organisation de vos classes dans Xcode lorsque le projet devient conséquent, c-a-d environ 100 classes.
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Spaces reste pratique pour pas avoir trop de fenêtres partout, c'est un bon début.
Ensuite dans Xcode, avec bcp de classes, faut bien organiser ses "Groups & Files" c'est clair
Moi perso :
- Je mets un "group" pour chaque ViewController que je dois créer, groupe dans lequel je met le .h, le .m et le .xib (plutôt que de mettre le XIB dans "Resources" totalement à part du .h/.m quoi).
- Je sépare M/V/C en tout cas surtout M et VC : mes classes métier + modèle dans un "Group" (éventuellement sous-groupé pour les classes réseau, les classes métier, le modèle), mes ViewControllers dans un autre "Group", et mes "Widgets" (= sous-classes persos de UIView quand nécessaire) dans un 3e Group...
- Penser à utiliser les "Smart Groups" ! Pour retrouver rapidement un XIB par exemple
(ou alors tu laisses "Wildcard pattern" et tu mets "*.?ib")... d'ailleurs je me demande bien pourquoi ils ont toujours pas adapté la pattern de ce smart group dans le template projet ^^
- C'est vrai que je pense pas souvent à les utiliser non plus, mais ça me rappelle qu'il existe aussi les "Bookmarks" pour rapidement accéder aux endroits de ton code entre lesquels tu navigues souvent. Pareil, le smartgroup "Bookmarks" te permet de les lister pour y aller ensuite.
- Ou sinon ne pas oublier les petits menus cachés dans les icônes en haut à droite de la TextView où tu saisis ton code (Bookmarks, Breakpoints, Classes, Headers, + bouton pour switcher entre .h et .m)...
- Y'a aussi la barre des favoris (View > Layout > Show Favorites Bar), où l'on peut faire glisser des fichiers... mais je trouve ça moins pratique que les bookmarks
...
Bref avec les astuces du genre, on peut déjà mieux s'en sortir (les bookmarks c'est vrai que c'est pratique).
Après, avec un écran plus grand, ou un 2e écran, c'est quand même bien plus agréable, c'est sûr :P
Finalement y'a plein de perles cachées, dans Xcode :P
Et pour les devs iPhone, je crée des groupes qui correspondent à l'arborescence de la navigation.
Mais bon, ça suffit pas toujours.
Je vais regarder du côté des bookmarks.
Si je faisais comme toi, un groupe par VC, j'aurais un paquet de groupes... ce qui augmente encore la hauteur de la navigation à gauche.
>:( Depuis, je n'arrive plus à me contenter de l'écran du PwB (sauf si je voyage).
En fait ce que je voulais mettre en avant ici, c'est que je trouve plus simple de mettre le XIB avec le .m et .h plutôt que de devoir aller le chercher dans "Ressources" si on veut éditer le XIB associé à la classe.
Mais c'est vrai, ça fait bcp de groupes... mais c'est pour ça qu'il faut bien s'organiser ensuite et regrouper ces groupes par fonctionnalités et par "section" que tu as dans ton appli, etc...
Sinon pour le double écran, attention, c'est adictif ! J'ai sur le mac pro un 24" + un 22" en mode portrait + Spaces avec un esapce Xcode, un doc et un IB et éventuellement un laptop a coté pour les forum, du coup j'arrive plus a coder juste sur mon laptop :-p
Donc, si XXX.m est dans le groupe taratata du projet machin, je trouverai le fichier XXX.m dans le dossier taratata du dossier machin. Very simple, isn't it?
Sinon j'essais aussi de séparer les différentes parties du MVC, même si j'ai aussi tendance à regrouper mes vues avec mes controleurs.
Par contre, bonne idée de faire un groupe pour chaque vue/controleur avec .h .m et .xib
Sinon pour j'ai essayé d'utiliser la barre de favoris, mais je suis pas fan. Pour les smarts groups, pareil, au final y'a tout dedans est c'est chaud de s'y retrouver. Je préfère largement naviguer dans l'arborescence de mon projet.
Un truc qui manque par contre c'est de pouvoir mettre des couleurs d'étiquettes comme dans le Finder. ça pourrait être pratique.
Un truc que j'aimerais aussi c'est de pouvoir changer le format d'affichage de certains fichiers : genre les .h sont en gris italique. Car ne se baser que sur l'icône ou l'extension c'est chiant ^^
Sinon un truc de bien chiant, c'est Interface Builder... Autant dans les autres apps, la palettes je trouve ça trop bien, autant dans Interface Builder c'est chiant, c'est impossible d'avoir sa fenêtre + l'inspecteur + la library + le truc qui liste les objets à la fois... Surtout quand on fait une interface d'iPad qui prend la totalité de l'écran... :-/
Encore si les palettes étaient accessibles en utilisant exposé, ok, mais c'est pas le cas :-/
Enfin bref, voilà un peu comment j'organise mes projets et surtout mes petites frustrations ^^
Attention, il y a une nuance
Pratique quand on est en train de bosser sur une ou deux parties spécifiques d'un gros fichier .m pour y revenir rapidement régulièrement.
PS : Je ne peux que plussoyer l'utilisation de bugreport.apple.com
Certes ça reste moins précis que les bookmarks Xcode, mais pratique quand même.
Ceci dit je vais quand même essayé de voir ces bookmarks dont tu parles, car non seulement ça t'emmènes là où tu veux dans ton code (comme mes "#pragma marks") mais l'avantage c'est que t'as besoins d'ouvrir le fichier d'abord. Donc j'avoue que ça peut être bien pratique ;-)
Et sinon ouai, faudra que je pense à faire des reports sur bugreport. Là pendant les vacances je vais avoir le temps de beaucoup coder, donc je vais me mettre dans un coin tout ce que je verrais bien comme améliorations, et après j'enverrais à Apple qui finira par m'embaucher tellement j'ai de trop bonnes idées... ou pas ^^'
Ou plutôt des "[tt]// MARK:[/tt]" (qui sont équivalents aux #pragma marks mais que je préfère pour diverses raisons), ainsi que "[tt]// TODO:[/tt]" et "[tt]// ?[/tt][tt]??:[/tt]" ou autres "[tt]// ![/tt][tt]!!:[/tt]" : j'en fait fort usage, tout comme les TextMacros que je personnalise et utilise à foison (et dans lesquelles je mets déjà les "[tt]// MARK:[/tt]" justement)
Par exemple ma TextMacro qui me génère automatiquement le code de UITableViewDelegate+UITableViewDataSource quand je tape "table" dans le code, j'ai un "[tt]// MARK:[/tt]" devant les méthodes delegate et un autre avant celle du dataSource, avec un "[tt]// MARK: -[/tt]" entre les deux pour mettre un séparateur dans le menu, etc.
C'est vrai que tout ça est très pratique et fait partie aussi des choses que tout le monde ne pense pas à utiliser.
sinon, le todo je vois, mais les ??? et !!! tu t'en sers généralement pour quoi ?
Je me sers effectivement bcp plus du MARK et du TODO que de ??? et de !!!, je me sers du ??? surtout quand je reprend un code qui n'est pas de moi et que je ne capte pas pourquoi l'auteur a mis ça (et donc qu'il faudra revenir dessus pour s'assurer que ce code qui me semble bizarre ne pose pas de pb) et !!! quand j'ai noté un truc qu'il faudra que je revois mais qui marchotte pour l'instant, genre un patch vite fait qui n'a qu'une vocation temporaire... Autrement dit, je n'utilise pratiquement jamais c'est ??? et !!! :P
Je préfère "// MARK:" parce que :
- c'est plus uniforme avec les autres notations
- ça peut être mis à la fin d'une ligne ou autre et pas que en début de ligne
- les #pragma ne sont pas portables (bon ok qd on fait de l'Obj-C en même temps... mais bon, c'est une règle générique, quand on peut éviter les #pragma qui sont des instructions très dépendantes du compilateur, c'est une bonne habitude)
- j'ai une TextMacro qui écrit directement cette marque entre deux lignes pleines de "////", et en plus de bien séparer dans le code les diverses sections ça fait plus zouli :P Bref, c'est un peu arbitraire comme choix, mais voilà :P
Par contre du coup le fait que ce soit de la même couleur que des commentaires "normaux" me dérange :-/
Et sinon, ça serait possible que tu partages tes macros ? ^^
Mais il est vrai que même en faisant des groupes pour séparer M et VC, il est quand même parfois difficile de retrouver ses petits. Je vais tester les bookmarks !