目录

1.设计规范
1.1.目录设计
1.2.变量命名
1.3.界面布局
1.4.设计模式
1.5.文档设计
2.编码标准
3.插件应用(以vscode为例)
4.参考资源
5.总结

写在后面

1.设计规范

1.1.目录设计

目录构造这一块设计参照vue脚手架做为一个参考的根底，次要还是要留神命名和构造组织治理。

• 我的项目命名
  全副采纳小写形式， 以中划线分隔。

  正例：mall-management-system/mall_management-system

  反例： mallManagementSystem

• 目录命名
  全副采纳小写形式， 以中划线分隔，有复数构造时，要采纳复数命名法， 缩写不必复数

  正例： scripts / styles / components / images / utils / layouts / demo-styles / demo-scripts / img / doc / demo_scripts

  反例： script / style / demoStyles / imgs / docs

  【非凡】VUE 的我的项目中的 components 中的组件目录，应用 kebab-case 命名

  正例： head-search / page-loading / authorized / notice-icon

  反例： HeadSearch / PageLoading

  【非凡】VUE 的我的项目中的除 components 组件目录外的所有目录也应用 kebab-case 命名
  正例： page-one / shopping-car / user-management

  反例： ShoppingCar / UserManagement
  注：不论参考哪种命名形式，最重要是要规定对立

   ├── index.html                      入口页面    ├── build                            构建脚本目录    │   ├── build-server.js                 运行本地构建服务器，能够拜访构建后的页面    │   ├── build.js                        生产环境构建脚本    │   ├── dev-client.js                   开发服务器热重载脚本，次要用来实现开发阶段的页面主动刷新    │   ├── dev-server.js                   运行本地开发服务器    │   ├── utils.js                        构建相干工具办法    │   ├── webpack.base.conf.js            wabpack根底配置    │   ├── webpack.dev.conf.js             wabpack开发环境配置    │   └── webpack.prod.conf.js            wabpack生产环境配置    ├── config                          我的项目配置    │   ├── dev.env.js                      开发环境变量    │   ├── index.js                        我的项目配置文件    │   ├── prod.env.js                     生产环境变量    │   └── test.env.js                     测试环境变量    ├── mock                            mock数据目录    │   └── hello.js    ├── package.json                    npm包配置文件，外面定义了我的项目的npm脚本，依赖包等信息    ├── src                             我的项目源码目录        │   ├── main.js                         入口js文件    │   ├── app.vue                         根组件    │   ├── components                      公共组件目录    │   │   └── title.vue    │   ├── assets                          资源目录，这里的资源会被wabpack构建    │   │   └── images    │   │       └── logo.png    │   ├── routes                          前端路由    │   │   └── index.js    │   ├── store                           利用级数据（state）    │   │   └── index.js    │   └── views                           页面目录    │       ├── hello.vue    │       └── notfound.vue    ├── static                          纯动态资源，不会被wabpack构建。    └── test                            测试文件目录（unit&e2e）        └── unit                            单元测试            ├── index.js                        入口脚本            ├── karma.conf.js                   karma配置文件            └── specs                           单测case目录                └── Hello.spec.js

1.2.变量命名

网上有很多优良的命名计划，能够参考看看，这里我只是选取比拟要害的根底准则。

• 留神词性
  一般变量/属性应用用名词

  var person = {    name: 'Frank'}var student = {    grade: 3,    class: 2}

  bool变量/属性用形容词或者be动词或者情态动词或者hasX

  var person = {    dead: false, // 如果是形容词，后面就没必要加 is，比方isDead 就很废话    canSpeak: true, //情态动词有 can、should、will、need 等，情态动词前面接动词    isVip: true, // be 动词有 is、was 等，前面个别接名词    hasChildren: true, // has 加名词}

  一般函数/办法用动词结尾

  var person = {    run(){}, // 不及物动词    drinkWater(){}, // 及物动词    eat(foo){}, // 及物动词加参数（参数是名词）}

  回调、钩子函数用介词结尾，或用动词的当初实现时态

  var person = {    beforeDie(){},    afterDie(){},    // 或者    willDie(){}    dead(){} // 这里跟 bool 抵触，你只有不同时裸露 bool dead 和函数 dead 就行，怕抵触就用下面的 afterDie}button.addEventListener('click', onButtonClick)var component = {    beforeCreate(){},    created(){},    beforeMount(){},    mounted(){},    beforeUpdate(){},    updated(){},    activated(){},    deactivated(){},    beforeDestroy(){},    destroyed(){},    errorCaptured(){}}

  容易混同的中央加前缀
  div1.classList.add('active') // DOM 对象
  div2.addClass('active') // jQuery 对象
  不如改成
  domDiv1 或 elDiv1.classList.add('active')
  $div2.addClass('active')
  属性拜访器函数能够用名词
  $div.text() // 其实是 $div.getText()
  $div.text('hi') // 其实是 $div.setText('hi')

• 留神一致性
  介词一致性
  如果你应用了 before + after，那么就在代码的所有中央都保持应用
  如果你应用了 before + 实现时，那么就保持应用
  如果你改来改去，就「不统一」了，不统一将导致「不可预测」
  程序一致性
  比方 updateContainerWidth 和 updateHeightOfContainer 的程序就令人很顺当，同样会引发「不可预测」
  表里一致性
  函数名必须完满体现函数的性能，既不能多也不能少。
  比方

  function getSongs(){    return $.get('/songs).then((response){        div.innerText = response.songs    })}

  就违反了表里一致性，getSongs 示意获取歌曲，并没有暗示这个函数会更新页面，然而实际上函数更新了 div，这就是表里不一，正确的 写法是

  要么纠正函数名

  function getSongsAndUpdateDiv(){    return $.get('/songs).then((response){        div.innerText = response.songs    })}

  要么写成两个函数

  function getSongs(){    return $.get('/songs)}function updateDiv(songs){    div.innerText = response.songs}getSongs().then((response)=>{    updateDiv(response.songs)})

• 工夫一致性
  有可能随着代码的变迁，一个变量的含意曾经不同于它一开始的含意了，这个时候你须要及时改掉这个变量的名字。
  这一条是最难做到的，因为写代码容易，改代码难。如果这个代码组织得不好，很可能会呈现牵一发而动全身的状况（如全局变量就很难改）
  很多优良的框架或者代码，有很多优良的编码标准，咱们能够多参考多学习，灵活运用到理论的我的项目开发中。

1.3.界面布局

web端界面设计布局计划:参考elementUIweb端UI框架设计。
挪动端的界面布局设计方案：参考Vant有赞挪动端UI框架设计。

1.4.设计模式

• 公布订阅模式
  以睿云的我的项目架构为例，每个患者信息依据不同就诊医院可能存在不同层级的组件和页面模块，并且在不同父组件上面的子组件或者孙组件之间传递数据的。
  
  能够看出，图中的数据传递十分复杂，并且不够直观，代码也显得十分臃肿，难以保护。显然仅仅用单向数据流或者双向绑定父子组件间的透传数据，并不能很好的满足一些复杂多变的我的项目需要。
  
  利用公布订阅模式进行专用组件进行全局治理，整个代码构造会十分清晰直观，保护起来也绝对不便。而后，无论子组件还是父组件都能通过这样来传递数据，所有的操作都在一个eventbus事件核心进行，简化其中多层组件的传递的复杂性和不确定性。

  this.eventBus.$emit() // 公布this.eventBus.$on() // 订阅this.eventBus.$off() // 勾销订阅

  能够依据我的项目的理论状况，抉择开发模式，没有最好的设计模式，只有最适宜理论我的项目能力大大简化我的项目复杂性，进步开发效率。

• 表驱动编程
  所有一一对应的关系都能够用表来做，个别波及相干多个if-else等逻辑分支解决，分支最多不要超过三个。不仅代码冗余，而且不够清晰直观。switch...case尽管能够肯定水平解决这样问题，然而当逻辑分支持续减少，代码过长，还是防止不了相干的问题产生。

应用表驱动进行代码改写：

const  types_table={'appointmentSummary':fn1,'patientDiseaseInfo':fn2,'patientInfo':fn3,'questionnaireFiller':fn4...}types_table[type]()

依据不同判断条件对应不同的执行逻辑，将其组织成一个一个的函数，实现逻辑和代码实现的一个抽离。整个代码开发，十分的整洁清晰，而且易于扩大，最要害的是进步了代码的可读性。

1.5.文档设计

jsdoc用于编写前端组件阐明的js正文库，能够依据相干的正文阐明，生成相应的组件开发的文档阐明。无效缩小开发人员之间的开发沟通老本，进步开发效率。

/** * RuiJin类存储一位客人的名字，并打招呼。 */class RuiJin {  /**   * 次要是解释data外面对于瑞金医院的评估报告js的文件   *    * @param {Object} patientInfo 评估报告的患者的根本信息数据   * @param {Boolean} showPanel1 查看报告界面的第一个tab项的显隐   * @param {Boolean} showPanel2 查看报告界面的第二个tab项的显隐   * @param {Object} formData 新增模块的开关期和评分的抉择表格项   * @param {String} evaluationResult1 当报告论断须要两页展现时，用于存储第二页的报告查看论断。   * @param {String} evaluationId 存储以后报告的id项   * @param {Boolean} printPageShow 是否显示超过第二页的打印页   */  constructor() {    this.patientInfo = {}    this.maGaitExport = {      summaryDatas: [],      walkDetails: [],    }    this.summaryData = []  // 概要    this.statis = {      walk: [], // 行走过程      turn: [], // 转向过程      fog: [], // 解冻详情    }    this.patientGaitModel = {}    this.FogRecogn = {      FogResults: {}, // 解冻步态详情      FogDetails: [], // 解冻步态详情    }    this.isEdit = false // 是否处于编辑状态    this.PressureRightEnd = [] // 右后脚跟压强    this.expandState = [true, true, true, true] // 开展收起状态    this.showScrollBtn = false    this.canEdit = false // 查看论断是否能够编辑    this.isShowDialog = false // 是否显示编辑医生弹窗    this.currentTabIndex = 1 // 0 静止剖析报告 1 冻结指数    this.freezeExpandState = [true, true, true] // 解冻步态开展收起状态    this.evaluationResult1 = '闪动'    this.dialog1 = true//查看论断dialog阐明    this.diagnostician = ''//诊断医生    this.tug6CheckItemList = []//参数项list    this.fogDetailsEmptyCount = 0    this.status = ''    this.showPanel1 = false    this.showPanel2 = true    this.formData = {      switchType: '',      isSynchroScore: ''    }    this.evaluationResult1 = ''    this.evaluationId = ''    this.printPageShow = true  }  /**   * 筛选出报告外面所有查看项的试验时长的最大值   *    */  MaxSummaryCheckTime () {    const allCheckTimes = reportData.maGaitExport.summaryDatas.map(item => Math.ceil((item && item.TrialTime) || 0))    if (allCheckTimes.length === 0) {      return 0    } else {      return Math.max(...allCheckTimes)    }  }  /**   * 用于判断打印界面是否须要展现两页   * 首先通过\n换行符来切分判断，存在多少，在去判断在\n的每一段存在多少行   * 通过一行以48列为基准进行计算。   *    */  disatibutePages () {    const colsLength = Math.ceil(this.patientGaitModel.evaluationResult.length / 48)    const rowsLength = this.patientGaitModel.evaluationResult.split('\n').length - 1    if (colsLength + rowsLength > 15) {      this.evaluationResult1 = this.patientGaitModel.evaluationResult.split('\n').slice(rowsLength - colsLength).join('')      this.patientGaitModel.evaluationResult = this.patientGaitModel.evaluationResult.split('\n').slice(0, rowsLength - colsLength).join('')    }    this.printPageShow = false  }}

2.编码标准

2.1.HTML标准

HTML 作为形容网页构造的超文本标记语言，在百度始终有着宽泛的利用。本文档的指标是使 HTML 代码格调保持一致，容易被了解和被保护。

代码格调

缩进与换行

[强制] 应用 4 个空格做为一个缩进层级，不容许应用 2 个空格 或 tab 字符。

解释：
对于非 HTML 标签之间的缩进，比方 script 或 style 标签内容缩进，与 script 或 style 标签的缩进同级。

示例：

<style>/* 款式内容的第一级缩进与所属的 style 标签对齐 */ul {    padding: 0;}</style><ul>    <li>first</li>    <li>second</li></ul><script>// 脚本代码的第一级缩进与所属的 script 标签对齐require(['app'], function (app) {    app.init();});</script>

[倡议] 每行不得超过 120 个字符。

解释：

过长的代码不容易浏览与保护。然而思考到 HTML 的特殊性，不做硬性要求。

命名

[强制] class 必须单词全字母小写，单词间以 - 分隔。

[强制] class 必须代表相应模块或部件的内容或性能，不得以款式信息进行命名。

示例：

<!-- good --><div class="sidebar"></div><!-- bad --><div class="left"></div>

[强制] 元素 id 保障在页面惟一。

解释：

同一个页面中，不同的元素蕴含雷同的 id，不合乎 id 的属性含意。

[倡议] id 倡议单词全字母小写，单词间以 - 分隔。同我的项目必须放弃格调统一。

[倡议] id、class 命名，在防止抵触并形容分明的前提下尽可能短。

示例：

<!-- good --><div id="nav"></div><!-- bad --><div id="navigation"></div><!-- good --><p class="comment"></p><!-- bad --><p class="com"></p><!-- good --><span class="author"></span><!-- bad --><span class="red"></span>

[强制] 禁止创立无款式信息的 class。

解释：

不容许 class 只用于让 JavaScript 抉择某些元素，class 应该具备明确的语义和款式。否则容易导致 CSS class 泛滥。

应用 id、属性抉择作为js是更好的形式。

[强制] 同一页面，应防止应用雷同的 name 与 id。

解释：

IE 浏览器会混同元素的 id 和 name 属性， document.getElementById 可能取得不冀望的元素。所以在对元素的 id 与 name 属性的命名须要十分小心。

一个比拟好的实际是，为 id 和 name 应用不同的命名法。

示例：

<input name="foo"><div id="foo"></div><script>// IE6 将显示 INPUTalert(document.getElementById('foo').tagName);</script>````###  标签#### [强制] 标签名必须应用小写字母。示例：

<!-- good -->
<p>Hello StyleGuide!</p>

<!-- bad -->
<P>Hello StyleGuide!</P>

#### [强制] 对于无需自闭合的标签，不容许自闭合。解释：常见无需自闭合标签有 `input`、`br`、`img`、`hr` 等。示例：

<!-- good -->
<input type="text" name="title">

<!-- bad -->
<input type="text" name="title" />

#### [强制] 对 `HTML5` 中规定容许省略的闭合标签，不容许省略闭合标签。解释：对代码体积要求十分严苛的场景，能够例外。比方：第三方页面应用的投放零碎。示例：

<!-- good -->
<ul>

<li>first</li><li>second</li>

</ul>

<!-- bad -->
<ul>

<li>first<li>second

</ul>

#### [强制] 标签应用必须合乎标签嵌套规定。解释：比方 `div` 不得置于 `p` 中，`tbody` 必须置于 `table` 中。具体的标签嵌套规定参见[HTML DTD](http://www.cs.tut.fi/~jkorpela/html5.dtd)中的 `Elements` 定义局部。#### [倡议] HTML 标签的应用应该遵循标签的语义。(语义化)解释：上面是常见标签语义- p - 段落- h1,h2,h3,h4,h5,h6 - 层级题目- strong,em - 强调- ins - 插入- del - 删除- abbr - 缩写- code - 代码标识- cite - 引述起源作品的题目- q - 援用- blockquote - 一段或长篇援用- ul - 无序列表- ol - 有序列表- dl,dt,dd - 定义列表示例：

<!-- good -->
<p>Esprima serves as an important building block for some JavaScript language tools.</p>

<!-- bad -->
<div>Esprima serves as an important <span class="strong">building block</span> for some JavaScript language tools.</div>

#### [倡议] 在 CSS 能够实现雷同需要的状况下不得应用表格进行布局。解释：在兼容性容许的状况下应尽量放弃语义正确性。对网格对齐和拉伸性有严格要求的场景容许例外，如多列简单表单。#### [倡议] 标签的应用应尽量简洁，缩小不必要的标签。示例：

<!-- good -->
<img class="avatar" src="image.png">

<!-- bad -->
<span class="avatar">

<img src="image.png">

</span>

###  属性#### [强制] 属性名必须应用小写字母。示例：

<!-- good -->