Comment marquez-vous le code pour pouvoir revenir plus tard et travailler dessus?
En C # j'utilise le #warning et #error directives,
#warning This is dirty code...
#error Fix this before everything explodes!
De cette façon, le compilateur me fera savoir que j'ai encore du travail à faire. Quelle technique utilisez-vous pour marquer le code afin de ne pas l'oublier?
Marquez-les avec // TODO, // HACK ou d'autres jetons de commentaire qui s'afficheront dans le volet Office de Visual Studio.
Todo commente aussi.
Nous avons également ajouté un mot clé spécial NOCHECKIN, nous avons ajouté un crochet de validation à notre système de contrôle de source (très facile à faire avec au moins cvs ou svn) où il analyse tous les fichiers et refuse de l'archiver s'il trouve le texte NOCHECKIN n'importe où.
Ceci est très utile si vous voulez simplement tester quelque chose et être sûr qu'il ne sera pas accidentellement enregistré (passé les yeux vigilants lors de la diff de tout ce qui est commis au contrôle de source).
J'utilise une combinaison de //TODO://HACK: Et throw new NotImplementedException(); sur mes méthodes pour indiquer le travail qui n'a pas été fait. De plus, j'ajoute des signets dans Visual Studio sur des lignes incomplètes.
// TODO: Nom de la personne - veuillez corriger cela.
C'est en Java, vous pouvez ensuite regarder les tâches dans Eclipse qui localiseront toutes les références à cette balise, et pouvez les regrouper par personne afin que vous puissiez assigner un TODO à quelqu'un d'autre, ou seulement regarder les vôtres.
Si je dois tout laisser tomber au milieu d'un changement, alors
#error finish this
Si c'est quelque chose que je devrais faire plus tard, il va dans mon traqueur de bogues (qui est utilisé pour toutes les tâches).
Les commentaires "à faire" sont excellents en théorie, mais pas si bons en pratique, du moins d'après mon expérience. Si vous allez être éloigné assez longtemps pour en avoir besoin, alors ils ont tendance à être oubliés.
Je privilégie la stratégie générale de Jon T, mais je le fais généralement en cassant simplement le code temporairement - j'insère souvent une référence de méthode délibérément indéfinie et je laisse le compilateur me rappeler à quoi je dois revenir:
PutTheUpdateCodeHere();
Ajoutez un test dans un état désactivé. Ils apparaissent dans tous les rapports de build.
Si cela ne fonctionne pas, je dépose un bug.
En particulier, je n'ai jamais vu les commentaires de TODO diminuer en quantité de manière significative. Si je n'ai pas eu le temps de le faire quand j'ai écrit le commentaire, je ne sais pas pourquoi j'en aurais plus tard.
Une approche que j'ai vraiment aimée est "Hack Bombing", comme l'a démontré Oren Eini ici .
try
{
//do stuff
return true;
}
catch // no idea how to prevent an exception here at the moment, this make it work for now...
{
if (DateTime.Today > new DateTime(2007, 2, 7))
throw new InvalidOperationException("fix me already!! no catching exceptions like this!");
return false;
}
//TODO: Finish this
Si vous utilisez VS, vous pouvez configurer vos propres balises de tâche sous Outils> Options> Environnement> Liste des tâches
gvim met en évidence "// XXX" et "// TODO" en jaune, ce qui m'a étonné la première fois que j'ai marqué du code de cette manière pour me rappeler d'y revenir.
J'utilise // TODO: ou // HACK: pour rappeler que quelque chose est inachevé avec une note expliquant pourquoi. Je reviens souvent (lire "rarement") et termine ces choses en raison de contraintes de temps. Cependant, lorsque je regarde le code, j'ai un enregistrement de ce qui est resté inachevé et, plus important encore, POURQUOI.
Un autre commentaire que j'utilise souvent à la fin de la journée ou de la semaine:
// COMMENCEZ ICI CHRIS
^^^^^^^^^^^^^^^^^^^^^ Me dit où je me suis arrêté pour que je puisse minimiser mon temps bootstrap lundi matin).
Je suis un programmeur C++, mais j'imagine que ma technique pourrait être facilement implémentée en C # ou tout autre langage d'ailleurs:
J'ai une macro ToDo(msg) qui se développe en construisant un objet statique à portée locale dont le constructeur génère un message de journal. De cette façon, la première fois que j'exécute du code inachevé, je reçois un rappel dans ma sortie de journal qui me dit que je ne peux plus reporter la tâche.
Cela ressemble à ceci:
class ToDo_helper
{
public:
ToDo_helper(const std::string& msg, const char* file, int line)
{
std::string header(79, '*');
Log(LOG_WARNING) << header << '\n'
<< " TO DO:\n"
<< " Task: " << msg << '\n'
<< " File: " << file << '\n'
<< " Line: " << line << '\n'
<< header;
}
};
#define TODO_HELPER_2(X, file, line) \
static Error::ToDo_helper tdh##line(X, file, line)
#define TODO_HELPER_1(X, file, line) TODO_HELPER_2(X, file, line)
#define ToDo(X) TODO_HELPER_1(X, __FILE__, __LINE__)
... et vous l'utilisez comme ceci:
void some_unfinished_business() {
ToDo("Take care of unfinished business");
}
Ce n'est pas un monde parfait, et nous n'avons pas toujours le temps infini pour refactoriser ou méditer le code.
Je mets parfois //REVIEW dans le code si je veux y revenir plus tard. c'est-à-dire que le code fonctionne, mais peut-être pas convaincu que c'est la meilleure façon.
// REVIEW - RP - Is this the best way to achieve x? Could we use algorithm y?
De même pour //REFACTOR
// REFACTOR - should pull this method up and remove near-dupe code in XYZ.cs
Ce sont les trois façons différentes que j'ai trouvées utiles pour signaler quelque chose qui doit être résolu.
Placez un indicateur de commentaire à côté du code qui doit être consulté. La plupart des compilateurs peuvent reconnaître des drapeaux communs et les afficher de manière organisée. Habituellement, votre IDE possède une fenêtre de surveillance spécialement conçue pour ces indicateurs. L'indicateur de commentaire le plus courant est: // TODO Voici comment l'utiliser:
// TODO: Corrigez cela avant qu'il ne soit publié. Cela provoque une violation d'accès car il utilise de la mémoire qui n'est pas encore créée.
Une façon de signaler quelque chose qui doit être résolu avant la publication serait de créer une variable inutile. La plupart des compilateurs vous avertiront si vous avez une variable qui n'est pas utilisée. Voici comment vous pouvez utiliser cette technique:
int This_Is_An_Access_Violation = 0;
Signets IDE. La plupart des produits sont livrés avec un moyen de placer un signet dans votre code pour référence future. C'est une bonne idée, sauf qu'elle ne peut être vue que par vous. Lorsque vous partagez votre code, la plupart des IDE ne partagent pas vos signets. Vous pouvez vérifier le système de fichiers d'aide de votre IDE pour voir comment utiliser ses fonctionnalités de création de signets.
Todo Comment.
S'il s'agit de dette technique à long terme , vous pouvez commenter comme:
// TODO: This code loan causes an annual interest rate of 7.5% developer/hour. Upfront fee as stated by the current implementation. This contract is subject of prior authorization from the DCB (Developer's Code Bank), and tariff may change without warning.
... euh. Je suppose qu'un TODO le fera, tant que vous ne les ignorerez pas simplement.
J'utilise // FIXME: xxx pour le code cassé et // CHGME: xxx pour le code qui a besoin d'attention mais fonctionne (peut-être seulement dans un contexte limité).
// TODO: <explanation>
si c'est quelque chose que je n'ai pas réussi à mettre en œuvre et que je ne veux pas oublier.
// FIXME: <explanation>
si c'est quelque chose qui, selon moi, ne fonctionne pas bien et que je veux revenir plus tard ou que d'autres yeux le regardent.
Je n'ai jamais pensé aux options # error/# warning. Celles-ci pourraient également être utiles.
Comme la plupart des programmeurs semblent le faire ici, j'utilise des commentaires TODO. De plus, j'utilise l'interface de tâche d'Eclipse Mylyn . Lorsqu'une tâche est active, Mylyn se souvient de toutes les ressources que j'ai ouvertes. De cette façon, je peux suivre
- où dans un fichier je dois faire quelque chose (et quoi),
- dans quels fichiers je dois le faire, et
- à quelle tâche ils sont liés.
J'utilise également TODO: commentaires. Je comprends la critique selon laquelle ils sont rarement corrigés et qu'ils seraient mieux rapportés comme des bugs. Cependant, je pense que cela manque quelques points:
Je les utilise le plus lors de développements lourds, quand je refactorise et redessine constamment des choses. Je les regarde donc tout le temps. Dans des situations comme celle-là, la plupart d'entre elles sont effectivement traitées. De plus, il est facile de rechercher TODO: pour être sûr de ne rien manquer.
Il peut être très utile pour les personnes lisant votre code de connaître les endroits qui, selon vous, ont été mal écrits ou piratés ensemble. Si je lis du code inconnu, j'ai tendance à chercher des schémas organisationnels, des conventions de dénomination, une logique cohérente, etc. De cette façon, je ne perds pas de temps à essayer de trouver une logique là où il n'y en a pas.