Essayez d'éviter d'utiliser des commentaires de code lors de la refactorisation des pages Web

Wulin.com (www.vevb.com) Introduction de l'article: Je n'ai jamais vu de recherche scientifique le prouver, mais dans le domaine du logiciel, c'est comme un dogme ou une croyance commune. En raison de son existence, il est important d'écrire facilement des logiciels et de faire attention au type de code lisible. Ces exigences peuvent être réalisées grâce à certaines techniques, dont une rédaction de commentaires de code.

Avertissement: Ce que j'ai dit à propos d'éviter les commentaires du code ne signifie pas que je n'écris pas de commentaires, ce qui signifie que j'évite d'écrire des commentaires de code autant que possible, mais je les écris quand je pense que cela en vaut la peine.

Nous passons plus de temps à lire un logiciel que d'écrire un logiciel, et je n'ai jamais vu de recherche scientifique le prouver, mais dans le domaine du logiciel, c'est comme un dogme ou une croyance commune. En raison de son existence, il est important d'écrire facilement des logiciels et de faire attention au type de code lisible. Ces exigences peuvent être réalisées grâce à certaines techniques, dont une rédaction de commentaires de code.

Lorsque vous parlez de commentaires de code, il y a toujours un débat sans fin. Devrions-nous utiliser des commentaires pour illustrer le rôle de notre code? Faut-il nous concentrer sur l'expressivité du code sans avoir besoin de commentaires pour aider à la lecture? Joe Kunk a écrit un blog sur l'argument - ne devriez-vous pas écrire des commentaires. Certaines personnes disent que le code bien documenté est considéré comme un bon code, et certains disent que les commentaires doivent être évités car les commentaires sont souvent utilisés pour expliquer / masquer le code mauvais.

À mon avis, sous l'influence des livres, pour s'assurer que le code est soigné et facile à refactor, nous devons éviter d'écrire des commentaires à moins d'avoir une bonne raison d'écrire des commentaires (tels que des algorithmes mathématiques) ou en raison des exigences ou des processus de l'entreprise, nous sommes obligés de le faire. Voici cinq préoccupations concernant les notes.

Où je pense que les commentaires du code fonctionnent contre-effets 1. Les commentaires encouragent souvent le mauvais code

Le code commenté est un bon code Il y a un tel dicton, donc les gens ajoutent souvent des commentaires au code pour rendre le code magnifique. Si nous ajoutons des commentaires pour interpréter le code, c'est comme un signal: peut-être que nous écrivons un mauvais code. Lorsque nous voulons écrire un commentaire, nous devons nous demander si nous pouvons le rendre plus lisible en nettoyant le code.

2. Nous passerons plus de temps à écrire et à maintenir

Les commentaires sont généralement la deuxième version du code. Nous nous répétons en fait lorsque nous écrivons des commentaires pour une fonction. Nous avons violé le principe sec (ne vous répétez pas). Nous passons plus de temps et ajoutons de la complexité. Si les exigences changent, le code doit également changer et si nous écrivons des commentaires, nous devons également les modifier. Alors faites un changement pour deux fois le temps que vous passez. Nous pouvons utiliser ce temps pour améliorer notre code ou développer de nouvelles fonctionnalités.

3. Les commentaires ne sont pas testables et vérifiés

Lorsque nous modifions le code, nous utilisons des compilateurs, des IDE et des outils de test unitaire pour aider, et il n'y a pas de commentaires et pas d'outils similaires. Vous ne pouvez pas compter sur des outils ou des tests unitaires pour vous assurer qu'ils sont utilisés correctement, des annotations de date, etc. Une fois que vous avez rédigé un commentaire, car il n'est pas testable et ne peut pas prêter attention à sa précision, il sera préservé sans aucun doute une fois qu'il va mal.

4. Les commentaires ne sont pas fiables par rapport au code

Habituellement, lorsque les commentaires et le code s'en sortent, il devient moins significatif. Si un programmeur le lit, il peut être induit en erreur. Même sans tromper, vous devez lire le code source pour comprendre ce que vous faites. Pour un exemple pratique, si notre patron a besoin de nous pour apporter une modification, devrions-nous regarder les commentaires ou le code? Bien sûr, nous examinerons le code.

5. Les commentaires occupent beaucoup d'espace d'écran

Certaines méthodes de commentaires (comme celle ci-dessous) occupent beaucoup de lignes, ce qui devient un problème lorsque vous voulez voir plus de code.

/ **

*

* @param titre le titre du CD

* @param auteur l'auteur du CD

* @param suit le nombre de pistes sur le CD

* @param Durée en avant la durée du CD en quelques minutes

* /

public void addcd (titre de chaîne, auteur de chaîne,

Int Tracks, int DuréeInminutes) {

CD CD = nouveau CD ();

cd.title = title;

cd.author = auteur;

cd.tracks = pistes;

CD.Duration = durée;

cdlist.add (cd);

}