Bad idéia para deixar “console.log ()” chamadas em seu código JavaScript produção?

Question

Eu tenho um monte de chamadas console.log() no meu JavaScript.

Devo comentário los antes de implantar a produção?

Eu gostaria de deixá-los lá, então eu não tenho que ir para o trabalho de re-adicionando os comentários mais tarde, se eu preciso fazer mais depuração. Será esta uma má idéia?

Answer 1

Ele vai causar erros de JavaScript, terminando a execução do bloco de Javascript que contém o erro.

Você poderia, no entanto, definir uma função fictícia que é um não-op quando Firebug não está ativo:

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

Se você usar qualquer outro que log métodos, você precisa stub fora aqueles também.

Answer 2

Como outros já apontou-a, deixando-o em causará erros em alguns navegadores, mas esses erros pode ser contornado, colocando em alguns tocos.

No entanto, gostaria não só comentá-las, mas outright remover essas linhas. Parece apenas superficial para fazer o contrário. Talvez eu estou sendo pedante, mas eu não acho que o código "produção" deve incluir o código "debug" em tudo, mesmo em forma comentou. Se você deixar um comentário em em tudo, esses comentários devem descrever o que o código está fazendo, ou o raciocínio por trás dele - e não blocos de código desativado. (Embora, a maioria dos comentários devem ser removidos automaticamente pelo processo de minimização. Você está minimizando, certo?)

Além disso, em vários anos de trabalho com JavaScript, não posso lembro de alguma vez voltar para uma função e dizendo "Gee, eu gostaria de ter deixado esses console.logs no lugar aqui!" Em geral, quando estou "feito" com o trabalho em uma função, e depois tem que voltar a ele, eu estou voltando para corrigir algum outro problema. O que quer que esse novo problema é que, se os console.logs de uma rodada anterior de trabalho poderia ter sido útil, então eu teria descoberto o problema pela primeira vez. Em outras palavras, se eu voltar a algo, eu não sou propensos a precisar exactamente a mesma informação de depuração como eu precisava em ocasiões anteriores.

Apenas meus dois centavos ... Boa sorte!

Answer 3

Se você tem um script de implantação, você pode usá-lo para retirar as chamadas para console.log (e apoucar o arquivo).

Enquanto você está nisso, você pode jogar o seu JS através JSLint e registrar as violações de inspeção (ou impedir a implantação).

Este é um grande exemplo de por que você deseja automatizar a implantação. Se o seu processo permite que você publique um arquivo js com console.logs em que, em algum momento você irá fazê-lo.

Answer 4

Para o meu conhecimento não há nenhum método mais curto de apagando console.log do que os 45 caracteres seguintes:

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

Essa é a primeira de 3 versões diferentes, dependendo de qual métodos de console que você deseja stub todos eles são minúsculos e todos foram testados no IE6 + e navegadores modernos.

As outras duas versões cobrir variando outros métodos de console. Um cobre os quatro princípios básicos e as outras coberturas todos os métodos de console para o Firebug e webkit conhecidos. Mais uma vez, no arquivo menor tamanhos possíveis.

Esse projeto está no github: https://github.com/andyet/ConsoleDummy.js

Se você pode pensar de qualquer maneira de minimizar o código ainda mais, as contribuições são bem-vindas.

- EDIT - 16 de maio de 2012

Eu já melhorou neste código. Ainda é pequena, mas adiciona a capacidade de transformar a saída do console on e off: https://github.com/HenrikJoreteg/andlog

Foi destaque no changelog Mostrar

Answer 5

Você deve pelo menos criar um console.log manequim se o objeto não existe para que o seu código não vai jogar erros em máquinas dos usuários sem o Firebug instalado.

Outra possibilidade seria a de logging gatilho apenas em 'modo de depuração', ou seja, se um determinado sinalizador é definido:

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

Answer 6

Espero que ajude alguém - eu escrevi um wrapper para ele um tempo atrás, a sua um pouco mais flexível do que a solução aceita .

Obviamente, se você usar outros métodos, como console.info etc, você pode replicar o efeito. quando feito com o seu ambiente de teste, basta alterar o padrão C.debug para false para a produção e você não terá que alterar qualquer outro código / tomar linhas fora etc. Muito fácil de voltar e depuração mais tarde.

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

Isso parece funcionar para mim ...

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

Answer 8

percebi que eu iria compartilhar uma perspectiva diferente. Deixando esse tipo de saída visível para o mundo exterior em um aplicativo PCI faz você não compatível.

Answer 9

Eu concordo que o stub console é uma boa abordagem. Eu tentei vários plugins console, trechos de código, incluindo alguns bastante complexos. Todos eles tinham algum problema em pelo menos um navegador, então eu acabei indo com simples algo como abaixo, que é uma fusão de outros trechos que eu vi e algumas sugestões da equipe de YUI. Parece função no IE8 +, Firefox, Chrome e Safari (para 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: Ele suporta desabilitar o log para o console por meio de uma bandeira. Talvez você possa automatizar essa via scripts de construção também. Alternativamente, você poderia expor UI ou algum outro mecanismo para inverter esta bandeira em tempo de execução. Você pode obter muito mais sofisticado é claro, com níveis de log, ajax apresentação de registros com base em limiar de log (por exemplo, todas as declarações nível de erro são transmitidos para o servidor para armazenamento lá etc.).

Muitos desses tópicos / questões em torno de log parecem pensar de declarações de log como código de depuração e não código de instrumentação . Daí o desejo de remover as instruções de registro. Instrumentação é extremamente útil quando um aplicativo está em estado selvagem e ele não é mais tão fácil é para anexar um depurador ou informação é enviada a você de um usuário ou através de apoio. Você nunca deve registrar qualquer coisa sensível, independentemente de onde ele foi registrado no modo de privacidade / segurança não deve ser comprometida. Uma vez que você acha do registro conforme instrumentação torna-se agora o código de produção e deve ser escrito com o mesmo padrão.

Com aplicações usando javascript cada vez mais complexo Eu acho que a instrumentação é crítica.

Answer 10

Como outros têm menciona que irá jogado um erro na maioria dos navegadores. No Firefox 4 não irá lançar um erro, a mensagem é registrada no console do desenvolvedor web (novo no Firefox 4).

Uma solução para esses erros que eu realmente gostei foi de && bug :

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

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

Answer 11

Um one-liner agradável:

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