より安定した読みやすさの高いJavaScriptコードの作成

誰もが自分のプログラミングスタイルを持っていて、他人のプログラミングスタイルを感じることも避けられません.他人のコードを修正します.」他人のコードを修正する」ことは私たちにとってつらいことです.一部のコードはそんなに読みやすく、メンテナンス可能ではないので、他の人に他の人のコードを修正させ、最終的には1つの変数を修正し、1つの関数の呼び出しタイミングを調整するだけで、1時間以上かけて他の人のコードを読み、明らかにする必要があるかもしれません.ここでは、javascriptコードの読み取りと安定性を向上させるために、取得位置の「コンポーネント」を一歩一歩再構築します.
本文の内容は以下の通りである.

javascriptコードを分離

関数は外部環境

に過度に依存すべきではない.

の意味化および多重化

コンポーネントは論理に注目すべきであり、動作はパッケージ

にすぎない.

独自のスタイルを形成するコード

Javascriptコードを分離

次のコードは、読み取り/変更が困難なコードを示しています.

(function (window, namespace) {
    var $ = window.jQuery;
    window[namespace] = function (targetId, textId) {
        //            "  "
        var $target = $('#' + targetId),//  
            $text = $('#' + textId);//    
        $target.on('click', function () {
            $text.html('   ');
            var data = '   ';//balabala    ，   ，       
            if (data) {
                $text.html(data);
            } else
                $text.html('    ');
        });
    }
})(window, 'linkFly');

このコードは、「コンポーネント」を構成していることを一応認めます.上のコードは典型的な方法ですべてのことを解決し、内部の論理を埋め込むと生活が自立できなくなり、需要が増加すると、例えば位置から戻ってきたデータフォーマットを取得するには加工が必要になり、データを処理するコードを探して修正しなければならない.
論理を分離して、次のコードを得ます.

(function (window, namespace) {
    var $ = window.jQuery,
        $target,
        $text,
        states= ['   ', '    '];
    function done(address) {//      
        $text.html(address);
    }
    function fail() {
        $text.html(states[1]);
    }
    function checkData(data) {
        //          
        return !!data;
    }
    function loadPosition() {
        var data = '   ';//     
        if (checkData(data)) {
            done(data);
        } else
            fail();
    }
    var init = function () {
        $target.on('click', function () {
            $text.html(states[0]);
            loadPosition();
        });
    };
    window[namespace] = function (targetId, textId) {
        $target = $('#' + targetId);
        $text = $('#' + textId);
        initData();
        setData();
    }
})(window, 'linkFly');

関数は外部環境に過度に依存してはいけない。

上のコードでは、コンポーネント全体を様々な関数に切断しました(ここで私が言っているのは関数であり、方法ではないことに注意してください).ここでは、関数が制御できない変数に過度に依存しているという新しい問題がよく発生します.
変数$targetと$textは環境内のグローバル変数としてコンポーネントの初期化から値を付与しますが、私たちが切断したコードの多くの操作方法は$text、特に$textとdone()、fail()の間の曖昧な関係に依存しています.$textに関連する構造、論理が変更されると、私たちのコードは大きく変更されます.
ページ/DOMに関連するものは信頼できない(例えば$targetや$text)が,ページ構造が変化するとその挙動も大きく変化する.関数も外部の環境に依存すべきではありません.制御できない変数では、関数と依存変数の関係を解き、関数を自分の領域の論理に集中させ、より純粋にしなければならない.簡単に言えば、関数に依存する外部変数は、パラメータによって関数内部に伝達されるべきです.新しいコードは次のとおりです.

(function (window, namespace) {
    var $ = window.jQuery;
    //          
    function checkData(data) {
        return !!data;
    }
    //     
    function loadPosition(done, fail) {
        var data = '   ';//     
        if (checkData(data)) {
            done(data);
        } else
            fail();
    }
    window[namespace] = function (targetId, textId) {
       var  $target = $('#' + targetId),
            $text = $('#' + textId);
        var states = ['   ', '    '];
        $target.on('click', function () {
            $text.html(states[0]);
            loadPosition(function (address) {//      
                $text.html(address);
            }, function () {//      
                $text.html(states[1]);
            });
        });
    }
})(window, 'linkFly');

意味化と多重化

変数statesは配列であり、記述された動作は読みにくい.states[0]を見るたびに、変数statesの値を覚えなければならないので、できるだけよく読むことができるようにしなければならない.
なお、上記のコードでは$text.htmlは典型的なコードの繰り返しであり、私たちはもう一度コードを修正します.今回の修正コードでは、私たちが抽出したchangeStateText()のコード位置は、前の環境(つまり、大きな閉パッケージの環境全体)に昇格していないことに注意してください.

(function (window, namespace) {
    var $ = window.jQuery;
    function checkData(data) {
        return !!data;
    }
    function loadPosition(done, fail) {
        var data = '   ';//     
        if (checkData(data)) {
            done(data);
        } else
            fail();
    }
    window[namespace] = function (targetId, textId) {
        var $target = $('#' + targetId),
            $text = $('#' + textId),
            changeEnum = { LOADING: '   ', FAIL: '    ' },
            changeStateText = function (text) {
                $text.html(text);
            };
        $target.on('click', function () {
            changeStateText(changeEnum.LOADING);
            loadPosition(function (address) {
                changeStateText(address);
            }, function () {
                changeStateText(changeEnum.FAIL);
            });
        });
    }
})(window, 'linkFly');

意味化については、現在のコード全体の論理と意味を知る必要があります.
このコンポーネント全体で、すべての関数モジュールは、ツールとツールプロバイダに分けることができます.
前のレベルの環境(大閉パッケージ全体)は、私たちのビジネスでツールのアイデンティティを果たしています.そのタスクは、位置論理の取得に関連するツールを構築することです.window[namespace])関数では、ツールプロバイダのアイデンティティであり、コンポーネントの完全なビジネスをツールに提供する使用者を担当する唯一のエントリです.ここの$text.html()は論理的にツールではなく、ツールプロバイダがツールを使用して得たフィードバックに属するため、changeStateText()関数はツールプロバイダwindow[namespace]()に置かれる.

コンポーネントは論理に注目すべきで、動作はパッケージにすぎない。

ここまで,関数を分離し,このコンポーネントに良好な意味を持たせた.しかし、この時、新しいニーズが来ました.位置が取得されていない場合は、他の操作が必要です.Windows[namespace]()に新しいパラメータを追加する必要があることがわかります.新しいパラメータを追加すると、位置の取得に失敗した後、いくつかの情報を変更し、再び位置情報の取得を試みる必要があるという新しいニーズが通知されます.しかし、幸いなことに、私たちのコードはほとんどの論理をツールプロバイダから抽出しており、ツール全体の論理にはあまり影響しません.コードを見てみると、私たちのコンポーネントはツールプロバイダ以外に方法がありません(オブジェクト上の関数に依存しています).つまり、私たちのコンポーネントにはオブジェクトがありません.
多くの人のコードはいつもツールプロバイダを作るのが好きで、ツールの本質を無視しているのを見たことがあります.上記の増加した需要に迎合すると、私たちのツールプロバイダはますます重くなります.この時、私たちはツールを提供すべきではないかと考えなければなりません.
最初のニーズに戻りましょう.位置を取得するコンポーネントだけです.間違いありません.そのコアビジネスは位置を取得することです.コンポーネント化されるべきではありません.その本質はツールオブジェクトであり、ページに関連するべきではありません.最初からページの変化に注目すべきではありません.コードを再構築してみましょう.

(function (window, namespace) {
    var Gps = {
        load: function (fone, fail) {
            var data = '   ';//       
            this.check(data) ?
                done(data, Gps.state.OK) :
                fail(Gps.state.FAIL);
        },
        check: function (data) {
            return !!data;
        },
        state: { OK: 1, FAIL: 0 }
    };
    window[namespace] = Gps;
})(window, 'Gps');

ここで、私たちは直接ツールプロバイダをつまんで、私たちは直接ツールを外のツール使用者に提供して、ツール使用者に直接私たちのツールを使用させて、ここのコードは状態に関係なくて、ページに関係ありません.
これで再構築が完了します.

独自のコードを作成

なぜなら、みんなが自分のプログラミングスタイルを持っているからです.一部の人のプログラミングスタイルは冒頭のコードです...私は自分のプログラミングスタイルを形成して、良好なコードのと構造/意味の上で創立したと思います.そうしないと、コードが読みにくくなり、書きにくくなるだけです.****単一varとマルチvar個人的には単一varスタイルが好きですが、コードはできるだけある方法/関数を使用する前にvarを行うと思います.時には単一varのために気が狂うこともあります.私は関数式の宣言が好きすぎるので、関数式の宣言はvar文では実行されません.そこで、たまにこのような宣言しながら実行するコードが現れます.悪い子供に教えないためにコードを貼らない(実は見つからないとは言わない).
オブジェクト属性のシールドの下のコードは2つのオブジェクトの构筑を実証して、后1つは闭包を通じて内部属性を隠して、同様に、2つの方法はすべて无new化を実现して、私个人は...多くのthisを见るのが好きではありません..しかし、前者をお勧めします.

(function () {
    //   ，   _name  
    var Demo = function () {
        if (!(this instanceof Demo))
            return new Demo();
        this._name = 'linkFly';
    };
    Demo.prototype.getName = function () {
        return this._name;
    }

    //   ，             ，     _name  
    var Demo = function () {
        var name = 'linkFly';
        return {
            getName: function () {
                return name;
            }
        }
    }
});

巧みに変数を頂点に置く[hoisting]巧みに関数で宣言する変数の頂点に置く特性は、乙女座の心理状態のあなたが単一varを放棄することを意味しますが、あなたの関数をコード構造上非常に明確にすることができます.例えば、次のコードです.

(function () {
    var names = [];
    return function (name) {
        addName(name);
    }
    function addName(name) {
        if (!~names.indexOf(name))//        
            names.push(name);
        console.log(names);// ["linkFly"]
    }
}())('linkFly');

ifと&&というコードは、いくつかのグループで議論されています.

(function () {
    var key = 'linkFly',
        cache = { 'linkFly': 'http://www.cnblogs.com/silin6/' },
        value;
    //&&  
    key && cache && cache[key] && (value = cache[key]);
    //  if
    if (key && cache && cache[key])
        value = cache[key];
})()；

多分こんなことを考えて、私は突然私があまり推薦しないコードを発見して、すべて私が書いたコードで、囧.もし皆さんにももっと面白いコードがあれば、役人の皆さんが弟に見せてほしいです.