js開發規范
本人在開發工作中就曾與不按規范來開發的同事合作過，與他合作就不能用"愉快"來形容了。現在本人撰寫此文的目的除了與大家分享一點點經驗外，更多的是希望對未來的合作夥伴能夠起到一定的借鑒作用。當然，如果我說的有不科學的地方還希望各路前輩多多指教。下面分條目列出各種規范要求，這些要求都是針對同事編碼毛病提出來的，好些行業約定的其它規范可能不會再提及。1. 保證代碼壓縮後不出錯對於大型的JavaScript項目，一般會在產品發布時對項目包含的所有JavaScript文件進行壓縮處理，比如可以利用Google Closure Compiler Service對代碼進行壓縮，新版jQuery已改用這一工具對代碼進行壓縮，這一般會去掉開發時寫的注釋，除去所有空格和換行，甚至可以把原來較長的變數名替換成短且無意義的變數名，這樣做的目的是加快文件的下載速度，同時也減小網站訪問帶來的額外數據流量，另外在代碼保護上也起到了一點點作用，至少壓縮後的代碼即使被還原還是沒那麼容易一下讀懂的。要想代碼能正確通過壓縮，一般要求語句都要以分號正常結束，大括弧也要嚴格結束等，具體還要看壓縮工具的要求。所以如果一開始沒有按標准來做，等壓縮出錯後再回去找錯誤那是浪費時間。2. 保證代碼能通過特定IDE的自動格式化功能一般較為完善的開發工具（比如Aptana Studio）都有代碼"自動格式"化功能，這一功能幫助實現統一換行、縮進、空格等代碼編排，你可以設置自己喜歡的格式標准，比如左大括弧{是否另起一行。達到這個要求的目的在於方便你的開發團隊成員拿你代碼的一個副本用IDE自動格式化成他喜歡或熟悉的風格進行閱讀。你同事需要閱讀你的代碼，可能是因為你寫的是通用方法，他在其它模塊開發過程中也要使用到，閱讀你的代碼能最深入了解方法調用和實現的細節，這是簡單API文檔不能達到的效果。3. 使用標準的文檔注釋這一要求算是最基本的，這有利於在方法調用處看到方法的具體傳參提示，也可以利用配套文檔工具生成html或其它格式的開發文檔供其他團隊成員閱讀，你可以嘗試使用jsdoc-toolkit。如果你自動生成的API是出自一個開放平台，就像facebook.com應用，那麼你的文檔是給天下所有開發者看的。另外編寫完整注釋，也更方便團隊成員閱讀你的代碼，通過你的參數描述，團隊成員可以很容易知道你編寫的方法傳參與實現細節。當然也方便日後代碼維護，這樣即使再大的項目，過了很長時間後，回去改點東西也就不至於自己都忘記了當時自己寫的代碼是怎麼一回事了。4. 使用規范有意義的變數名使用規范有意義的變數名可以提高代碼的可讀性，作為大項目開發成員，自己寫的代碼不僅僅要讓別人容易看懂。開發大項目，其實每個人寫的代碼量可能都比較大，規范命名，日後自己看回自己的代碼也顯的清晰易懂，比如日後系統升級或新增功能，修改起代碼來也輕松多了。如果到頭發現自己當初寫的代碼現在看不太懂了，那還真是天大的笑話了。當然，使用有意義的變數名也盡量使用標準的命名，比如像這里：var me = this也許沒有var self = this好，因為self是Python中的關鍵字，在Python中self就是通常語言this的用法。再看下面一個例子，加s顯然比沒有加來的科學些，這樣可以知道這個變數名存的是復數，可能是數組等： var li = document.getElementsByTagName('li') var lis = document.getElementsByTagName('li') 5. 不使用生偏語法JavaScript作為一門動態腳本語言，靈活性既是優點也是缺點，眾所周知，動態語言不同層次開發人員對實現同樣一個功能寫出來的代碼在規范或語法上會存在較大的差別。不管怎麼樣，規范編碼少搞怪，不把簡單問題復雜化，不違反代碼易讀性原則才是大家應該做的。比如這語句：typeof(b) == 'string' && alert(b)應該改為：if (typeof(b) == 'string') alert(b)，像前面那種用法，利用了&&運算符解析機制：如果檢測到&&前語句返回false就不再檢測後面語句，在代碼優化方面也有提到把最可能出現的情況首先判斷，像這種寫法如果條件少還好，如果條件較多而且語句也長，那代碼可讀性就相當差。又比如：+function(a){var p = a;}( 'a')應該改為：(function(a){var p = a;})( 'a')，其實function前面的+號與包含function的()括弧作用是一樣的，都是起運算優先作用，後者是常見且容易看明白的防止變數污染的做法，比如好些流行JavaScript框架就是採用後面這種方式。再說個降低代碼可讀性的例子，如：function getPostionTxt(type){return type == 2 ? "野外" : (type == 3 ? "商城" : (type == 4 ? "副本" : null));}應該改成：function getPostionTxt(type){var typeData={"2":"野外","3":"商城","4":"副本"};if (typeData[type]) return typeData[type]; else return null;}。如果type是從0開始不間斷的整數，那麼直接使用數組還更簡單，這種結果看起來就清晰多了，看到前面那種多層三元表達式嵌套頭不暈嗎。6. 不在語句非賦值地方出生中文語句中不應該出現中文我想一般人都知道，雖然這樣做不影響程序運行，但是顯然有背行業標准要求，當然我們也不是在使用"易語言"做開發。關於這一個問題，我本來不想把它拿出來說的，但我確實遇到有人這樣做的，也不知道是不是因為他的英語實在太爛了，至少還可以用拼音吧，另外尋求翻譯工具幫忙也不錯的選擇。我舉例如下，像以下寫法出現在教學中倒還可以理解：this.user['名字'] = '張三' 或者 this.user.名字 = '張三'7. 明確定義函數固定數量的參數固定數量參數的函數內部不使用arguments去獲取參數，因為這樣，你定義的方法如果包含較多的腳本，就不能一眼看到這個方法接受些什麼參數以及參數的個數是多少。比如像下面： var $ = function(){return document.getElementById(arguments[0]);}應該改成：var $ = function(elemID){return document.getElementById(elemID);} 8. 不必熱衷動態事件綁定雖然知道事件可以動態綁定，比如使用addEventListener或者使用jQuery的bind方法，也知道採用動態事件綁定可以讓XHTML更干凈，但是一般情況下我還是建議直接把事件寫在DOM節點上，我認為這樣可以使代碼變得更容易維護，因為這樣做，我們在查看源代碼的時候就可以容易地知道什麼Element綁定了什麼方法，簡單說這樣更容易知道一個按鈕或鏈接點擊時調了什麼方法腳本。9. 降低代碼與XHTML的耦合性不要過於依賴DOM的一些內容特徵來調用不同的腳本代碼，而應該定義不同功能的方法，然後在DOM上調用，這樣不管DOM是按鈕還是鏈接，方法的調用都是一樣的，比如像下面的實現顯然會存在問題： function myBtnClick(obj) { if (/確定/.test(obj.innerHTML)) alert('OK'); else if (/取消/.test(obj.innerHTML)) alert('Cancel'); else alert('Other'); } <a herf="javascript:;" onclick="myBtnClick(this)">確定</a><a herf="javascript:;" onclick="myBtnClick(this)">取消</a> 上面例子其實在一個函數內處理了兩件事情，應該分成兩個函數，像上面的寫法，如果把鏈接換成按鈕，比如改成這樣：<input type="button" onclick="myBtnClick(this)" value="確定" />，那麼myBtnClick函數內部的obj.innerHTML就出問題了，因為此時應該obj.value才對，另外如果把按鈕名稱由中文改為英文也會出問題，所以這種做法問題太多了。10. 一個函數應該返回統一的數據類型因為JavaScrip是弱類型的，在編寫函數的時候有些人對於返回類型的處理顯得比較隨便，我覺得應該像強類型語言那樣返回，看看下面的兩個例子： function getUserName(userID) { if (data[userID]) return data[userID]; else return false; } 應該改為： function getUserName(userID) { if (data[userID]) return data[userID]; else return ""; } 這個方法如果在C#中定義，我們知道它准備返回的數據類型應該是字元串，所以如果沒有找到這個數據我們就應該返回空的字元串，而不是返回布爾值或其它不合適的類型。這並沒有影響到函數將來的調用，因為返回的空字元串在邏輯判斷上可被認作"非"，即與false一樣，除非我們使用全等於"==="或typeof進行判斷。11. 規范定義JSON對象，補全雙引號使用標准肯定是有好處的，那麼為什麼還是有人不使用標准呢？我想這可能是懶或習慣問題。也許還會有人跟我說，少寫引號可以減輕文件體積，我認為這有道理但不是重點。對於伺服器返回的JSON數據，使用標准結構可以利用Firefox瀏覽器的JSONView插件方便查看（像查看XML那樣樹形顯示），另外你如果使用jQuery做開發，最新版本jQuery1.4+是對JSON格式有更高要求的，具體的可以自己查閱jQuery更新文檔。比如：{name:"Tom"}或{'name':'Tom'}都應該改成{"name":"Tom"}。12. 不在文件中留下未來確定不再使用的代碼片段當代碼調整或重構後，之前編寫的不再使用的代碼應該及時刪除，如果認為這些代碼還有一定利用價值可以把它們剪切到臨時文件中。留在項目中不僅增加了文件體積，這對團隊其它成員甚至自己都起到一定干擾作用，怕將來自己看回代碼都搞不懂這方法是干什麼的，是否有使用過。當然可以用文檔注釋標簽@deprecated把這個方法標識為不推薦的。13. 不重復定義其他團隊成員已經實現的方法對於大型項目，一般會有部分開發成員實現一些通用方法，而另外一些開發成員則要去熟悉這些通用方法，然後在自己編寫模塊遇到有調用的需要就直接調用，而不是像有些開發者喜歡"單干"，根本不會閱讀這些通用方法文檔，在自己代碼中又寫了一遍實現，這不僅產生多餘的代碼量，當然也是會影響團隊開發效率的，這是沒有團隊合作精神的表現，是重復造輪子的悲劇。比如在通用類文件Common.js有定義function $(elemID){return document.getElementById(elemID)}那麼就不應該在Mail.js中再次出現這一功能函數的重復定義，對於一些復雜的方法更應該如此。14. 調用合適的方法當有幾個方法都可以實現同類功能的時候，我們還是要根據場景選擇使用最合適的方法。下面拿jQuery框架的兩個AJAX方法來說明。如果確定伺服器返回的數據是JSON應該直接使用$.getJSON，而不是使用$.get得到數據再用eval函數轉成JSON對象。如果因為本次請求要傳輸大量的數據而不得以使用$.post也應該採用指定返回數據類型（設置dataType參數）的做法。如果使用$.getJSON，在代碼中我們一眼能看出本次請求伺服器返回的是JSON。溫馨提示：jQuery1.4後，如果伺服器有設置數據輸出的ContentType，比如ASP.NET C#設置 Response.ContentType = "application/json"，那麼$.get將與$.getJSON的使用沒有什麼區別。15. 使用合適的控制項存儲合適的數據曾發現有人利用DIV來保存JSON數據，以待頁面下載後將來使用，像這樣：<div id="json">{ "name":"Tom"}</div>，顯然這個DIV不是用來界面顯示的，如果非要這樣做，達到使用HTML文件進行數據緩存的作用，至少改成用隱藏域來存這數據更合理，比如改成：<input type="hidden" value=" { "name":"Tom"}" />。其實也可以利用window對象來保存一些數據，像上面的例子，我們可以在AJAX請求頁直接包含這樣的腳本塊：<script>window.userData = { "name":"Tom"};</script>，當在AJAX請求回調函數中執行完$( "#MyDiv ").html(data)後，在window上就馬上有了這一變數。如果採用第一種方法，將不可避免eval(document.getElementById("UserData").innerHTML)。如果在window對象存放大量數據的話，這些數據不用時要及時手動清理它們，它們是要等瀏覽器刷新或重啟後才會消失的，這就會增加內存開銷。16. 永遠不要忽略代碼優化工作代碼最優化是每個程序員應該努力達到的目標，也應該成為程序員永遠的追求。寫代碼的時候，不應該急著把功能實現出來，要想一下如何寫代碼，代碼的執行效率才是較好的。舉個例子：假設有定義getElementById的快捷方法functoin $(elemID){return document.getElementById(elemID)}，那麼有人可能會寫出這樣的代碼$("MyDiv").parentNode.removeChild($("MyDiv"))，其實這里執行了兩次getElementById DOM查找，如果改成這樣將更好：var myDiv = $("MyDiv"); myDiv.parentNode.removeChild(myDiv)。還好getElementById的DOM查找算比較快，如果換成getElementsByTagName則更應該注重優化了。jQuery開發團隊也有提醒大家要注意這方面的問題。當然，代碼優化技巧也是需要個人不斷積累的。曾有朋友跟我說他寫網站後台代碼從來不用考慮優化的，因為他們網站用的是至強四核伺服器，我覺得這是很可笑的。17. 會分析策劃文檔，能用面向對象方法進行介面定義和代碼組織這一能力對於每一個程序員來說都是非常重要的，這也是決定一個程序員水平高低的一個重要因素。能夠把需求細化並抽象出不同的類，然後有條理地編寫代碼，使代碼結構清晰，可讀性高，代碼易於維護，不至於太過程化而且雜亂無章，這樣才算是一個優秀的程序員。
B. js代碼規范問題 JavaScript判斷語句規范
所以。。問題是？
C. JavaScript的編程規范
找這個文章
JavaScript程序編碼規范
這是一套適用於JavaScript程序的編碼規范。它基於Sun的Java程序編碼規范。但進行了大幅度的修改, 因為JavaScript不是Java。
軟體的長期價值直接源於其編碼質量。在它的整個生命周期里,一個程序可能會被許多人閱讀或修改。如果一個程序可以清晰的展現出它的結構和特徵,那就能減少在以後對其進行修改時出錯的可能性。
編程規范可以幫助程序員們增加程序的健壯性。
所有的JavaScript代碼都是暴露給公眾的。所以我們更應該保證其質量。
保持整潔很重要。
D. javascript 幫忙把代碼規范化一下，怎麼寫才是好代碼
聲明方法放一起，執行代碼放一起
E. js模塊化編程有什麼規范
基礎
我們首先簡單地概述一下，自從三年前Eric Miraglia（YUI的開發者）第一次發表博客描述模塊化模式以來的一些模塊化模式。如果你已經對於這些模塊化模式非常熟悉了，大可以直接跳過本節，從「進階模式」開始閱讀。
匿名閉包
這是一種讓一切變為可能的基本結構，同時它也是Javascript最棒的特性。我們將簡單地創建一個匿名函數並立即執行它。所有的代碼將跑在這個函數內，生存在一個提供私有化的閉包中，它足以使得這些閉包中的變數能夠貫穿我們的應用的整個生命周期。
復制代碼 代碼如下:
(function () {
// ... all vars and functions are in this scope only
// still maintains access to all globals
}());
注意這對包裹匿名函數的最外層括弧。因為Javascript的語言特性，這對括弧是必須的。在js中由關鍵詞function開頭的語句總是會被認為是函數聲明式。把這段代碼包裹在括弧中就可以讓解釋器知道這是個函數表達式。
全局變數導入
Javascript有一個特性叫做隱式全局變數。無論一個變數名在哪兒被用到了，解釋器會根據作用域鏈來反向找到這個變數的var聲明語句。如果沒有找到var聲明語句，那麼這個變數就會被視為全局變數。如果這個變數用在一句賦值語句中，同時這個變數又不存在時，就會創建出一個全局變數。這意味著在匿名閉包中使用或創建全局變數是很容易的。不幸的是，這會導致寫出的代碼極難維護，因為對於人的直觀感受來說，一眼根本分不清那些是全局的變數。
幸運的是，我們的匿名函數提供了簡單的變通方法。只要將全局變數作為參數傳遞到我們的匿名函數中，就可以得到比隱式全局變數更清晰又快速的代碼了。下面是示例：
復制代碼 代碼如下:
(function ($, YAHOO) {
// now have access to globals jQuery (as $) and YAHOO in this code
}(jQuery, YAHOO));
模塊導出
有時你不僅想要使用全局變數，你還想要聲明它們，以供反復使用。我們可以很容易地通過導出它們來做到這一點——通過匿名函數的返回值。這樣做將會完成一個基本的模塊化模式雛形，接下來會是一個完整的例子：
復制代碼 代碼如下:
var MODULE = (function () {
var my = {},
privateVariable = 1;
function privateMethod() {
// ...
}
my.moleProperty = 1;
my.moleMethod = function () {
// ...
};
return my;
}());
注意我們已經聲明了一個叫做MODULE的全局模塊，它擁有2個公有的屬性：一個叫做MODULE.moleMethod的方法和一個叫做MODULE.moleProperty的變數。另外，它還維護了一個利用匿名函數閉包的、私有的內置狀態。同時，我們可以很容易地導入需要的全局變數，並像之前我們所學到的那樣來使用這個模塊化模式。
進階模式
上面一節所描述的基礎已經足以應對許多情況，現在我們可以將這個模塊化模式進一步的發展，創建更多強大的、可擴展的結構。讓我們從MODULE模塊開始，一一介紹這些進階模式。
放大模式
整個模塊必須在一個文件中是模塊化模式的一個限制。任何一個參與大型項目的人都會明白將js拆分多個文件的價值。幸運的是，我們擁有一個很棒的實現來放大模塊。首先，我們導入一個模塊，並為它添加屬性，最後再導出它。下面是一個例子——從原本的MODULE中放大它：
復制代碼 代碼如下:
var MODULE = (function (my) {
my.anotherMethod = function () {
// added method...
};
return my;
}(MODULE));
我們用var關鍵詞來保證一致性，雖然它在此處不是必須的。在這段代碼執行完之後，我們的模塊就已經擁有了一個新的、叫做MODULE.anotherMethod的公有方法。這個放大文件也會維護它自己的私有內置狀態和導入的對象。
寬放大模式
我們的上面例子需要我們的初始化模塊最先被執行，然後放大模塊才能執行，當然有時這可能也不一定是必需的。Javascript應用可以做到的、用來提升性能的、最棒的事之一就是非同步執行腳本。我們可以創建靈活的多部分模塊並通過寬放大模式使它們可以以任意順序載入。每一個文件都需要按下面的結構組織：
復制代碼 代碼如下:
var MODULE = (function (my) {
// add capabilities...
return my;
}(MODULE || {}));
在這個模式中，var表達式使必需的。注意如果MODULE還未初始化過，這句導入語句會創建MODULE。這意味著你可以用一個像LABjs的工具來並行載入你所有的模塊文件，而不會被阻塞。
緊放大模式
寬放大模式非常不錯，但它也會給你的模塊帶來一些限制。最重要的是，你不能安全地覆蓋模塊的屬性。你也無法在初始化的時候，使用其他文件中的屬性（但你可以在運行的時候用）。緊放大模式包含了一個載入的順序序列，並且允許覆蓋屬性。這兒是一個簡單的例子（放大我們的原始MODULE）：
復制代碼 代碼如下:
var MODULE = (function (my) {
var old_moleMethod = my.moleMethod;
my.moleMethod = function () {
// method override, has access to old through old_moleMethod...
};
return my;
}(MODULE));
我們在上面的例子中覆蓋了MODULE.moleMethod的實現，但在需要的時候，可以維護一個對原來方法的引用。
克隆與繼承
復制代碼 代碼如下:
var MODULE_TWO = (function (old) {
var my = {},
key;
for (key in old) {
if (old.hasOwnProperty(key)) {
my[key] = old[key];
}
}
var super_moleMethod = old.moleMethod;
my.moleMethod = function () {
// override method on the clone, access to super through super_moleMethod
};
return my;
}(MODULE));
這個模式可能是最缺乏靈活性的一種選擇了。它確實使得代碼顯得很整潔，但那是用靈活性的代價換來的。正如我上面寫的這段代碼，如果某個屬性是對象或者函數，它將不會被復制，而是會成為這個對象或函數的第二個引用。修改了其中的某一個就會同時修改另一個（譯者註：因為它們根本就是一個啊！）。這可以通過遞歸克隆過程來解決這個對象克隆問題，但函數克隆可能無法解決，也許用eval可以解決吧。因此，我在這篇文章中講述這個方法僅僅是考慮到文章的完整性。
跨文件私有變數
把一個模塊分到多個文件中有一個重大的限制：每一個文件都維護了各自的私有變數，並且無法訪問到其他文件的私有變數。但這個問題是可以解決的。這里有一個維護跨文件私有變數的、寬放大模塊的例子：
復制代碼 代碼如下:
var MODULE = (function (my) {
var _private = my._private = my._private || {},
_seal = my._seal = my._seal || function () {
delete my._private;
delete my._seal;
delete my._unseal;
},
_unseal = my._unseal = my._unseal || function () {
my._private = _private;
my._seal = _seal;
my._unseal = _unseal;
};
// permanent access to _private, _seal, and _unseal
return my;
}(MODULE || {}));
所有文件可以在它們各自的_private變數上設置屬性，並且它理解可以被其他文件訪問。一旦這個模塊載入完成，應用程序可以調用MODULE._seal()來防止外部對內部_private的調用。如果這個模塊需要被重新放大，在任何一個文件中的內部方法可以在載入新的文件前調用_unseal()，並在新文件執行好以後再次調用_seal()。我如今在工作中使用這種模式，而且我在其他地方還沒有見過這種方法。我覺得這是一種非常有用的模式，很值得就這個模式本身寫一篇文章。
子模塊
我們的最後一種進階模式是顯而易見最簡單的。創建子模塊有許多優秀的實例。這就像是創建一般的模塊一樣：
復制代碼 代碼如下:
MODULE.sub = (function () {
var my = {};
// ...
return my;
}());
雖然這看上去很簡單，但我覺得還是值得在這里提一提。子模塊擁有一切一般模塊的進階優勢，包括了放大模式和私有化狀態。
F. JS代碼自動規范
JS格式化，網上有很多在線的JS格式化，http://tool.chinaz.com/Tools/JsFormat.aspx
G. 這樣寫JAVAscript代碼規范嗎
function su(b); function就是函數頭 su就是函數名 b是個形參，主要還是匹配函數名，再看參數個數是否相等，如果都一樣的話就可以調用函數了。
這個b是形參，只是代表有一個數值要傳進去而已，取什麼名字都可以。
su(num)表示的就是把num這個數值傳入到su函數中去執行b+5 也就是num+5；
box(num)就是傳入box函數中執行su(num)+num;
題主把6代入的時候 整個函數執行就是這樣的：
function box(6){
return su(6)+6;
}
function su(6){
return 6+5;
}
var result=box(6)
alert(result); //結果返回的也就是17了
H. 關於JS代碼書寫規范問題，我是JS初學者
這個是個人習慣問題，不過如果進一個正規的公司，對這個還是有要求的，所以需要從現在培養書寫習慣，例如=號等等運算符，左右都需要加上空格，這樣代碼看起來更工整，也更清晰，至於大括弧是獨佔一行，還是寫在前一句的最後（如果寫在上一句的最後，也需要和前面加一個空格），這根據不同的項目有不同的要求，如果你看一些網上比較知名的開源項目，有些裡面大括弧獨佔一行，有些則是在前一句的最後，但不管哪種方式，在同一個項目中必須得保證使用同一種標准。
初學者寫代碼也就自己看看，不會在意，可以後工作了是大家維護代碼，所以必須保證工整清晰以及整體的一致，所以得從一開始培養書寫習慣。
I. js里有幾種編碼規范
什麼是編碼規范
編碼規范就是指導如何編寫和組織代碼的一系列標准。通過閱讀這些編碼規范，你可以知道在各個公司里代碼是如何編寫的。
我們為什麼需要編碼規范
一個主要的原因是：每個人寫代碼的方式都是不同的。我可能喜歡這么寫，而你喜歡用另一種方法寫。如果我們只處理自己的代碼，這樣並沒有什麼問題。但如果有成千上萬的程序員同時在一個代碼庫上面工作呢？如果沒有規范，事情很快會變得一團糟。代碼規范可以讓新人迅速的熟悉相關的代碼，並且也能寫出讓其他程序員簡單易懂的代碼。
Airbnb JavaScript Style Guide
號稱是「最合理的編寫 JavaScript 代碼的方式」。
Airbnb 的這個代碼規范可能是互聯網最流行的 JavaScript 代碼規范了，它在 Github 上足有 6 萬 star，幾乎覆蓋了 JavaScript 的每一項特性。
Google JavaScript Style Guide
只有遵守了這里的規則，一個 JavaScript 源文件才能被稱為「Google Style」。很霸氣，我行我素，同時也被不少公司沿用。
Idiomatic JavaScript Style Guide
符合語言習慣的 JavaScript 代碼規范。
不管有多少人參與，不管是否在同一個代碼庫，所有的 JavaScript 代碼風格都必須像同一個人寫的。
另一個很強勢的同時也很流行的 JavaScript 編碼規范。它的野心也很大，不止想規范 JavaScript，其它語言也都想管起來。
地球上所有的代碼都像同一個人寫的？想想讓人覺得不寒而慄啊……
JavaScript Standard Style Guide
一個功能強大的 JavaScript 代碼規范，自帶 linter 和自動代碼糾正，無需配置，自動格式化代碼。可以在編碼早期就發現代碼中的低級錯誤。這個代碼規范被很多知名公司所採用，比如 NPM、GitHub、mongoDB 等。
（這個 Github 地址霸氣到不行。）
jQuery JavaScript Style Guide
jQuery 是多少人入門前端的好幫手啊，可惜如今只剩回憶了。它們的這個規范算是很早期的一個代碼規范了，主要是針對它們的代碼以及早期 JavaScript 版本進行規定。
總結
以上所述是小編給大家介紹的5 種JavaScript編碼規范，希望對大家有所幫助，如果大家有任何疑問請給我留言，小編會及時回復大家的。在此也非常感謝大家對腳本之家網站的支持！
J. 什麼是web前端開發標准
其實web前端是一個新詞彙，剛開始的時候只有美工和程序，後來隨著web的發展，對用專戶交互的需求越來越高，就衍屬生出了ui（用戶交互頁面）這除了視覺效果還要有交互體驗，就需要js去實現，畢竟一個人的精力是有限的，這么多的工作不可能由一個人去實現，於是出圖就成了前端美工，切圖出html css就成了前端切圖，js就成了前端交互。一般情況下出圖和html頁面是一個人完成，而js效果由程序員去寫，因為畢竟都是程序腳本，程序員學起來相對容易一些。