為什麼要規範編碼，我相信這是每個程式設計師都曾經思考過的問題，每個人都應該有每個人的答案，在這兒我只是想談一下我個人的感受，希望對剛入行的朋友能有所幫助。至於大神神馬的，可以略過~~~~~
要討論這個問題，我們首先得說點其他的。我們來假設乙個場景：相信每個朋友最開始都有這種感受：哇，今天狀態超好，簡直是文若鉛華，絲若泉湧。敲起鍵盤來簡直感覺不要太順暢。隨著一連串的編寫，可能寫完抬頭一看一上午或者一下午就過去了。要麼是飯點，要麼就該要下班了。在想一想自己今天的狀態，那感覺不要太好。然後高高興興就回家或者吃飯去了。之前的事情告一段落。。。。。。。然後時間慢慢過去.....
3個月後，專案經理在團隊裡面問道，之前的這個專案是誰負責的來著，然後順利的找到你，現在客戶有一些新的需求，既然之前是你寫的，那麼你來改一下吧。。。
那麼此時的你改怎麼辦呢，如果這是乙個小專案，只有幾千行原始碼，也許你會覺得重寫一遍遠比去理解當初的意思來的更快，然而，如果這是乙個大專案呢，涉及的**量可能有幾萬行的時候怎麼辦？毫無辦法，只能一步一步去嘗試理解，然後重新新增注釋，你會發現這需要花的時間成本太高了 ，長時間的加班就顯得不可避免，還會給領導落下個工作效率低下的映像。這都不是你所想要看到的結果。
在前不久，我們團隊接到乙個專案，粗略的看了一下，原始碼大概在1.3w+的樣子，
簡單的通過公司的質量檢測工具做了份質量評估報告：
api注釋率35%；
**注釋覆蓋率10%；
不符合編碼規範問題1w+；
存在嚴重阻斷100+；
拿到這個質量檢測報告我的內心是崩潰的，這等於這專案的原始碼基本是看不了的。嘗試去閱讀理解然後對其進行維護的可能性基本等於零。
這使得我們不得不思考重寫整個專案的可能性，在用了大半個月的時間做可行性分析（包括原維護部門的人員交流，原開發部門的文件補全，測試部門的測試用例。。等等）之後，我們得到了可以重寫的結論。接下來就是對新環境的搭建，新測試用例的搬遷，新單元原始碼的重寫。。。。為此又付出的4個月左右的時間。前前後後加起來就是小半年。而這些時間本身是有必要付出的嗎？答案當然是否定的。
通過以上的假設與實際例子我們不難看出，規範的編碼書寫習慣是乙個程式設計師自我修養的必要素質。也許在我們一開始的時候會覺得這些條條框框是那麼的煩人，以及沒有作用。但這是經過時間推敲的，是前人為我們總結下來的寶貴經驗，而且一旦你養成了良好的書寫習慣你會發現，看著有規範的**是一件多麼讓人賞心悅目的事情~！（ps：如果你書寫的**都是高質量的**，那麼你離漲工資就不遠了哦~~~~）
這篇文章主要是想跟剛入行的朋友們分享一下，在這個你原本可以以肆意書寫的世界，為什麼要制定那麼多的條條框框來束縛你的編碼。也是希望能警醒自己在編碼的過程中能始終如一的追求編碼的質量。而不是僅靠數量的堆疊。
歡迎更有感觸的朋友留下自己的心得分享吧~
一些編碼規範
先判斷是否為空list null list.size 0提示條件裡不要有感嘆號！客戶很反感。字串加trim 判斷。去掉前邊的空格。儘量減少對變數的重複計算 明確乙個概念，對方法的呼叫，即使方法中只有一句語句，也是有消耗的，包括建立棧幀 呼叫方法時保護現場 呼叫方法完畢時恢復現場等。所以例如下面的操作...
關於Web Worker的一些心得
現在在平台中線程js中不能識別extjs的方法，原因是執行緒js無法引入extjsd的方法。onmessage只接收資料，不能在裡面直接寫方法，只能呼叫外面的方法 webwork.js無法訪問window,docment等物件 案例 建立乙個執行緒 varworker newworker test ...
一些關於BFC的心得
bfc的概念 什麼是bfc？bfc 塊級格式化上下文是前端頁面的視覺化css渲染的一部分，是布局過程中生成塊級盒子的區域，也是浮動元素與其他元素的互動限定區域。在bfc中，盒子從頂端開始垂直的乙個接乙個的排列，兩個盒子之間的垂直的間隔是由他們的margin值決定的，在乙個bfc中，兩個相鄰的塊級盒子...