良好的编码习惯

        最近的自己处于一种得过且过的状态中😔，说逃避的话就是总感觉是自己没有心思做任何事，只想混着，其实是自己不想走出这个舒适圈，去学习和历练，一味的敷衍了事，情绪也很疯。这样的后果是，渐渐地越来越掌控不了自己，工作一塌糊涂，被领导批评，心情也很糟糕😟。越是这种时候，越不能慌乱，一定不要在这个舒适圈中日复一日，仅满足于胜任当前这个工作，这几天感觉敷衍和安于现状感给我带来的是无尽的惶恐和不安，这样下去一直停留在原地必然会被淘汰。（只是对我自己这段时间感受的一个陈述，没有PUA😜）

        我喜欢别人那种思路整齐明了且优雅的代码，可我自己写的总是乱七八糟，七上八下😂，恰好在处于低谷的时候看到了一篇文章，觉得可以学习一下，不管什么，学习点让我逃离舒适圈就好。

今天要学习的主题是：良好的编码习惯

良好的编码习惯

---

1.变量和方法命名见名知意，使用小驼峰命名，避免使用下划线

//不推荐：
let a1 = 1;  // 坚决杜绝使用让人看了也不知道是啥的字母数字组合
const user_last_login_time = {}; // 不要使用下划线命名变量
list(){}; // 只写一个list

//推荐：
const userLastLoginTime = {}; // 小驼峰可读性更高
getUserList(){}; // 方法名最好使用动词+名词的组合

2.方法名定义推荐加上动词前缀 

⭐ 加载数据使用 load 前缀，例如: loaduserData 

⭐ 获取数据或值使用get 前缀，例如:getUserAvatar()
      ！！！ load与get的关系是load前缀的方法可以包含多个get前缀的方法，get不可以包含load前缀的方法，可以理解为要加载的数据由一或多个get前缀的方法来获取：例如

loadUserData(){
   this.getUserLocation();
   this.getUserInfo();
   ...
 }

⭐ 设置数据或值使用 set/update 前缀，例如:updateUserAvatar()

⭐ 格式化数据使用 format 前缀，例如:formatUserList()

⭐ 设置数据或值使用 set/update 前缀，例如:updateUserAvatar()

⭐ 判断某种条件使用 judge 前缀，例如: judgeCanshowModal()judgeIsvipuser();judgeHasRecord();

⭐ 监听事件或数据变化使用on 前缀，例如 onFilterChanged(); onSubmitsucces s ( ) ;

⭐ 点击事件使用 click/tap 前缀，例如 clickuserAvatar();

⭐ 跳转新页面使用 navTo 前缀，例如 navToDetailPage();

3.常量使用全大写，使用下划线连接单词

const PAGE_SIZE = 10;

4.命名风格全局要统一，有章可循，别这个文件这样，另一个文件又那样了

        不是非要一定按照上面的前缀来命名，只要你做到让人一眼看上去就知道这个方法是干嘛的，而且要有规律可循，你可以按自己的喜好来命名。

        你知道你的某个同事喜欢用 judge 前缀来命名具有判断相关逻辑的方法，那你看他代码时一看到 judge 开头的，不用看内容只看名你就大概知道是干嘛的了，节省下来的时间干别的不香么。

5.严格控制文件行数，最好保持在500行以下

        该拆分的拆分，文件行数过多，可维护性和可读性都很差，别说什么业务本身就很复杂，拆不出来只能说你代码组织能力差。

        拆分维度根据你的需求不同而不同，但是大体的思路可以是common通用方法、utils工具方法、gateway请求方法，presenter数据处理、models数据模型（TS）等，还可以根据你的业务逻辑来拆分，总之维度很多，重点是要拆的清晰，一定要避免拆的多而杂，那样还不如不拆。

6.严格控制代码重复率，不要图方便一味复制粘贴

        代码重复率是一个团队代码质量评测一个很重要的指标，显而易见重复代码会占用更多空间，并且会增加维护的困难度，修改你复用的重复代码时很容易漏掉，要耗费额外精力去验证，所以尽量拆出你的复用逻辑，别偷懒，别给自己留坑。

7.迭代时做好重构优化代码的准备

        不要为了一时轻松，写迭代需求时就一直在原代码基础上加加加，或者不敢动以前的代码，怕改出问题，如果迭代的新功能有更好的组织形式，多花一点时间去重构优化绝对是值得的，这将长久利于你后续的功能迭代效率，也会丰富你组织代码的经验，再有类似需求时你就可以预先使用更优的代码组织形式，后续产品想要迭代时你将游刃有余。

        以上建立在是自己的代码，你对自己的代码有足够的了解的情况下，再根据实际情况衡量收益，对后续迭代收益大的话，重构是有必要的。如果起初就没有设计好，导致维护的时候不能按理想的方式来，以后迭代都要受不合理代码的制约而一次次妥协的话，那难受的还是自己。

        当然，这个看个人，你不难受的话那你就可以不重构，但是不能保证看的人不难受，你有自己的认知程度，但不代表你的认知是对的，是好的，对自己的水平要有个充分且客观的认识，而且永远不要认为你负责一个业务这个业务的需求就永远都只给你做，首先公司是不希望一个业务只有一个人了解的，这个懂吧，没有你业务就崩掉这种事绝对不会允许发生，更别提你请个假啥的，所以你的代码总有机会被别人接触，别人对你技术水平的判断就会在这时开始形成。

8.写注释，随手写注释，刻在骨子里，像条件反射一样！

        不多说，你自己去看看不爱写注释的那位同事的代码，感受一下，你就明白为啥注释这么重要了，或者简单点，你就看你自己没写注释的代码，一个月前两个月前的，你还能完全捋清楚当时的思路不？

        方法最好都写注释，变量名等如果你觉得实习生都可以轻松看懂的部分可以不写。

9.方法、类、组件遵循职责单一原则

内部所做的事情要与名字契合，不要额外写无关的逻辑

10.方法、组件需要的数据不要耦合依赖全局数据或一些并不是为你的需求准备的其他外部变量

• 你的方法和组件数据依赖的变量，会不会受别人改动而被影响，如果别人也在用这个变量不小心改了是不是你的就崩了

• 反之如果别人想用你的组件，那就得改这个变量，改了就可能搞坏别的，他也不知道这个变量还有哪个鬼在用，那干脆不用组件了，自己写吧

• 再比如，你通过某种奇怪的方式将别人的某个文件或组件里的变量拿来用，那他不会保证哪天不把这些代码删掉或改掉，然后你线上挂掉了，你可怪不到人家头上，即使你用的是自己其他需求里的变量，万一产品哪天说那个功能下线了，你咋搞？

 11.使用ES6+语法，简化代码，提高效率

        JavaScript语言本身也有一些令人不满意的地方，如变量提升，回调地狱等，ES6+主要是为了解决ES5的先天不足。

12.列表渲染和条件渲染写在标签的第一个属性

// Vue
<div v-if="show" id="" class="">div>
<div v-else id="" class="">div>
// 小程序
<view wx:if="{{show}}" id="" class="">view>
<view wx:else id="" class="">view>
<view wx:for="{{list}}" wx:key="index" id="" class="" data-index="{{index}}" bindtap="clickBtn" >view>

        这样写可以增加可读性，可以更快速直观地看出来元素之间的关系，以及是否渲染，如何渲染，这些信息比其他属性更主要。其他框架同理。

13.样式文件中根据dom结构分块且有序地编写样式

/* header头部样式 */
.header {
  ...
}
.header .logo {
  ...
}
.header .search-bar {
  ...
}
 
/* list样式 */
.list {
  ...
}
 
.list .item {
  ...
}

 如果你习惯用BEM命名的话也是一样，分块且有序。 甚至如果你想的话，css属性的顺序也可以遵循一套规则，使用stylelint插件stylelint-config-recess-order（安装教程）可以自动调整你的属性顺序。

        一般建议css顺序如下：

（1）定位属性：position  display  float  left  top  right  bottom   overflow  clear   z-index
（2）自身属性：width  height  padding  border  margin   background
（3）文字样式：font-family   font-size   font-style   font-weight   font-varient   color   
（4）文本属性：text-align   vertical-align   text-wrap   text-transform   text-indent    text-decoration   letter-spacing    word-spacing    white-space   text-overflow
（5）css3中新增属性：content   box-shadow   border-radius  transform

后续慢慢更新