Spice for Xcode : réutilisez vos bouts de code
Spice for Xcode [1.0 – US – 9,99 € – OS X 10.7 – WildPalm Ltd.] simplifie la sauvegarde et la gestion de bouts de codes utilisés pour des projets Xcode (Gratuit). L'outil de développement d'Apple intègre déjà un gestionnaire de snippets, mais celui-ci va beaucoup plus loin en gérant notamment les dépendances associées à un fichier.
Pour commencer, ajoutez un projet Xcode à Spice for Xcode avant de créer un "spice" qui contient le code et les fichiers associés à ce code. Vous pourrez alors facilement ajouter ces ressources à un autre projet en l'ouvrant à nouveau dans l'utilitaire et en ajoutant le "spice" créé précédemment. Si vous insérez du code non-ARC dans un projet qui utilise ARC, Spice for Xcode proposera de le convertir au passage.
Spice for Xcode devrait s'avérer efficace pour les développeurs qui doivent gérer un grand nombre de projets avec souvent du code en commun. En un nombre limité d'opérations, vous pourrez ajouter du code, un élément d'interface ou encore une API à un projet existant. Il manque en revanche une version de démonstration pour tester avant achat.
Pour commencer, ajoutez un projet Xcode à Spice for Xcode avant de créer un "spice" qui contient le code et les fichiers associés à ce code. Vous pourrez alors facilement ajouter ces ressources à un autre projet en l'ouvrant à nouveau dans l'utilitaire et en ajoutant le "spice" créé précédemment. Si vous insérez du code non-ARC dans un projet qui utilise ARC, Spice for Xcode proposera de le convertir au passage.
Spice for Xcode devrait s'avérer efficace pour les développeurs qui doivent gérer un grand nombre de projets avec souvent du code en commun. En un nombre limité d'opérations, vous pourrez ajouter du code, un élément d'interface ou encore une API à un projet existant. Il manque en revanche une version de démonstration pour tester avant achat.
Le moyen le plus cracra d'écrire des programmes, faire du copier/coller...
@ treizep
C'est tellement plus amusant de toujours recopier les mêmes routines à la main...
@treizep
Tu plaisantes ! le copier/coller en programmation c'est une pratique courante et efficace …
Par contre perso je ne suis pas adepte de ce genre d'outil, une automatisation de plus dont je me passe … je préfère largement le copier/coller à la main; question de gout ...
@treizep +1
@Seccotine -1
Le bon code c'est comme les bons romans, si on peut éviter le copier/coller: tant mieux
@denisbook
Très usitée, mainte fois hélas, suivre ce lien pour mieux comprendre : http://fr.wikipedia.org/wiki/Ne_vous_répétez_pas
@ denisbook : "Le copier/coller en programmation c'est une pratique courante et efficace" ???
Très efficace oui pour faire du "quick and dirty", du "vite fait mal fait".
Si tu dupliques un bout de code 10 fois à des endroits différents de ton appli, six mois ou un an plus tard quand tu devras faire des corrections ou modifications, tu devras rechercher dans ton code tous les endroits où tu as dupliqué le code. Et gare si tu en oublies! Et si c'est quelqu'un d'autre qui devra modifier ta merde, tu peux être sûr qu'il va te traiter de tous les noms. Imagine en plus si tu as modifié le code dupliqué à un endroit, et que cette modification est minime. Et si tu n'as pas mis de gros commentaires (de toute façon tu n'as pas mis de commentaire, car la mentalité du vite fait mal fait ne pousse pas à en mettre), celui modifiera ton code derrière toi risque de ne pas voir cette différence et paf, du code de perdu et un bogue corrigé qui réapparait*. Et du code dupliqué ne serait-ce qu'une fois peut aboutir à ça !
Le copier/coller, la méthode de la feignasse qui ne veut pas prendre deux minutes pour factoriser son code. Pourtant l'orienté objet est idéal pour ça. Au pire, les "procédures" et autres "fonctions", c'est pas fait pour les chiens.
(*) C'est l'explication la plus courante à ceux qui se demandent pourquoi un bogue corrigé à la version 2.3 réapparaît à la 3.0 (avec les erreurs de gestion du versioning des sources).
@ Grenade et @ marc_os
Vous avez pas compris... on copie colle une routine qu'on adapte. Si c'est pour écrire la même chose qui a la même structure, chaque fois le réécrire serait profondément débile.
Surtout que vouloir réécrire un code qui a bien été rodé, c'est plutôt pour rajouter des bugs qu'en éviter...