web-dev-qa-db-ja.com

"console.log（）"コールをプロダクションJavaScriptコードに残すのは悪い考えですか？

JavaScriptに多数のconsole.log()呼び出しがあります。

本番環境にデプロイする前にコメント化する必要がありますか？

そのまま残したいので、後でデバッグする必要がある場合にコメントを再度追加する手間が省けます。これは悪い考えですか？

javascriptdebuggingloggingproduction
73
Charlie Kotter

Javascriptエラーが発生し、エラーを含むJavaScriptのブロックの実行が終了します。

ただし、Firebugがアクティブでない場合は何もしないダミー関数を定義することもできます。

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

log以外のメソッドを使用する場合は、それらもスタブ化する必要があります。

118
Jason Creighton

他の人がすでに指摘しているように、そのままにしておくと一部のブラウザでエラーが発生しますが、これらのエラーは一部のスタブを配置することで回避できます。

ただし、コメントアウトするだけでなく、それらの行を完全に削除します。それ以外の場合はだらしないようです。たぶん私は知識を深めているのですが、「製品」コードに「デバッグ」コードをコメント形式で含めるべきではないと思います。コメントを残す場合、それらのコメントは、コードが何をしているか、またはその背後にある理由を説明する必要があります。無効にされたコードのブロックではありません。 （ただし、ほとんどのコメントは縮小プロセスによって自動的に削除されます。最小化していますよね？）

また、JavaScriptを使用して数年経った今、関数に戻って「ああ、ここにconsole.logsを残しておけばよかった！」と言ったことを思い出すことはできません。一般に、関数の作業が「完了」し、後でその関数に戻る必要がある場合、他の問題を修正するために戻ってきます。その新しい問題が何であれ、前の作業のconsole.logsが役に立ったとしたら、私はその問題を初めて発見したでしょう。つまり、何かに戻ったとしても、以前とまったく同じデバッグ情報が必要になることはほとんどありません。

ちょうど私の2セント...がんばって！

36
Chris Nielsen

配備スクリプトがある場合は、それを使用してconsole.logへの呼び出しを取り除く（そしてファイルを縮小する）ことができます。

その間、JSLintを介してJSをスローし、違反を検査のためにログに記録できます（またはデプロイメントを防止できます）。

これは、展開を自動化する理由の良い例です。プロセスでconsole.logsを含むjsファイルを公開できる場合、ある時点でwillを実行します。

10
Nosredna

私の知る限り、次の45文字よりも短いconsole.logをスタブ化する方法はありません。

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

これは、どのコンソールメソッドをスタブ化したいかに応じて、3つの異なるバージョンのうちの最初のものであり、すべてが小さなものであり、すべてIE6 +および最新のブラウザーでテストされています。

他の2つのバージョンは、他のさまざまなコンソールメソッドをカバーしています。 1つは4つの基本をカバーし、もう1つはfirebugとwebkitのすべての既知のコンソールメソッドをカバーします。繰り返しますが、可能な限り小さなファイルサイズです。

そのプロジェクトはgithubにあります： https://github.com/andyet/ConsoleDummy.js

コードをさらに最小化する方法を考えることができれば、貢献を歓迎します。

-編集-2012年5月16日

その後、このコードを改善しました。まだ小さいですが、コンソール出力のオンとオフを切り替える機能が追加されています。 https://github.com/HenrikJoreteg/andlog

変更ログショーで特集

9
Henrik Joreteg

それが誰かを助けることを願っています-私はしばらくの間それのためのラッパーを書きました、それは受け入れられたソリューションよりわずかに柔軟性があります。

もちろん、console.infoなどの他の方法を使用すれば、効果を再現できます。ステージング環境での作業が終わったら、本番環境でデフォルトのC.debugをfalseに変更するだけで、他のコードを変更したり、行を削除したりする必要はありません。後で戻ってデバッグするのは非常に簡単です。

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");
5
Dimitar Christoff

少なくともダミーを作成する必要がありますconsole.logオブジェクトが存在しないため、Firebugがインストールされていないユーザーのマシンでコードがエラーをスローしない場合。

別の可能性は、「デバッグモード」でのみロギングをトリガーすることです。つまり、特定のフラグが設定されている場合です。

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

これは私のために働くようです...

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

コンソールスタブが良いアプローチであることに同意します。かなり複雑なものを含む、さまざまなコンソールプラグイン、コードスニペットを試しました。少なくとも1つのブラウザーで問題が発生したため、以下のような単純なものになりました。これは、私が見た他のスニペットとYUIチームからの提案の融合です。 IE8以降、Firefox、ChromeおよびSafari（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;
};

注：フラグによるコンソールへのロギングの無効化をサポートします。おそらく、ビルドスクリプトを使用してこれを自動化することもできます。または、UIまたは他のメカニズムを公開して、実行時にこのフラグを反転させることもできます。もちろん、ログレベル、ログしきい値に基づくログのajax送信（たとえば、すべてのエラーレベルステートメントがサーバーに送信されてそこに保存されるなど）により、はるかに洗練されたものにすることができます。

ログに関するこれらのスレッド/質問の多くは、ログステートメントをコードではなくデバッグコードと見なしているようですinstrumentation。したがって、ログステートメントを削除したいという要望があります。インストルメンテーションは、アプリケーションが公開されていて、デバッガーをアタッチすることが簡単ではない場合や、ユーザーから、またはサポートを介して情報が提供されたりする場合に非常に役立ちます。機密情報が記録されている場所に関係なく、機密情報を記録しないでください。プライバシー/セキュリティが侵害されることはありません。ロギングをインストルメンテーションとして考えると、これは本番用コードになり、同じ標準に書き込む必要があります。

より複雑なJavaScriptを使用するアプリケーションでは、インストルメンテーションが重要だと思います。

2
tidmutt

別の視点を共有するだろうと考えました。このタイプの出力をPCIアプリケーションの外部に表示したままにすると、非準拠になります。

2
McGovernTheory

他の人が言及しているように、ほとんどのブラウザーでエラーがスローされます。 Firefox 4ではエラーはスローされず、メッセージはWeb開発者コンソールに記録されます（Firefox 4の新機能）。

私が本当に気に入ったそのような間違いに対する1つの回避策は de && bug でした：

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

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

素敵なワンライナー：

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