熱點推薦:
您现在的位置: 電腦知識網 >> 編程 >> Java編程 >> JSP教程 >> 正文

JavaScript腳本編寫規范

2022-06-13   來源: JSP教程 

  對於熟悉 C/C++ 或 Java 語言的工程師來說JavaScript 顯得靈活簡單易懂對代碼的格式的要求也相對松散很容易學習並運用到自己的代碼中也正因為這樣JavaScript 的編碼規范也往往被輕視開發過程中修修補補最終也就演變成為後續維護人員的惡夢軟件存在的長期價值直接與編碼的質量成比例編碼規范能幫助我們降低編程中不必要的麻煩而 JavaScript 代碼是直接發送給客戶浏覽器的直接與客戶見面編碼的質量更應該受到關注 

本文淺談 JavaScript 編程中關於編碼規范的問題分析其中緣由希望引起更多 Web 開發人員對 JavaScript 編碼規范問題的關注和對軟件產品質量問題的重視 

前言 

提及 C/C++ 和 Java 編碼規范相信許多工程師並不生疏但說到 JavaScript 語言的編碼規范也許您會忍俊不禁JavaScript 不是語法很靈活嗎?變量隨時用隨時可以聲明語句結束符可以不要字符串和數字也可以相加參數多一個少一個也不會報錯沒錯當您從 C/C++ 和 Java 嚴格的語法規定之下轉向 JavaScript 語言會覺得自由了很多輕松了很多語法松散是 JavaScript 重要的特征它靈活易懂給開發人員帶來了很多方便但如果編寫過程中不注意代碼的調試成本和維護成本則會無形地增加 

JavaScript 編碼會隨應被直接發送到客戶端的浏覽器代碼規范不只是代碼質量的保證也影響到產品的長期信譽希望 JavaScript 編程語言的規范問題也能同樣引起更多朋友的關注 

JavaScript 編碼規范建議 

本文就 JavaScript 編碼過程中涉及的排版命名聲明作用域及一些特殊符號的使用等方面根據個人在學習工作中的總結給出自己的一些建議並分析其中緣由以供參考 

JavaScript 文件引用 

JavaScript 程序應該盡量放在 js 的文件中需要調用的時候在 HTML 中以 <script src="filenamejs"> 的形式包含進來JavaScript 代碼若不是該 HTML 文件所專用的則應盡量避免在 HTML 文件中直接編寫 JavaScript 代碼因為這樣會大大增加 HTML 文件的大小無益於代碼的壓縮和緩存的使用 

另外<script src="filenamejs"> 標簽應盡量放在文件的後面這樣會降低因加載 JavaScript 代碼而影響頁面中其它組件的加載時間 

代碼排版 

行長度 

每行代碼應小於  個字符如果代碼較長應盡量選擇換行下一行代碼應縮進  個空格這樣可以使代碼排版整齊減輕閱讀代碼的疲勞感換行縮進  個空格可以和代碼段的縮進  個空格區分開以增強代碼的可閱讀性 

行結束 

JavaScript 語句應該以分號結束但大多數浏覽器允許不寫分號只要在本應是分號的地方有一個換行符就行但是如果代碼行較長需要換行的時候有哪些注意事項呢?換行應選擇在操作符和標點符號之後最好是在逗號’’之後而不要在變量名字符串數字或’)’ ’]’ ’++’ ’’等符號之後換行 

這樣可以有效的防止拷貝粘貼而引起的錯誤並可有效地增強代碼的可閱讀性請見清單 代碼的輸出符合我們的期望但就寫法而言對 valueB 的賦值語句是在變量 valueA 之後進行的換行這很容易被誤解為 valueB=ValueA給閱讀造成障礙而對 valueC 的復制語句是在’+’之後進行的換行就容易理解的多這也是本文所提倡的換行方式 

清單  行結束的位置 

縮進 

關於縮進的問題不只是 JavaScript幾乎所有的語言編寫的時候都會提及縮進的問題縮進幾乎是代碼編寫規范的第一課是代碼可閱讀性判斷的直接因素 

代碼縮進的好處是不言而喻的但是對於如何縮進則沒有標准而言最受歡迎的是方便使用 TAB 鍵縮進也有些喜歡用  個 個 個空格進行縮進這樣縮進風格不一也同樣給代碼的閱讀帶來障礙 

本文提倡用  個空格來進行縮進並在同一產品中采用同一種縮進標准不支持用 TAB 鍵進行縮進這是因為直到現在還沒有統一的標准來定義 TAB 鍵所代替的空白大小有些編輯器解析為  個空格大小有些則解析為  個因而用不同的編輯器查看代碼可能造成格式混亂 

當然 TAB 簡單易用為解決這個問題建議在設置開發環境時將編輯器裡的 TAB 快捷鍵重新設置為  個空格據了解 Eclipse Vi Nodepad++Editplus UltraEdit 等流行的編輯器均提供了此功能

  

  注釋

  代碼中的注釋很重要自然也是毋庸置疑的通常我們會強調代碼中注釋數量的多少而輕視了對注釋質量的提高編碼是及時添加注釋會給後續代碼的維護人員帶來很大的便利但是如果注釋不注意更新或者由於拷貝粘貼引起的錯誤的注釋則會誤導閱讀人員反而給閱讀帶來障礙

  除了注釋要 及時更新外我們還應對注釋的內容要特別關注注釋要盡量簡單清晰明了避免使用含混晦澀的語言同時著重 注釋的意義對不太直觀的部分進行注解請見清單

  清單 有意義的注釋

  這樣的注釋方式在 JavaScript 代碼中經常見到"initialize valueA to be sero" 這樣的注釋有什麼用呢?難道閱讀程序的工程師從"var valueA = ;"復制語句中看不出來麼?"set timeout to be s"這條注釋不只是因拷貝粘貼引起的時間大小的錯誤同時也誤導了程序員對這條語句的理解setTimeout() 函數的作用並非是設置函數執行的超時時間而是等待一定時間後執行所調用的函數害人匪淺呀這樣的注釋內容寧可刪掉

  此外JavaScript 的注釋有兩種"//" 和"/* */"建議"//"用作代碼行注釋"/* */"形式用作對整個代碼段的注銷或較正式的聲明中如函數參數功能文件功能等的描述中

  標識符命名

  JavaScript 中的標識符的命名規則

  • 以字母下劃線_或美元符號$開頭
  • 允許名稱中包含字母數字下劃線_和美元符號$
  • 區分大小寫

  變量參數成員變量函數等名稱均以小寫字母開頭構造器的名稱以大寫字母開頭下劃線_開頭的變量一般習慣於標識私有 / 局部成員而美元符號$開頭的變量習慣於標識系統相關比如系統進程等應避免用下劃線_或美元符號$來命名標識符盡可能地降低代碼的閱讀負擔

  聲明

  變量的聲明

  盡管 JavaScript 語言並不要求在變量使用前先對變量進行聲明但我們還是應該養成這個好習慣這樣可以比較容易的檢測出那些未經聲明的變量避免其變為隱藏的全局變量造成隱患

  在函數的開始應先用 var 關鍵字聲明函數中要使用的局部變量注釋變量的功能及代表的含義且應以字母順序排序每個變量單獨占一行以便添加注釋這是因為 JavaScript 中只有函數的 {} 表明作用域用 var 關鍵字聲明的局部變量只在函數內有效而未經 var 聲明的變量則被視為全局變量我們來看下清單

  清單 局部變量聲明

  從上例的輸出驚奇地發現用 var 聲明過的變量 valueA 和沒有聲明的變量 valueB 是有區別的特別需要注意的是在函數內部用 var 聲明的變量為局部變量這樣可以有效地避免因局部變量和全局變量同名而產生的錯誤

  函數的聲明

  函數也應在調用前進行聲明內部函數應在 var 聲明內部變量的語句之後聲明可以清晰地表明內部變量和內部函數的作用域

  此外函數名緊接左括號(之間而右括號)和後面的{之間要有個空格以清楚地顯示函數名以其參數部分和函數體的開始若函數為匿名 / 無名函數則 function 關鍵字和左括號(之間要留空格否則可能誤認為該函數的函數名為 function

  清單  內部函數聲明 

<script language="javascript">  
 var innerA = ;  
 function outF() {  
   var innerA = ;  
   function _inF() {  
       alert("valueA="+innerA);  
   }  
   _inF();  
 }  
 outF();                         //output: valueA=  
 _inF();                         //error: innerF is not defined  
 </script>   

  從清單  的輸出可以看出inF() 函數僅在 outF() 函數的內部生效局部變量 innerA 對內部函數的作用域生效這樣的編碼方式使得變量和函數的作用域變得清晰 

語句 

對於簡單語句而言需要提及的仍然是分號必要性同時一行最多有一個語句如果一個賦值語句是用函數和對象來賦值可能需要跨多行一定切記要在賦值語句末加上分號 

這是因為 JavaScript 中所有表達式都可以當語句遇換行符時會解析為表達式的結束此時不規范的換行和分號的丟失可能引入新的錯誤 

對於復合語句if for while do switch try … catch 等代碼體函數定義的函數體對象的定義等都需要放在花括號’{}’裡面 

’{’ 應在行末標志代碼塊的開始  
’}’ 應在一行開頭標志代碼塊的結束同時需要和’{’所在行的開始對齊以表明一個完整的復合語句段這樣可以極大地提高代碼的可閱讀性控制邏輯能清晰地表現出來  
被包含的代碼段應該再縮進  個空格  
即使被包含的代碼段只有一句也應該用花括號’{}’包含盡管不用花括號代碼也不會錯但如若需要增加語句的話則較容易因花括號遺漏而引起的編譯錯誤或邏輯錯誤  
return語句在使用時也需慎重如果用表達式的執行作為返回值請把表達式和 return 放在同一行中以免換行符被誤解析為語句的結束而引起返回錯誤return 關鍵字後若沒有返回表達式則返回 undefined構造器的默認返回值為 this 

清單  return 表達式 

在清單  中顯示了因返回表達式沒有和 return 關鍵字放在同一行而引起的返回錯誤需重視 

特殊符號 

空白符 

適當的空白行可以大大提高代碼的可閱讀性可以使代碼邏輯更清晰易懂同時在表達式中適當的留空白也會給代碼的閱讀帶來方便 

關鍵字的後面如有括號則最好在關鍵字和左括號’(’之間留空白如 for if while 等而函數名和括號之間則不宜留空白但若是匿名函數則必須在 function 和左括號’(’之間留空白否則編輯器會誤認為函數名為 function 

在表達式中二元運算符 ( 除左括號’(’左方括號’[’作用域點’’) 和兩個操作數之間最好留空白一元運算符(若不是詞 typeof 等)和其操作數之間不宜留空白 

逗號’’的後面需要留空白以顯示明確的參數間隔變量間隔等 

分號’;’之後通常表明表達語句的結束而應空行在 for 的條件語句中分號之後則應該留空白 

{ } 和 [ ] 

在 JavaScript 中如需定義空對象和空數組通常很自然地想到用 new Object() 和 new Array() 的方法其實花括號’{}’和方括號’[]’可以直接用來定義一個空對象和一個空數組這種書寫方法可以使代碼看起來簡單易懂 

== 和 === 

判斷"邏輯等"在代碼裡太平常的不過事情了但 JavaScript 與其他熟知的編程語言不同的是除了可以使用兩個等號’==’來作判斷以為還可以使用三個等號’===’來進行邏輯等判斷兩者的不同是’==’作邏輯等判斷時會先進行類型轉換後再進行比較’===’則不會因而’==’進行的判斷結果可能產生偏差’!=’與’!==’的區別亦是如此本文提倡盡量使用’===’來進行邏輯等的判斷用’!==’進行邏輯不等的判斷 

清單  === 的使用 

  <script language="javascript">  
 var valueA = "";  
 var valueB = ;  
 if ( valueA == valueB) {  
   alert("Equal");  
 }  
 else {  
   alert("Not equal")  
 }  
 //output: "Equal" 
 if ( valueA === valueB) {  
   alert("Equal");  
 }  
 else {  
   alert("Not equal")  
 }  
 //output: "Not equal" 
 </script>   

清單  中valueA 和 valueB 兩個變量的值顯然是不相等的起碼 valueA 是個字符串而 valueB 是一個數字但用’==’進行判斷是程序卻輸出相等的字樣這是因為編譯器對兩個變量進行比較時因為他們的類型不同而自動地將 valueB 轉換成字符串而後再和 valueA 進行比較的用’===’得到的判斷結果正和預期的結果相符 


加號’+’也同樣是程序員所熟知的操作符之一JavaScript 和其他編程語言不同的是在 JavaScript 中’+’除了表示數字值相加字符串相連接以外還可以作一元運算符用把字符串轉換為數字因而如果使用不當則可能與自增符’++’混淆而引起計算錯誤這一點在清單  中可以清楚地看出 

清單  巧用 + 號 

<script language="javascript">  
 var valueA = ;  
 var valueB = "";  
 alert( valueA + valueB);     //ouput:   
 alert( valueA + (+valueB)); //output:   
 alert( valueA + +valueB);    //output:  
 alert( valueA ++valueB);     //Compile error  
 </script>   

  總結 

本文就 JavaScript 代碼的排版命名聲明語句和一些特殊字符的使用等方面談了自己對 JavaScript 編程規范的建議此外還有許多方面需要深入了解研究如 with eval 語句和 this 對象的使用等等我們在認識其普遍性的同時也需要注意其特殊性在編寫代碼時多用心留意以創造更多更優質的程序代碼

  


From:http://tw.wingwit.com/Article/program/Java/JSP/201311/20238.html
    推薦文章
    Copyright © 2005-2022 電腦知識網 Computer Knowledge   All rights reserved.