最近天天挨骂 ，心里可不爽了但是又不能不服气 ，确实没有人家写的好 因此 做下下几点 规范要求自己
1. 通过规范
：tab建用两个空格来代替 不同系统的tab 占位格不同 windows 4个 linux 8个 这是唯一能保证在所有环境下获得一致展现的方法
：每个样式属性或者每句代码后加 ； 方便断句
2. id 和class 命名规范
：内容优先，表现为辅 user.manager.html页面 中存在一个add form 表单 就可以命名为 formID: user-manager-from-add 名称 ： user-mangaer-form-add-name 密码 ： user-mangaer-form-add-pwd
按钮 ： user-mangaer-form-add-btn-sub //提交按钮 按钮 ： user-mangaer-form-add-btn-dis //取消按钮
model: user-manager-model-add
大块显示问题：user-manager-form-update-mplace-div
页面名称-形式-操作-形式-操作。。。。。。。页面名称-名词-动词-名词-动词。。。。。。。
3. 代码格式：方法名，驼峰方式进行 不能存在 下划线，div块获取 必须以$符至前 ：符号 ， = ！ || 等 必须左右空格 尽量 对齐
4. 目录划分 简洁。有习惯性缩写的单词必须(MUST)采用容易理解的缩写。如：源代码目录使用src，不使用source。下面是更多例子：
：img: 图片。不允许(MUST NOT)使用image、images、imgs等。
: js: javascript脚本。不允许(MUST NOT)使用script、scripts等。
: css: 样式表。不允许(MUST NOT)使用style、styles等。
: swf: flash。不允许(MUST NOT)使用flash等。
: src: 源文件目录。不允许(MUST NOT)使用source等。
: dep: 引入的第三方依赖包目录。不允许(MUST NOT)使用lib、library、dependency等。
: 不允许(MUST NOT)使用复数形式。如：imgs、docs是不被允许的。
下班回家静下心来想了想 ，他这样的文件结构真的是最好的吗？不能替换，吗？
如果我把前端 的操作 用后端模式进行套取 会怎样呢？ 还是拿 user.manager.html 为例子
后端
前端
公司内部
意义
UserDao
userRequest.js
userRequest.js
请求数据返回数据
UserService
userService.js
userHelp.js
对较为复杂的数据进行逻辑转换 从而 使得 前端 操作更加简便(拼接页面)
action
user.js
manager.js
html 页面数据请求的直接调用者
until
userUntil.js
userHelp.js
公共操作的js 可以多次复用
总而言之，这样只是把数据进行了分类处理 相对于 以前的代码来说 其实功能和性质都草不多。但是 各个模块间 数据交换更加清晰了，对于操作流程展示了更强的可控性能 ，说到这儿，不得不说一个问题，代码流程的统一，确实能够帮助我们很快的定位问题，但是有利肯定是有弊端的。流程肯定不是完美的，总是使用一个流程，确实可以增加代码速度和效率，但长期的固化思可能导致创新性的发展，因此在代码流程的道路上 我们需要不断的总结伪问题，形成一个长期可以持续发展的模式
再说说全局变量的问题：全局function 是以前我最喜欢用的函数，确实这样写是没有错误的，但是 过多的全局函数会使页面逻辑相对而言更加复杂 因此必须用到封装来进行操作 多个类似的操作的函数 封装到一个对象里面 属性中去， 以调用对象的方式调数据，使得数据更加简单，而且对于调用者只需要了解这个接口有什么操作，具体内容我们不管 也没有什么问题，使得view 和js的交互更加方便
：再说插件的使用无论是java 还是JavaScript 不得不说我们的广大的代码同胞们的能力是多强大，对于插件 我们的使用规则，常常是使用最简单功能封装这些功能 对数据进行操作。意义 方便插件更新 维护简易
意思两点：最重要的意思就是是封函数，好的封函数 应该是多复用的 ，修改不复杂的（当然函数内部逻辑忽略），意义就在与代码的隐私性，操作简易
