《最好最全面的前端开发规则》由会员分享，可在线阅读，更多相关《最好最全面的前端开发规则（43页珍藏版）》请在金锄头文库上搜索。
1、.这是一份旨在增强团队的开发协作,提高代码质量和打造开发基石的编码风格规范,其中包含了 HTML, JavaScript 和 CSS/SCSS 这几个部分。我们知道,当一个团队开始指定并实行编码规范的话,错误就会变得更加显而易见。如果一段特定的代码不符合规范的话,它有可能只是代码风格错误,而也有可能会是 bug。早期指定规范就使得代码审核得以更好的开展,并且可以更精确的地定位到错误。只要开发者们能够保证源代码源文件都严格遵循规范,那接下去所使用的混淆、压缩和编译工具则可投其所好不尽相同。一般规范以下章节列举了一些可应用在 HTML, JavaScript 和 CSS/SCSS 上的通用规则。文
2、件/资源命名在 web 项目中,所有的文件名应该都遵循同一命名约定。以可读性而言,减号-是用来分隔文件名的不二之选。同时它也是常见的 URL 分隔符i.e./ compass1中的下划线就是用来标记跳过直接编译的文件用的。资源的字母名称必须全为小写,这是因为在某些对大小写字母敏感的操作系统中,当文件通过工具压缩混淆后,或者人为修改过后,大小写不同而导致引用文件不同的错误,很难被发现。还有一些情况下,需要对文件增加前后缀或特定的扩展名比如 .min.js, .min.css,抑或一串前缀比如。这种情况下,建议使用点分隔符来区分这些在文件名中带有清晰意义的元数据。不推荐1. MyScript.js
3、2. myCamelCaseName.css3. i_love_underscores.html4. 1001-scripts.js5. my-file-min.css推荐1. my-script.js2. my-camel-case-name.css3. i-love-underscores.html4. thousand-and-one-scripts.js协议不要指定引入资源所带的具体协议。当引入图片或其他媒体文件,还有样式和脚本时,URLs 所指向的具体路径,不要指定协议部分http:,https:,除非这两者协议都不可用。不指定协议使得 URL 从绝对的获取路径转变为相对的,在请求资
4、源协议无法确定时非常好用,而且还能为文件大小节省几个字节。不推荐1. 推荐1. 不推荐1. .example 2. background: url;3. 推荐1. .example 2. background: url;3. 文本缩进一次缩进两个空格。1. 2. Fantastic3. Great4. 5. Test6. 7. 1. media screen and2. body 3. font-size:100%;4. 5. 1. function2. var x =10;3. function y4. return5. result:* x6. 7. 8. ;注释注释是你自己与你的小伙伴们
5、了解代码写法和目的的唯一途径。特别是在写一些看似琐碎的无关紧要的代码时,由于记忆点不深刻,注释就变得尤为重要了。编写自解释代码只是一个传说,没有任何代码是可以完全自解释的。而代码注释,则是永远也不嫌多。当你写注释时一定要注意：不要写你的代码都干了些什么,而要写你的代码为什么要这么写,背后的考量是什么。当然也可以加入所思考问题或是解决方案的链接地址。不推荐1. var offset =0;2. if3. / Add offset of 204. offset =20;5. 推荐1. var offset =0;2. if3. / If the labels are included we nee
6、d to have a minimum offset of 20 pixels4. / We need to set it explicitly because of the following bug: http:/ offset =20;6. 一些注释工具可以帮助你写出更好的注释。JSDoc或YUIDoc就是用来写 JavaScript 注释用的。你甚至可以使用工具来为这些注释生成文档,这也是激励开发者们写注释的一个好方法,因为一旦有了这样方便的生成文档的工具,他们通常会开始花更多时间在注释细节上。代码检查对于比较宽松自由的编程语言来说,严格遵循编码规范和格式化风格指南就显得极为重要。遵循
7、规范固然很好,但是有自动化流程来确保其执行情况,岂不更佳。Trust is good, control is better.对于 JavaScript,建议使用JSLint或JSHint。HTML 规范文档类型推荐使用 HTML5 的文档类型申明：.建议使用 text/html 格式的 HTML。避免使用 XHTML。XHTML 以及它的属性,比如application/xhtml+xml在浏览器中的应用支持与优化空间都十分有限。HTML 中最好不要将无内容元素1的标签闭合,例如：使用而非.HTML 验证一般情况下,建议使用能通过标准规范验证的 HTML 代码,除非在性能优化和控制文件大小上不
8、得不做出让步。使用诸如 W3C HTML validator 这样的工具来进行检测。规范化的 HTML 是显现技术要求与局限的显著质量基线,它促进了 HTML 被更好地运用。不推荐1. Test2. This is only a test.推荐1. 2. 3. Test4. This is only a test.省略可选标签HTML5 规范中规定了 HTML 标签是可以省略的。但从可读性来说,在开发的源文件中最好不要这样做,因为省略标签可能会导致一些问题。省略一些可选的标签确实使得页面大小减少,这很有用,尤其是对于一些大型网站来说。为了达到这一目的,我们可以在开发后期对页面进行压缩处理,在这
9、个环节中这些可选的标签完全就可以省略掉了。脚本加载出于性能考虑,脚本异步加载很关键。一段脚本放置在内,比如,其加载会一直阻塞 DOM 解析,直至它完全地加载和执行完毕。这会造成页面显示的延迟。特别是一些重量级的脚本,对用户体验来说那真是一个巨大的影响。异步加载脚本可缓解这种性能影响。如果只需兼容 IE10+,可将 HTML5 的 async 属性加至脚本中,它可防止阻塞 DOM 的解析,甚至你可以将脚本引用写在里也没有影响。如需兼容老旧的浏览器,实践表明可使用用来动态注入脚本的脚本加载器。你可以考虑yepnope或labjs。注入脚本的一个问题是：一直要等到 CSS 对象文档已就绪,它们才开始
10、加载短暂地在 CSS 加载完毕之后,这就对需要及时触发的 JS 造成了一定的延迟,这多多少少也影响了用户体验吧。终上所述,兼容老旧浏览器时,应该遵循以下最佳实践。脚本引用写在 body 结束标签之前,并带上 async 属性。这虽然在老旧浏览器中不会异步加载脚本,但它只阻塞了 body 结束标签之前的 DOM 解析,这就大大降低了其阻塞影响。而在现代浏览器中,脚本将在 DOM 解析器发现 body 尾部的 script 标签才进行加载,此时加载属于异步加载,不会阻塞 CSSOM但其执行仍发生在 CSSOM 之后。所有浏览器中,推荐1. 2. 3. 4. 5. 6. 7. 8. 9. 只在现代浏
11、览器中,推荐1. 2. 3. 4. 5. 6. 7. 8. 9. 语义化根据元素有时被错误地称作标签其被创造出来时的初始意义来使用它。打个比方,用 heading 元素来定义头部标题,p 元素来定义文字段落,用 a 元素来定义链接锚点,等等。有根据有目的地使用 HTML 元素,对于可访问性、代码重用、代码效率来说意义重大。以下示例列出了一些的语义化 HTML 主要情况：不推荐1. My page title2. 3. Home4. News5. About6. 7. 8. 9. All news articles10. 11. Bad article12. Introduction sub-title13. This is a very bad example for HTML semantics14. I think Im more on the side an
