Cattiva idea lasciare le chiamate "console.log()" nel codice JavaScript di produzione?

Question

Ne ho un sacco console.log() chiamate nel mio JavaScript.

Devo commentarli prima di distribuirli in produzione?

Vorrei semplicemente lasciarli lì, quindi non devo prendermi la briga di aggiungere nuovamente i commenti in seguito se ho bisogno di fare ulteriore debug.È una cattiva idea?

Answer 1

Si provocare errori Javascript, terminando l'esecuzione del blocco di JavaScript contenente l'errore.

Si potrebbe, tuttavia, definire una funzione fittizia che è un no-op quando Firebug non è attivo:

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

Se si utilizzano metodi diversi da log, si avrebbe bisogno di spegnere quelle pure.

Answer 2

Come altri hanno già fatto notare che, lasciandolo in causerà errori in alcuni browser, ma quegli errori possono essere aggirato mettendo in qualche stub.

Tuttavia, non vorrei unico commento fuori, ma a titolo definitivo rimuovere quelle linee. Sembra proprio sciatta di fare altrimenti. Forse sto essere pedante, ma non credo che la "produzione" codice dovrebbe includere il codice "debug" a tutti, anche in forma commentato. Se si lascia commenti in a tutti, tali osservazioni devono descrivere ciò che il codice sta facendo, o il ragionamento dietro di esso - non blocchi di codice disabilitato. (Anche se, la maggior parte dei commenti devono essere rimossi automaticamente dal processo di minimizzazione. Stai riducendo al minimo, giusto?)

Inoltre, in molti anni di lavoro con JavaScript, non riesco a ricordare mai tornare a una funzione e dire "Accidenti, vorrei avevo lasciato quei console.logs a posto qui!" In generale, quando sono "fatto" con il lavoro su una funzione, e poi devono tornare, sto tornando a risolvere qualche altro problema. Qualunque cosa che il nuovo problema è che se i console.logs da un precedente round di lavoro avrebbe potuto essere utile, allora avrei individuato il problema per la prima volta. In altre parole, se dovessi tornare a qualcosa, io non sono probabilmente bisogno esattamente le stesse informazioni di debug di cui avevo bisogno in precedenti occasioni.

Solo i miei due centesimi ... Buona fortuna!

Answer 3

Se si dispone di uno script di distribuzione, è possibile utilizzarlo per togliere le chiamate per console.log (e minify il file).

Mentre si è in esso, si può buttare i vostri JS attraverso JSLint e registrare le violazioni in materia di ispezione (o prevenire la diffusione).

Questo è un grande esempio del perché si desidera automatizzare la distribuzione. Se il processo consente di pubblicare un file js con console.logs in essa, ad un certo punto si lo fanno.

Answer 4

Per quanto ne so non esiste un metodo più breve spegnendo console.log oltre i seguenti 45 caratteri:

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

Questa è la prima delle 3 versioni differenti a seconda che i metodi console si desidera spegnere tutti sono minuscoli e tutti sono stati testati in IE6 + e browser moderni.

Le altre due versioni della copertura variando altri metodi di console. Uno copre le quattro basi e l'altro copre tutti i metodi noti per console Firebug e WebKit. Anche in questo caso, nel file più piccolo formati possibili.

Questo progetto è su GitHub: https://github.com/andyet/ConsoleDummy.js

Se si può pensare a un modo per ridurre ulteriormente il codice, i contributi vengono accolti.

- EDIT - 16 Maggio 2012

Da allora ho migliorato su questo codice. E 'ancora molto piccolo, ma aggiunge la capacità di trasformare l'output della console e si spegne: https://github.com/HenrikJoreteg/andlog

E 'stato presenti sul Changelog Mostra

Answer 5

Si dovrebbe almeno creare un console.log fittizio, se l'oggetto non esiste in modo che il codice non gettare gli errori sulle macchine degli utenti senza Firebug installato.

Un'altra possibilità sarebbe quella di attivare la registrazione solo in 'modalità debug', cioè se è impostata una certa bandiera:

if(_debug) console.log('foo');
_debug && console.log('foo');

Answer 6

Spero che aiuti qualcuno: qualche tempo fa ho scritto un wrapper, è leggermente più flessibile della soluzione accettata.

Ovviamente, se usi altri metodi come console.info ecc., puoi replicare l'effetto.una volta terminato con l'ambiente di staging, modifica semplicemente il valore predefinito C.debug in false per la produzione e non dovrai modificare nessun altro codice/estrarre righe ecc.È molto facile tornare indietro ed eseguire il debug in seguito.

var C = {
    // console wrapper
    debug: true, // global debug on|off
    quietDismiss: false, // may want to just drop, or alert instead
    log: function() {
        if (!C.debug) return false;

        if (typeof console == 'object' && typeof console.log != "undefined") {
            console.log.apply(this, arguments); 
        }
        else {
            if (!C.quietDismiss) {
                var result = "";
                for (var i = 0, l = arguments.length; i < l; i++)
                    result += arguments[i] + " ("+typeof arguments[i]+") ";

                alert(result);
            }
        }
    }
}; // end console wrapper.

// example data and object
var foo = "foo", bar = document.getElementById("divImage");
C.log(foo, bar);

// to surpress alerts on IE w/o a console:
C.quietDismiss = true;
C.log("this won't show if no console");

// to disable console completely everywhere:
C.debug = false;
C.log("this won't show ever");

Answer 7

Questo sembra funzionare per me ...

if (!window.console) {
    window.console = {
        log: function () {},
        group: function () {},
        error: function () {},
        warn: function () {},
        groupEnd: function () {}
    };
}

Answer 8

pensato che vorrei condividere una prospettiva diversa. Lasciando questo tipo di uscita visibile al mondo esterno in un'applicazione PCI rende non conforme.

Answer 9

Sono d'accordo che lo stub console è un buon approccio. Ho provato vari plugin per console, frammenti di codice, tra cui alcuni piuttosto complesse. Tutti avevano qualche problema in almeno un browser, così ho finito per andare con qualcosa di semplice come qui di seguito, che è una fusione di altri frammenti che ho visto e alcuni suggerimenti da parte del team YUI. E sembra funzionare in IE8 +, Firefox, Chrome e Safari (per Windows).

// To disable logging when posting a production release, just change this to false.
var debugMode = false;

// Support logging to console in all browsers even if the console is disabled. 
var log = function (msg) {
    debugMode && window.console && console.log ? console.log(msg) : null;
};

Nota: Supporta disabilitare la registrazione alla console tramite una bandiera. Forse si potrebbe automatizzare questo tramite script di compilazione troppo. In alternativa, si potrebbe esporre UI o qualche altro meccanismo per capovolgere questo flag in fase di esecuzione. È possibile ottenere molto più sofisticato, naturalmente, con i livelli di registrazione, l'Ajax presentazione di log in base a soglie di log (ad esempio tutte le dichiarazioni livello di errore vengono trasmesse al server per l'archiviazione ci ecc.).

Molti di questi fili / domande in giro per la registrazione sembrano pensare di dichiarazioni di registro come codice di debug e non codice strumentazione . Da qui il desiderio di rimuovere le dichiarazioni di registro. La strumentazione è estremamente utile quando un'applicazione è in natura e non è più facile da collegare un debugger o informazioni è alimentato a voi da un utente o tramite il supporto. Non si dovrebbe mai registrare nulla sensibili, indipendentemente da dove è stato registrato in modo privacy / sicurezza non dovrebbe essere compromessa. Una volta che si pensa alla registrazione come strumentazione diventa ora il codice di produzione e dovrebbe essere scritto per lo stesso standard.

Con le applicazioni che utilizzano JavaScript sempre più complesso credo che la strumentazione è critica.

Answer 10

Come altri hanno menzioni sarà gettato un errore nella maggior parte dei browser. In Firefox 4 non genera un errore, il messaggio viene registrato nella console Web Developer (di nuovo in Firefox 4).

Una soluzione a tali errori che mi è piaciuto è stato de && bug :

var de = true;
var bug = function() { console.log.apply(this, arguments); }

// within code
de&&bug(someObject);

Answer 11

Una bella one-liner:

(!console) ? console.log=function(){} : console.log('Logging is supported.');