首页手记前端菜鸟的开发之路--前端开发技巧

前端菜鸟的开发之路--前端开发技巧

标签：

JavaScript Vue.js

> 前面的文章也提到了，我本身就是做android的，外加上刚开始做android的时候。学长对我的代码风格有很大的限制。所以我在学习最新的语言的时候，首先会想到的是代码的格式化。虽然说vue-cli里面自带有eslint插件，但是其实在开发的时候会遇到很多自己不太习惯的操作，比如分号等行为会被他们标记为警告。虽然不会影响运行，但是或多或少都会对你接下来的操作产生偏差。这次首先从eslint关闭对某些检查的警告开始写起，逐渐深入讲到，我自己对某些代码格式化的一些理解。话不多说直接开始搞。

正如前文所说，代码的风格是一个很麻烦的事儿，但是一旦养成了一种习惯却又能给自己今后的发展有着很大的裨益。以前在刚开始做Android开发的时候，根本就不会注意到这种东西，然后命名也是从a到z，从1-n的这种。但是写着写着发现自己都没办法看懂前面写的代码的意思了。更不必去谈及协作开发了。所以在这种“危急存亡”之际，我忍着很大的痛苦，去学习了一套基本的代码格式化风格。
去年吧，看到了阿里巴巴发布了java开发手册，前几天又发布了android开发手册。这就已经充分说明代码风格对于一个程序开发的影响。
这次搭建前端网站呢？我是作为一个架构师（自封），可能我的一种不恰当的写法可能会引起现今乃至以后成员对编写前端的代码风格产生影响。于是我便在网上找了一本名为编写可维护的JavaScript。结合以前自己开发android的一些经验，不对应该是完善之前的一些开发习惯。弄出了一套规范。
本次文章呢？主要是从eslint入手,结合书本和自己经验希望给处于同阶段的朋友一起探讨的机会。如果在开发中存在任何不明白或者是不认同的，请联系我，我会看到后及时回复您。谢谢支持

一、关于如何取消eslint警告

标题也提到了，我是一个android开发工程师。对于前端我现在就像小学生一样。好了，打开vue，在进行安装的时候发现，vue-cli自带有代码检查器，二话不说立马就装上了。如下图，输入y就开发使用eslint插件了。

但是刚装上所谓的eslint，写了一行代码
this.$router.push({name: 'main'});
立马就给出警告
当时有种想放弃的感觉，因为自己写Android这么多年，先入为主的观点认为，每一句话的结尾都要以；结尾，但是在js上面不行。我回忆了一下当初学js的时候，；是可以的。于是我就打开了他的官方文档，仔细研究了一番，发现eslint会在项目中生成一个.eslintrc.js文件，而里面的rules节点就会省略一些不需要的检查，几经纠缠终于成功了。

当然很多写python的小伙伴可能也不太熟悉；，这只是我个人的习惯。如果eslint产生了和你以往编写代码的习惯相违背的话。你也可以重新去定义一些规则去避免这些东西。纯属个人习惯而已。

二、关于自己对前端的一些格式化风格整理

说实话，前端大佬千千万，我又只是一个初出茅庐的小伙儿。写这个东西可能有些逾越了。但是谁知道我以后会不会成为千千万的大佬中的一员呢？万丈高楼平地起。只有打好了基础，后来才会存在万丈高楼。不然楼即使建的再高也没用。如果您觉得这个有用给个关注，如果有疑问、异议请私聊我；如果认为我写的东西不入您的法眼，那就当看了一个乐子。

缩进：因为每个编译器的tab键位置不同。所以我建议，再协作开发的时候，尽量都使用两个空格(ide tab默认等于两个空格)

refreshVideo () {
this.showImg = true
setTimeout(function () {
that.showImg = false
}, 1000)
}
行宽：以前在做java 的时候，我记得行宽不超过100，所以在前端我依然延续着java的风格在一个屏幕内显示不下的时候在运算符后转行，次行增加两个缩进

doSometing (arg1, arg2, arg3,
arg4);
字符串： js支持单引号和双引号，但是java写习惯了，在公司同步在开发android项目，所以我还是习惯用双引号来赋值(tip:eslint需要增加双引号的规则)

var s = "Klivitam";
原始值：
1、数字应当使用十进制、科学计数法、十六进制表示整数。尽量不要使用八进制。
2、 null 值除了初始变量赋值、与已初始变量比较、函数传入参数和函数返回值的空判断外避免使用。
3、避免使用undefined，要判断是否未定义用typeof操作符
间距：我的做法和java写法一样，运算符前后各自加一个空格；括号外前后加空格，括号内不加.。（jq是括号内也加，不习惯）

for (int i = 0; i <= 5; i++) {
// dosometings...
}
常量：常量都采用大写加上下划线组成。尽量不要在代码中出现魔法值

const COUNT_MAX = 1000;
不推荐使用new的方式去创建对象。我在创建对象的时候习惯把括号和表达式放在一行，第一行行末是全部括号的开始，然后结束括号再另外占有一行。括号内每个遇到“，”就换行的思路。

var pages = [{
'page1',
'page2'
}]
注释：注释是一个很麻烦的问题，有时候觉得要注释很啰嗦，觉得代码很简单一看就懂。但是我最近一段时间可能处于多线开发。可能今天写Android明天就回来重新开发vue，思维跨度很大，重新理解可能花费很多时间，外加上现在两个项目都有人协作开发，自己觉得懂，但是别人不懂就很尴尬了。一般我写注释都参照着编写可维护的JavaScript建议来写的。

1、代码晦涩难懂
2、可能被人误解的代码
3、优化他人的代码和复用性高的代码
4、多浏览器适配代码
以上是我认为可能会用到注释的地方。但是具体注释的一些规则，我这里并没有谈及到。周所周知，注释分为单行注释和多行注释。就拿单行注释来说，我认为单行注释一般就用来解释一下变量的作用和某些操作的具体含义。而多行测试则是用来解释某个函数或者是某个文件的含义。而具体的格式。单行测试就应该单独占用一行，并且只占用一行，并且解释和“//”指间应该存在有一个空格的间距

// decided...
而多行注释，如果是文件，就应该包含新建者、新建时间以及文件的作用；如果是函数则包含纯如参数的含义，返回值的含义。另外“*”与注释之间也应该有一个空格做间隔。

/*
- item: xxx,index: xxx
- return: xxx
  */
  function (item, index) {
  retrun true;
  }
  最后也要说一下我以前在做Android就经常用到的一些申明（好多我都不知道学习学习）
  1. TODO: 代码还没有完成。包含下面要做的事情
  2. HACK：实现代码走了一个捷径，也可以表示可能有更好的解决方法
  3. XXX：说明有问题，希望能尽快解决问题
  4. FIXME：和上面一样，但是重要性稍微低一点
  5. REVIEW：说明代码任何可能的改动都需要评审
命名：关于命名呢，我依然延续着做Android的一些方式--驼峰命名法。无论是函数命名和变量命名，一般都是除了第一个单词的首字母是小写外，其他单词的首字母统统大写。但是变量命名的时候，我一般会将首字母设置为名词，函数则会将首字母变为动词来避免混淆。具体的命名尝试我建议您去下载阿里巴巴的android开发手册。我在这里就只是简单的抛砖引玉，小做介绍了。
相等使用 “===”，不等使用“！==”，这样可以避免转换出现潜在的风险

// 返回为true
console.log(true == 1)
// 返回为false
console.log(true === 1)
如果有兴趣可以去研究一下这两段代码。所以在判断的时候尽量使用三元操作符。（这和android就不一样了）
html，css，js尽可能相互独立。如果三者之间耦合度越高，则维护成本和可读性、调试的困难性很高。
尽可能避免使用全局变量
关于条件语句的层级，我个人建议是最多三层。高于三层你就得想一下你自己的代码逻辑了。
```
 if (xxx) {
  if (xxx) {
    // 里面就尽量不要再进行条件语句了
  }
 }
```
如果这样依次if下去，复杂度很高，你所使用的代码性能会很低。当然都只是个人观点。
至于try catch的使用呢。我个人是持有保留态度的，我很支持知乎上面一位朋友的评论。try catch是对那些对自己代码没自信的人才使用的。如果你对自己的代码足够自信，根本就不用使用try catch。但例如Android（为什么举例Android呢？因为前端涉事不深= =）里面的流操作，自带try catch方法除外。就我个人观点，尽量在代码中少用，实在避免不了再使用。

写了这么多，其实也不怎么写的下去了，第一是已经凌晨了，第二就是电脑的电量不怎么多了。我写了这么多，第一是将我最近在寝室研究的一些成果迫不及待的展示给每一个看客。可能与诸位的一些习惯不一样，也可能存在有某些我自己没发现的顽疾，正如开头写的一样，如果有疑虑、建议请您及时反馈给我。我一旦看到会第一时间反馈给您。好了，今天就到这里了，如果在以后我有更加完善的代码风格，我会会及时的补充的。拜拜了，洗澡去了 orz...

点击查看更多内容