(de-)Commenter de gros blocs de code
ClicCool
Membre
Bonjour,
Pour commenter/dé-commenter quelques lignes de code y'a le racourci-clavier Pomme /
Pour de gros blocs il est souvent plus aisé de l'encadrer simplement par la balise "/*" au début et la balise "*/" à la fin du bloc.
Mais quand il s'agit, pour un même bloc de le commenter, puis le dé-commenter à plusieurs reprises c'est vite désagréable.
A peine avons nous tapé le /* que toute la fin de notre page est verte, ce qui rend le repérage visuel de la fin du bloc difficile pour aller y taper le */
On peut alors toujours commencer par repérer la fin du bloc et y placer le */ puis remonter au début pour taper le /* magique.
Mais parfois, à force de commenter/dé-commenter on finit par fatiguer et se prendre des "syntax error befor / token" sur le */ oublié.
Mon truc et d'utiliser comme balise de fin de bloc: "//*"
Comme ça, même si on l'oublie, pas d'erreur de compil, c'est un commentaire comme un autre.
Et en début de bloc on peut alors placer/Enlever/remettre/Commenter un /*
Mieux encore, le racourci-clavier Pomme / appliqué sur le /* deviens alors efficace sur tout le Bloc de code (à l'envers).
/* le bloc de code suivant est commenté
// /* le bloc de code suivant n'est pas commenté
Et on peut tranquillement laisser nos balises autour du bloc en question pour y revenir plus tard
Pour commenter/dé-commenter quelques lignes de code y'a le racourci-clavier Pomme /
Pour de gros blocs il est souvent plus aisé de l'encadrer simplement par la balise "/*" au début et la balise "*/" à la fin du bloc.
Mais quand il s'agit, pour un même bloc de le commenter, puis le dé-commenter à plusieurs reprises c'est vite désagréable.
A peine avons nous tapé le /* que toute la fin de notre page est verte, ce qui rend le repérage visuel de la fin du bloc difficile pour aller y taper le */
On peut alors toujours commencer par repérer la fin du bloc et y placer le */ puis remonter au début pour taper le /* magique.
Mais parfois, à force de commenter/dé-commenter on finit par fatiguer et se prendre des "syntax error befor / token" sur le */ oublié.
Mon truc et d'utiliser comme balise de fin de bloc: "//*"
Comme ça, même si on l'oublie, pas d'erreur de compil, c'est un commentaire comme un autre.
Et en début de bloc on peut alors placer/Enlever/remettre/Commenter un /*
Mieux encore, le racourci-clavier Pomme / appliqué sur le /* deviens alors efficace sur tout le Bloc de code (à l'envers).
/* le bloc de code suivant est commenté
// /* le bloc de code suivant n'est pas commenté
Et on peut tranquillement laisser nos balises autour du bloc en question pour y revenir plus tard
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
Une bonne technique est de mettre le code entre les balises de préprocesseurs #if 0 #endif
Cette technique a plusieurs avantages...
Quand on a besoin de "décommenter" la partie de code "commentée" il suffit de remplacer 0 par 1 au lieu de supprimer les balises.
Il est aussi possible d'alterner facilement deux parties de code qui ont le même but mais qui fonctionnent différemment afin de tester la technique qui marche le mieux :
Merci de tes précisons, tu as raison et nuls doutes que je sous-utilise les instructions de pré-processeur.
(faudrait sans doutes que je sollicite humblement des cours particuliers à Maà®tre Renaud là dessus)
Par contre, si celles-ci sont utiles pour de longs tests sur plusieurs jours, elles ont l'inconvénient majeur de ne pas clairement signaler le code qui ne sera pas exécuté.
Et je t'avoue que, sur une petite série de test genre "avec versus sans"), je préfère que le code exclus soit clairement commenté, en vert (et contre tous ?).
Ca me fait penser à un truc : dans VisualStudio (oui, je sais, c'est M$
Tout ça pour dire : n'y aurait-il pas un moyen de développer ce genre de choses (plugins ? Modifs des prefs quitte à passer par des "defaults" ou creuser plus loin si ce n'est pas dispo par la GUI de XCode ?) pour l'éditeur de code intégré à XCode, qu'il mettre d'une toute autre couleur le code entre un "#if 0 ... #endif" par exemple ?
Sinon je ne sais pas si l'utilisation d'un éditeur externe (certains utilisent TextMate par exemple, comme Renaud justement il me semble) résoud le problème, car la problématique est quand même plus compliquée qu'une simple coloration syntaxique : Ce n'est pas juste une affaire de RegEx pour voir qu'on est entre "/*" et "*/" par exemple, mais il faut aussi que le moteur de coloration évalue la valeur du test derrière le "#if" ou "#ifdef", c'est ça c'est pas toujours évident... surtout si on fait intervenir des macros #defined ou définies dans les réglages du projet Xcode...
Merci Ali, pourfendeur des grincheuxÂ
Je suis ravi d'être là aussi !Â
Le plus fou c'est que au fur et à mesure de ces années bisextiles qui m'offrent leurs 24 heures de plus que j'exploite pour me re-mettre à coder c'est chaque fois un réel plaisir et un bouillonnement d'idées à mettre en pratique arrive immédiatemet
Alors, si on y ajoute la joie de cotoyer tous ces cocoaculteurs c'est le top !Â
J'ajouterais que entre le C (plaisir de rigueur et de pureté) , le C++ (joies de l'encapsulation propre surtout aidé par les supers frameWorks de CodeWarrior) et l'Objective-C avec Cocoa y'a pas photo.
Se remettre au Cocoa, c'est comme de remonter sur un vélo quand on a déjà apris à en faire, ça vient tout seul :brule:
En plus le Projet qui me ramène à mes "amours aux développement généreux" :P est un gros projet et j'aurais sans doutes la joie de m'y plonger quelques mois sans trop culpabiliser
@+
Renaud il utilise TextMate et Xcode, TextMate seul ce n'est pas évident, à cause du manque d'intégration avec le reste.
Sinon pour la question des commentaires, bon évidemment TextMate a une macro pour faire ce que tu souhaites, mais ce n'est pas la question.
La question c'est de savoir si Xcode peut le faire et la réponse est oui.
Menu Script -> Edit User Scripts, puis cliquer sur le + et coller le code suivant:
[tt]#!/usr/bin/env ruby -wKU
input = STDIN.read.to_s
regex = /(.*)\/\*(.*)\*\/(.*)/m
if input =~ regex
print input.gsub(regex,'\1\2\3')
else
print "/*#{input}*/"
end[/tt]
(Juste bien veiller à bien spécifier que l'output remplace la sélection)
Si tu appelles ce script pour une sélection de code qui contient un commentaire en /* */, il supprimera les /* */ sans toucher au reste (donc inutile de sélectionner précisément). Et si la sélection ne contient pas de commentaire, la sélection est commentée. Petite note: il n'y a pas de contrôle pour vérifier que la sélection de contienne qu'une seule des 2 balises.
Pour Ali: TextMate peut certainement faire ce dont tu parles, il fait un truc dans le genre en HTML/CSS: le bundle css est utilisé pour la colorisation pour le texte entre des balises <style></style>. Le tout est de savoir comment.
ça marche impec ton truc :kicking:
Je l'ai ajouté à mes scripts.
Ceci dit on en revient +/- au même soucis que le "Pomme /" traditionnel (sauf évidemment la syntaxe du commentaire)
C'est à dire qu'il faut sélectionner le bloc entier avant d'activer le script, ce qui est facile et clair quand toutes les lignes sont visible sur une seule page (mais à ce moment là les // font l'affaire).
Mais si le bloc est un peu trop gros ....
L'avantage que je trouvais aux "/*" + "//*/" c'était, entre autre, de laisser une balise de fin en place en faisant varier de position la balise de début.
En tous les cas je me coucherai moins bête encore ce soir (pourvu que ça dure) en ayant entrevu grâce à toi l'éditeur de ce menu scriptÂ
je viens de vivre les limitations de mes neurones face à un code n'apparaissant comme clairement exclus.
J'ai passé un long moment ce matin devant mon code "qui ne marchait plus qu'à moitié", jusqu'à ce que me rende compte qu'hier soir j'avais laisser un "#if 0 ..." trainer !!!
Des pages de code modifiées et re-modifiées pour corriger "l'erreur" et 1 heure pour tout remettre en ordre (j'avais pas fait de snapshot avant
Ceci-dit la "méthode Psychoh" est pas mal du tout pour permuter entre 2 blocs à évaluer/comparer ! Merci
Faut juste avoir passé une bonne nuit et brendre un bon café avant de retourner à son code
Si tu veux éviter ce genre de problème, il y a une autre technique : à chaque fois que tu mets un #if, tu rajoutes juste avant (parce qu'après tu ne le vois pas
Et comme ça le compilateur te le fait apparaà®tre à la compilation si tu l'as oublié.
L'autre avantage d'avoir les 2 scripts à portée de main, c'est d'avoir la possibilité de laisser des commentaires en "//" dans le code à ignorer. Sinon le /* */ a aussi un autre avantage: il marche aussi dans une même ligne.
Sinon pour les gros blocs de code, il y a un truc pas mal dans Xcode. Les raccourcis clavier "Set Mark" (ctrl-espace par défaut) "Select to Mark (Ctrl-X-Ctrl-M par défaut - le raccourci c'est la double combinaison).
Donc le principe est simple: tu mets le point d'insertion au début du bloc que tu veux commenter, puis "Set Mark". Puis tu te déplaces tranquillement jusqu'à la fin du dit bloc et là tu appelles "Select To Mark", et hop magie tout est sélectionné.
Et dans la série des "To Mark", il y en a d'autres qui sont intéressants:
"Delete To Mark": explicite
"Swap With Mark": pratique si on édite deux morceaux dans un même fichier pour passer de l'un à l'autre. On pose une marque dans le premier, on va ensuite travailler dans l'autre, puis pour revenir au premier "Swap With Mark", puis pour revenir au second "Swap With Mark" encore.
Mais il faut changer les raccourcis claviers!
Oui en effet
Encore une découverte pour moi, merci
en plus si plusieurs lignes sont sélectionnées lors d'un swap-mark, au swap-mark suivant elle seront encore sélectionnees.
J'ai rouvé une autre solution qui complète uilement la panoplie et résout le problème des mark 'inapparentes'. :brule:
On peut s'approcprier les balises que xCode utilise pour marquer les placeHolder lors d'une autocomplétion
Une ligne commentée contenant un "<#" suivi de-ce-qu'on-veut puis terminé par "#>"
C'est TRES TRES pratique aussi pour marquer les zone du code méritant qu'un y revienne plus tard.
dans le genre
Avantages:
- On peut mettre autant de ces marques explicites que souhaitées
- On navigue rapidement entre les marques avec le raccourci que l'on a choisi dans Text key Bindings des prefs pour "Code Sense select Next Placeholder" et "Code Sense select Previous Placeholder"
- le texte écrit entre les deux balises retrouvées saute aux yeux en apparaisant selectionné et son effacement (y comprs les balises se fait alors d'un seul coup de "backsapce"
Inconvénient:
- évidemment, ces même raccourcis servent aussi pour naviguer entre les "vrai" placeHolder lors d'une complétion. Mais ça gène pas vraiment car dans ce dernier cas les placeHolder sont regroupés sous nos yeux sur maximum 3 lignes et il y a peu de chance qu'on se loupe.
ET, lorsqu'on a l'impression d'avoir fini de coder la classe un rapide coup de "next placeHolder" nous permet de pas louper le dernier bout de code qu'on a encore oublié d'améliorer.
Présision: à noter qu'avec xCode 3.1 les "vrais" placeHolders apparaissent maintenant plus proprement surlignés en bleu et sans balises visibles , mais elles y sont toujours et restent fonctionnelles
Merci ClicCool... etÂ
Attends, je vais voir ça ...
Navré, j'en ai plus
[Mode Mauvaise foi] Faut dire que mon fournisseur attitré ne trouve jamais le temps de venir me voir [\Mode Mauvaise foi]
Mais j'ai une cuvée spéciale de HB si tu veux :
Mais le HB ça me va très bien, de toute façon je me doutais que t'aurais plus de Cantillon et je comptais bien te demander du jaune, là je suis gâtéÂ