Est-ce une mauvaise idée de laisser des appels firebug "console.log" dans votre produit avec du code JavaScript?

Question

J'ai un tas d'appels console.log en JavaScript.

Devrais-je les commenter avant de me mettre en production?

J'aimerais juste les laisser là afin que je n'aie pas à me soucier de supprimer les commentaires plus tard si j'ai besoin de faire du débogage. Est-ce une mauvaise idée?

Answer 1

Cela provoquera des erreurs de Javascript, mettant fin à l'exécution du bloc de Javascript contenant l'erreur.

Vous pouvez cependant définir une fonction fictive qui n’est pas opérationnelle quand Firebug n’est pas actif:

 if(typeof console === "undefined") {
    console = { log: function() { } };
}
 

Si vous utilisez des méthodes autres que log , vous devrez également les remplacer.

Answer 2

Comme d'autres l'ont déjà dit, la laissant dans provoquera des erreurs dans certains navigateurs, mais ces erreurs peut être contourné en mettant dans certains talons.

Cependant, je ne serais pas seul commentaire, mais carrément supprimer ces lignes. Il semble bâclée de faire autrement. Je suis peut-être pédant, mais je ne pense pas que la "production" de code devrait prévoir "debug" code à tous, même dans commenté forme. Si vous laissez des commentaires de tous ces commentaires décrire ce que fait le code, ou le raisonnement derrière cela-pas des blocs de code désactivé. (Bien que, la plupart des commentaires devraient être supprimés automatiquement par votre minification du processus. Vous êtes de la réduction, de droit?)

Aussi, au terme de plusieurs années de travail avec le JavaScript, je ne m'en souviens plus jamais revenir à une fonction et en disant: "Gee, je souhaite que j'avais quitté ceux de la console.les journaux en place ici!" En général, quand je suis "fait" avec le travail sur une fonction, et d'avoir plus tard à revenir, je suis de retour pour résoudre un autre problème. Quoi qu'nouveau problème est, si la console.journaux à partir d'un précédent cycle de travail pourrait être utile, j'en serais repéré le problème la première fois. En d'autres termes, si je reviens à quelque chose, je ne suis pas susceptible d'avoir besoin d'exactement les mêmes informations de débogage comme j'ai besoin de précédentes occasions.

Juste mes deux cents... Bonne chance!

Answer 3

Si vous avez un script de déploiement, vous pouvez l'utiliser pour supprimer les appels à console.log (et réduire le fichier).

Pendant que vous y êtes, vous pouvez lancer votre JS via JSLint et consigner les violations pour inspection (ou empêcher le déploiement).

C'est un excellent exemple de la raison pour laquelle vous souhaitez automatiser votre déploiement. Si votre processus vous permet de publier un fichier js contenant console.logs, vous le ferez à un moment donné.

Answer 4

À ma connaissance, il n'existe pas de méthode plus courte de déraciner console.log maximum 45 caractères:

window.console||(console={log:function(){}});

C'est le premier des 3 versions différentes en fonction de ce qui console les méthodes que vous souhaitez écraser tous d'entre eux sont de minuscules et tous ont été testés dans IE6+ et les navigateurs modernes.

Les deux autres versions couvrent divers autres console méthodes. L'un couvre les quatre principes de base et l'autre couvre tous connus de la console de méthodes pour firebug et webkit. Encore une fois, dans la plus petite taille de fichier possible.

Ce projet est sur github: https://github.com/andyet/ConsoleDummy.js

Si vous pouvez penser de toute façon à minimiser le code en outre, les contributions sont les bienvenues.

-- EDIT -- 16 Mai 2012

Depuis, j'ai amélioré sur ce code. Il est encore tout petit mais ajoute la possibilité de tourner à la sortie de la console sur et en dehors: https://github.com/HenrikJoreteg/andlog

Il a été présenté sur Le Changelog Montrer