/*/ comment here do some thing. /*/ do some thing. //*/ Why people write code like that? Is this a good practice?
9 Réponses :
Tout le monde a la propre façon de faire des choses ... Je suppose qu'ils ont fait cela, tout ce que vous avez à faire est d'ajouter un / vers le premier commentaire et supprimez le dernier / puis il bascule le bloc de commentaire à l'autre. ensemble d'instructions.
Edit: En réalité, tout ce que vous avez à faire est d'ajouter un / au premier commentaire, puis supprimez-le pour le basculer.
Il est généralement utilisé uniquement lorsque vous testez quelque chose pour le moment. C'est-à-dire que vous ne devez jamais commettre code comme celui-là au contrôle de la version, car il peut être déroutant.
Par exemple, si vous testez deux méthodes de calcul différentes, vous pouvez l'utiliser pour basculer entre eux. Personnellement, j'ai rarement fait cela, si du tout. P>
Pour ceux qui ne savent pas, vous pouvez basculer entre les deux sections de code en ajoutant une barre oblique avant: p>
/*/ comment here do some thing. /*/ do some thing else. //*/ //*/ comment here do some thing. /*/ do some thing else. //*/
Ce style smacks de quelque chose de plus permanent, cependant, compte tenu de l'attention sur la facilité de faire / défaire les différents blocs. Lorsque vous testez, je serais plus enclin à signaler simplement / noter tout le bloc en utilisant // sur chaque ligne. Un bon IDE devrait également faire cela trivial.
Bien que ce soit soigné si vous êtes coincé à l'aide de Pico, je n'aime toujours pas le faire.
Oui, j'ai tendance à copier des blocs aussi. Je pense que pendant un moment je vais essayer d'appliquer cette technique afin que je puisse obtenir une opinion plus juste à ce sujet.
Absolument pas. C'est terrible même pour ce que vous décrivez.
Assez. Pour basculer entre deux blocs de code, j'utilise #idif 1 ... #else ... #endif. Ensuite, basculez entre 1 et 0. Je n'ai vraiment pas besoin de mon syntaxe surligneur pour me dire quelle version est activée.
Je préférerais faire mais c'est une question de goût
Même c'est mal pratiquant. Vous devez utiliser le bloc #IF dans les fichiers d'en-tête pour configurer des macros. Le code utilise ensuite les macros (comme des fonctions similaires) sans aucune #Si afin que le code réel est égal à lire. Les macros gèrent ensuite les détails de la mise en œuvre.
Certainement mauvaises pratiques pour de vraies macros, mais une meilleure alternative à commenter le code. Bien sûr, TVANFosson a raison - le code mort ne devrait pas être là en premier lieu.
Pratique de merde. Le code mort n'a pas d'entreprise suspendu à un code de qualité de production. S'il y a vraiment des situations où l'ancien code mort s'appliquerait, il devrait être refacturé dans quelque chose qui peut être activé / désactivé à l'aide de la configuration non de recompilation.
La question ne dit pas que c'est dans le code de production. Je pense que j'ai peut-être utilisé ce genre de chose dans les rapports de bugs.
@Tom Hawtin-tacline - typiquement quand on demande s'il s'agit d'une bonne pratique, ils ne demandent pas s'il y a un cas d'angle où il pourrait être acceptable. Je suppose que l'OP veut savoir si c'est quelque chose qui devrait régulièrement être fait. Imo, ça ne devrait pas.
qui me confond et me prendrait du temps pour analyser, donc non je ne pense pas que ce soit une bonne pratique.
Toute facilité de basculement mentionnée dans la réponse de Kane n'en vaut pas la peine, je pense. La facilité de commentaire devrait être prise en charge par le navigateur de développeurs.
Pour moi, c'est juste déroutant et certainement pas standard.
C'est juste un moyen facile de basculer entre deux blocs de code (comme le dit Kane Wallmann).
Ce n'est probablement pas génial de le laisser dans le code de production (supprimez-le et récupérez-le du contrôle de la source si vous en avez besoin), mais en développant qu'il est pratique de pouvoir basculer rapidement deux implémentations code, etc.).
Je pense que cela et la méthode #IFDEF Les mentions Arkadiy sont mauvaises, en tant que recherche multi-fichier pour faire quelque chose les deux ressemblent à ce que le code est en direct, alors qu'il ne peut pas dépendre des lignes précédentes.
Si le code est valide #Ifdef plate-forme dépendance, assurez-vous que
Mais s'il suffit de tester le code, etc. Je préfère beaucoup en souligner le lot et insérer le commentaire C ++ //, lequel dans VisualStudio est Ctrl-K, C
Pas nécessairement mauvaise pratique, mais attendez-vous à des réponses mitigées de quelqu'un qui lit votre code. Par exemple, je pense que c'est vraiment cool mais ne commet jamais de code comme celui-là au référentiel.
C'est déroutant et manque d'esthétique de programmation. Un bon moyen de le faire consiste à utiliser le préprocesseur C et à le coder comme:
Mieux encore, #Ifdef temporairement_removed_pecace_i_am_testing_says_jaf Bloc de code désactivé #undif alors que vous oubliez de prendre le bloc avant de vous engager, le prochain gars saura pourquoi il était désactivé et s'il devrait le réactiver.
Commentaires - Meilleures pratiques - Stackoverflow.com/Questtions/121945/...