?? 前面的文章也提到了，我本身就是做android的，外加上剛開始做android的時候。學長對我的代碼風格有很大的限制。所以我在學習最新的語言的時候，首先會想到的是代碼的格式化。雖然說vue-cli里面自帶有eslint插件，但是其實在開發(fā)的時候會遇到很多自己不太習慣的操作，比如分號等行為會被他們標記為警告。雖然不會影響運行，但是或多或少都會對你接下來的操作產(chǎn)生偏差。這次首先從eslint關(guān)閉對某些檢查的警告開始寫起，逐漸深入講到，我自己對某些代碼格式化的一些理解。話不多說 直接開始搞。

??正如前文所說，代碼的風格是一個很麻煩的事兒，但是一旦養(yǎng)成了一種習慣卻又能給自己今后的發(fā)展有著很大的裨益。以前在剛開始做Android開發(fā)的時候，根本就不會注意到這種東西，然后命名也是從a到z，從1-n的這種。但是寫著寫著發(fā)現(xiàn)自己都沒辦法看懂前面寫的代碼的意思了。更不必去談及協(xié)作開發(fā)了。所以在這種“危急存亡”之際，我忍著很大的痛苦，去學習了一套基本的代碼格式化風格。 ??去年吧，看到了阿里巴巴發(fā)布了java開發(fā)手冊，前幾天又發(fā)布了android開發(fā)手冊。這就已經(jīng)充分說明代碼風格對于一個程序開發(fā)的影響。 ??這次搭建前端網(wǎng)站呢？我是作為一個架構(gòu)師（自封），可能我的一種不恰當?shù)膶懛赡軙瓞F(xiàn)今乃至以后成員對編寫前端的代碼風格產(chǎn)生影響。于是我便在網(wǎng)上找了一本名為編寫可維護的JavaScript。結(jié)合以前自己開發(fā)android的一些經(jīng)驗，不對應該是完善之前的一些開發(fā)習慣。弄出了一套規(guī)范。 ??本次文章呢？主要是從eslint入手,結(jié)合書本和自己經(jīng)驗希望給處于同階段的朋友一起探討的機會。如果在開發(fā)中存在任何不明白或者是不認同的，請聯(lián)系我，我會看到后及時回復您。謝謝支持

一、關(guān)于如何取消eslint警告

??標題也提到了，我是一個android開發(fā)工程師。對于前端我現(xiàn)在就像小學生一樣。好了，打開vue，在進行安裝的時候發(fā)現(xiàn)，vue-cli自帶有代碼檢查器，二話不說立馬就裝上了。如下圖，輸入y就開發(fā)使用eslint插件了。

但是剛裝上所謂的eslint，寫了一行代碼

this.$router.push({name: 'main'}); 復制代碼

立馬就給出警告

當時有種想放棄的感覺，因為自己寫Android這么多年，先入為主的觀點認為，每一句話的結(jié)尾都要以；結(jié)尾，但是在js上面不行。我回憶了一下當初學js的時候，；是可以的。于是我就打開了他的官方文檔，仔細研究了一番，發(fā)現(xiàn)eslint會在項目中生成一個.eslintrc.js文件，而里面的rules節(jié)點就會省略一些不需要的檢查，幾經(jīng)糾纏終于成功了。 當然很多寫python的小伙伴可能也不太熟悉；，這只是我個人的習慣。如果eslint產(chǎn)生了和你以往編寫代碼的習慣相違背的話。你也可以重新去定義一些規(guī)則去避免這些東西。純屬個人習慣而已。 ####二、 關(guān)于自己對前端的一些格式化風格整理 ??說實話，前端大佬千千萬，我又只是一個初出茅廬的小伙兒。寫這個東西可能有些逾越了。但是誰知道我以后會不會成為千千萬的大佬中的一員呢？萬丈高樓平地起。只有打好了基礎(chǔ)，后來才會存在萬丈高樓。不然樓即使建的再高也沒用。如果您覺得這個有用給個關(guān)注，如果有疑問、異議請私聊我；如果認為我寫的東西不入您的法眼，那就當看了一個樂子。

• 縮進： 因為每個編譯器的tab鍵位置不同。所以我建議，再協(xié)作開發(fā)的時候，盡量都使用兩個空格(ide tab默認等于兩個空格)

  refreshVideo () {this.showImg = truesetTimeout(function () {that.showImg = false}, 1000)} 復制代碼

• 行寬： 以前在做java 的時候，我記得行寬不超過100，所以在前端我依然延續(xù)著java的風格在一個屏幕內(nèi)顯示不下的時候 在運算符后轉(zhuǎn)行，次行增加兩個縮進

  doSometing (arg1, arg2, arg3,arg4); 復制代碼

• 字符串： js支持單引號和雙引號，但是java寫習慣了，在公司同步在開發(fā)android項目，所以我還是習慣用雙引號來賦值(tip:eslint需要增加雙引號的規(guī)則)

  var s = "Klivitam"; 復制代碼

• 原始值： 1、 數(shù)字應當使用十進制、科學計數(shù)法、十六進制表示整數(shù)。盡量不要使用八進制。 2、 null 值除了初始變量賦值、與已初始變量比較、函數(shù)傳入?yún)?shù)和函數(shù)返回值的空判斷外避免使用。 3、 避免使用undefined，要判斷是否未定義用typeof操作符

• 間距：我的做法和java寫法一樣，運算符前后各自加一個空格；括號外前后加空格，括號內(nèi)不加.。（jq是括號內(nèi)也加，不習慣）

  for (int i = 0; i <= 5; i++) {// dosometings... } 復制代碼

• 常量： 常量都采用大寫加上下劃線組成。盡量不要在代碼中出現(xiàn)魔法值

  const COUNT_MAX = 1000; 復制代碼

• 不推薦使用new的方式去創(chuàng)建對象。我在創(chuàng)建對象的時候習慣把括號和表達式放在一行，第一行行末是全部括號的開始，然后結(jié)束括號再另外占有一行。括號內(nèi)每個遇到“，”就換行的思路。

  var pages = [{'page1','page2' }] 復制代碼

• 注釋：注釋是一個很麻煩的問題，有時候覺得要注釋很啰嗦，覺得代碼很簡單一看就懂。但是我最近一段時間可能處于多線開發(fā)。可能今天寫Android明天就回來重新開發(fā)vue，思維跨度很大，重新理解可能花費很多時間，外加上現(xiàn)在兩個項目都有人協(xié)作開發(fā)，自己覺得懂，但是別人不懂就很尷尬了。一般我寫注釋都參照著編寫可維護的JavaScript建議來寫的。

  1、 代碼晦澀難懂 2、 可能被人誤解的代碼 3、 優(yōu)化他人的代碼和復用性高的代碼 4、 多瀏覽器適配代碼 復制代碼

以上是我認為可能會用到注釋的地方。但是具體注釋的一些規(guī)則，我這里并沒有談及到。周所周知，注釋分為單行注釋和多行注釋。就拿單行注釋來說，我認為單行注釋一般就用來解釋一下變量的作用和某些操作的具體含義。而多行測試則是用來解釋某個函數(shù)或者是某個文件的含義。而具體的格式。單行測試就應該 單獨占用一行，并且只占用一行，并且解釋和“//”指間應該存在有一個空格的間距

// decided... 復制代碼

而多行注釋，如果是文件，就應該包含新建者、新建時間以及文件的作用；如果是函數(shù)則包含純?nèi)鐓?shù)的含義，返回值的含義。另外“*”與注釋之間也應該有一個空格做間隔。

/** item: xxx,index: xxx* return: xxx */function (item, index) {retrun true;} 復制代碼

最后也要說一下我以前在做Android就經(jīng)常用到的一些申明（好多我都不知道 學習學習） 1. TODO: 代碼還沒有完成。包含下面要做的事情 2. HACK：實現(xiàn)代碼走了一個捷徑，也可以表示可能有更好的解決方法 3. XXX： 說明有問題，希望能盡快解決問題 4. FIXME： 和上面一樣，但是重要性稍微低一點 5. REVIEW：說明代碼任何可能的改動都需要評審

• 命名：關(guān)于命名呢，我依然延續(xù)著做Android的一些方式--駝峰命名法。無論是函數(shù)命名和變量命名，一般都是除了第一個單詞的首字母是小寫外，其他單詞的首字母統(tǒng)統(tǒng)大寫。但是變量命名的時候，我一般會將首字母設(shè)置為名詞，函數(shù)則會將首字母變?yōu)閯釉~來避免混淆。具體的命名嘗試 我建議您去下載阿里巴巴的android開發(fā)手冊。我在這里就只是簡單的拋磚引玉，小做介紹了。

• 相等使用 “===”，不等使用“！==”，這樣可以避免轉(zhuǎn)換出現(xiàn)潛在的風險

  // 返回為true console.log(true == 1) // 返回為false console.log(true === 1) 復制代碼

  如果有興趣可以去研究一下這兩段代碼。所以在判斷的時候盡量使用三元操作符。（這和android就不一樣了）

• html，css，js盡可能相互獨立。如果三者之間耦合度越高，則維護成本和可讀性、調(diào)試的困難性很高。

• 盡可能避免使用全局變量

• 關(guān)于條件語句的層級，我個人建議是最多三層。高于三層你就得想一下你自己的代碼邏輯了。

  if (xxx) {if (xxx) {// 里面就盡量不要再進行條件語句了}} 復制代碼

如果這樣依次if下去，復雜度很高，你所使用的代碼性能會很低。當然都只是個人觀點。

• 至于try catch的使用呢。我個人是持有保留態(tài)度的，我很支持知乎上面一位朋友的評論。try catch是對那些對自己代碼沒自信的人才使用的。如果你對自己的代碼足夠自信，根本就不用使用try catch。但例如Android（為什么舉例Android呢？因為前端涉事不深= =）里面的流操作，自帶try catch方法除外。就我個人觀點，盡量在代碼中少用，實在避免不了再使用。

---

??寫了這么多，其實也不怎么寫的下去了，第一是已經(jīng)凌晨了，第二就是電腦的電量不怎么多了。我寫了這么多，第一是將我最近在寢室研究的一些成果迫不及待的展示給每一個看客。可能與諸位的一些習慣不一樣，也可能存在有某些我自己沒發(fā)現(xiàn)的頑疾，正如開頭寫的一樣，如果有疑慮、建議請您及時反饋給我。我一旦看到會第一時間反饋給您。好了，今天就到這里了，如果在以后我有更加完善的代碼風格，我會會及時的補充的。拜拜了，洗澡去了 orz...

轉(zhuǎn)載于:https://juejin.im/post/5cdd44cae51d45475b17e3b5

總結(jié)

以上是生活随笔為你收集整理的关于Android 工程师转成vue的三两事儿(2)--前端开发技巧的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。