| 前端代码中的自定义变量命名 | ||
| 命名方法： | ||
| 1.驼峰 2.下划线连接 | ||
| 对于文件名，我们一般采用小写字母+下划线的形式 | ||
| 为什么？因为在window下aa.txt和AA.txt系统认为是同一个的文件，而在linux环境下则认为是2个不同的文件，为了使我们代码移植性更好以及为了避免一些不必要的麻烦建议文件名必须小写； | ||
| 对于js又有以下一些规则： | ||
| A：普通变量名 | ||
| 1.以变量首字母突出这个变量的类型(我叫她首字母标记类型法)； | ||
| 如： | ||
| 定义多个学生数组 let aStudent = [‘shiyue‘, ‘ansheng‘]; | ||
| 定义一个学生对象 let oStudent = { name: ‘xx‘ }； | ||
| 定义学生的名字 let sName = ‘HanMeimei‘; | ||
| 2.在变量末尾突出这个变量类型(我叫她变量末尾比较类型法, 我自己比较喜欢这种)； | ||
| 如： | ||
| 2.1 驼峰命名 | ||
| 定义多个学生数组 let studentAry = [‘shiyue‘, ‘ansheng‘]; | ||
| 定义一个学生对象 let studentObj = { name: ‘xx‘ }； | ||
| 定义学生的名字 let name = ‘HanMeimei‘; | ||
| 2.2 下划线命名 | ||
| 定义多个学生数组 let student_ary = [‘shiyue‘, ‘ansheng‘]; | ||
| 定义一个学生对象 let student_obj = { name: ‘xx‘ }； | ||
| 定义学生的名字 let name = ‘HanMeimei‘; | ||
| B: 函数变量名 | ||
| 函数名推荐采用驼峰命名 | ||
| 如： | ||
| 获取学生姓名的方法： let getName = function(){} ---方式1 | ||
| 可能有人会这样定义： let getStudentName = function(){} ---方式2 | ||
| 这2种方式哪个更好呢？ | ||
| 如果这个脚本或者说这个文件中有获取学生姓名和获取老师姓名2个需求，那我觉得方式2更合适，如果只有获取学生姓名这1个需求，那方式1更简单合适； | ||
| 获取学生这个对象： let getStudent = function(){} | ||
| 因为student就是1个对象，所以我们不需要写成getStudentObj，阅读我们代码的人也能一目了然的想到这是获取学生对象； | ||
| C: 事件监听函数命名 | ||
| 事件监听函数命名建议采用onXXX开头的驼峰式命名 | ||
| 如： | ||
| 监听一个下拉选择组件的change事件： let onSelectChange = function(e){...} | ||
| 当一个页面中需要注册多个下拉选择组件的change事件时我们又该如何定义？ | ||
| 这个时候直接写onSelectChange显然不太合适了， | ||
| 如筛选条件中 学生对象的改变； 性别的改变 | ||
| onStudentChange(){} | ||
| onSexChange(){} | ||
| ！important | ||
| D：关于变量名的简写 | ||
| 很多时候我们的变量名需要多个单词拼接，但是我们又不想让这个变量名太长，很难取舍 | ||
| 如： | ||
| 定义未读消息条数，我看到有人是这样定义的 let notRead = 0; | ||
| 显然这个变量很糟糕， 首先否定修饰很多时候只需要在单词前面加上un, 比如我们js中的defined <-> undefined，其次，我们在定义记数相关时一般都会使用count | ||
| let unReadCount = 0; ---方式1 | ||
| let notRead = 0; ---方式2 | ||
| 显然方式1更优雅，一看就知道是个数量的定义，而方式2更像是一个未读的Flag标记，很难让人直接和未读条数联系起来； | ||
| E: 逻辑关系 | ||
| 如： | ||
| 在vue中定义一个是否显示的标记： v-if="isShow" | ||
| isShow是true就是显示，false就是隐藏，这样我们的代码逻辑就会很清晰； | ||
| 现在我们看2个很糟糕的例子： | ||
| 同样是在vue中定义是否显示的标记： | ||
| v-if="isHide" | ||
| v-if="!isHide" | ||
| 这2中方式都不好，我们的原则就是能避免使用否定的就尽量不要使用否定，不管单个否定还是双向否定，总之正向的逻辑会更清晰； | ||
| 要洗澡睡觉了，对于css样式的命名下一篇再介绍 |
原文：https://www.cnblogs.com/longly/p/10023760.html