浅谈前端研发链路之代码规范

本文首发于微信公众号：前端徐徐。欢迎关注，获取更多前端技能分享。

大家好，我是徐徐。今天我们来聊聊前端研发链路中的代码规范。

前言

在前端开发过程中，保持代码的整洁和一致性是至关重要的。这不仅有助于团队协作，提高代码的可读性和可维护性，还能减少错误，提升开发效率。本文将从业界流行规范，CSS命名规范，工具三个方面简析一下前端开发中的代码规范，然后探讨一下未来代码规范的发展趋势。

业界流行规范

其实我相信大部分前端开发者刚入行前端的时候或多或少都阅读过一些规范，有官方的规范，有公司的规范，有自己部门的规范，但是大部分小伙伴应该都是从业界流行的代码规范去学习和了解的。
业界流行的代码规范说明是大家都比较认可的，学习它的主要目是提高代码的一致性和可维护性，帮助我们编写清晰、简洁且高质量的代码。有个规范之后，编码才有一条准则，下面是对几个常用的业界流行规范做了简洁的对比，在实际的开发中，团队和个人可以根据自己的风格来选择，每个风格都了解一下，但是最后旨在一条，规范统一。

Airbnb Style Guide

Airbnb Style Guide 是业界最流行的 JavaScript 代码规范之一，由 Airbnb 团队发布。它涵盖了 JavaScript、React 和 JSX 的最佳实践，强调代码的可读性和一致性。例如，它建议使用箭头函数、模板字符串、解构赋值等现代语法。
优点：

1. 详细且全面，涵盖了 JavaScript、React 和 JSX 的最佳实践。
2. 提供了大量的示例和解释，便于理解和应用。
3. 被广泛使用，有大量社区支持和插件。

缺点：

1. 规则较多，初学者可能觉得繁琐。
2. 某些规则可能不适用于所有项目，需要根据具体情况调整。

网址：https://github.com/airbnb/javascript

StandardJS

StandardJS 是一个无配置的 JavaScript 代码规范，它旨在通过极简的配置实现最佳的代码风格。StandardJS 不需要额外的配置文件，只需在项目中添加依赖即可使用。它内置了许多默认规则，帮助开发者快速上手并保持代码的一致性。
优点：

1. 无需配置，开箱即用，非常简洁。
2. 统一的风格，减少团队间的代码风格差异。
3. 自动修复功能，简化开发流程。

缺点：

1. 灵活性较差，无法根据项目需求自定义规则。
2. 不适用于需要高度定制的项目。

网址：https://github.com/standard/standard

Google Style Guide

Google Style Guide 是由 Google 发布的代码规范，涵盖了多种编程语言，包括 JavaScript。Google Style Guide 强调一致性和可读性，并提供了详细的规则和示例，帮助开发者编写高质量的代码。
优点：

1. 由 Google 提供，覆盖面广，具有权威性。
2. 强调一致性和可读性，有助于编写高质量代码。
3. 详细的文档和示例，便于学习和实施。

缺点：

1. 规则较多，需要时间适应。
2. 某些规则可能不适用于小型或快速迭代的项目。

网址：https://google.github.io/styleguide

上面的这些规范大部分都是 JS 相关的规范，但是在前端开发中还有一个非常重要的规范，那就是 CSS 规范。

CSS 命名规范

上面这张图片其实侧面也反映了 CSS 的重要性，如果 CSS 写得好会节省不少的开发时间。的确 CSS 不是一门非常漂亮的语言，但 20 多年来它已经成功地为 Web 样式提供了动力，也算一门很厉害的语言了。但是很多开发者并不会很好地维护 CSS，大部分原因是没有一个系统的 CSS 命名指导，或者大部分人都是随心所欲。
CSS 命名规范的作用就是让我们的代码更整洁、易读，减少样式冲突。通过一致的命名规则，不管是谁写的代码，团队里的每个人都能轻松理解和维护，协作起来也更顺畅。这样一来，项目变大了也不容易乱，大家修改和扩展样式时都更方便。下面简单对比一下几种命名方式，大家可根据自己的情况选择相应的命名方式。

BEM

BEM（Block, Element, Modifier）是一种 CSS 命名方法学，旨在提高 CSS 代码的可读性和可维护性。BEM 将组件分为块（Block）、元素（Element）和修饰符（Modifier），并通过命名约定来表示它们之间的关系。例如，block__element--modifier 表示一个块中的元素及其修饰符。
优点：

1. 命名清晰，层次分明，提高代码的可读性和可维护性。
2. 易于与 JavaScript 结合，实现动态样式。
3. 提高样式复用性，减少重复代码。

缺点：

1. 初学者需要时间适应命名规则。
2. 对于小型项目，可能显得过于复杂。

网址：https://getbem.com

OOCSS

OOCSS（Object Oriented CSS）是一种面向对象的 CSS 方法学，旨在通过将样式分为结构（structure）和皮肤（skin）两部分，提高样式的复用性和模块化。OOCSS 强调将重复的样式提取到独立的类中，以减少代码冗余。
优点：

1. 强调复用性和模块化，提高代码的灵活性。
2. 减少样式重复，提高开发效率。
3. 易于维护和扩展。

缺点：

1. 需要开发者具备一定的面向对象思想。
2. 初始学习曲线较陡。

网址：https://github.com/stubbornella/oocss/wiki

SMACSS

SMACSS（Scalable and Modular Architecture for CSS）是一种 CSS 架构，旨在通过模块化和分层的方式组织样式。SMACSS 将样式分为五类：基础（Base）、布局（Layout）、模块（Module）、状态（State）和主题（Theme），以提高样式的可维护性和扩展性。
优点：

1. 分层结构清晰，便于维护和扩展。
2. 提供了灵活的命名约定，适应不同项目需求。
3. 易于与其他方法学结合使用。

缺点：

1. 初期设置和组织样式文件可能较为复杂。
2. 对于小型项目，可能显得过于复杂。

网址：https://smacss.com

工具

说到代码规范相关的工具，就想拿出上面👆这张图，不知道各位看官是一种什么样的看法，一锅乱炖，要是搞不好就是一坨💩。
这里的工具主要是旨在辅助开发者编写高质量代码的工具，确保代码的一致性和可维护性。每个工具都有自己的应用场景，如何组合使用让你的项目更加规范也是一个需要研究的课题，但是在这里不做过多的配置性的说明，因为基本的配置官网都有，这里只是简单对比一下各个工具的使用场景和优缺点，方便大家根据自己的情况自行选择。还是那句话，工具不是越多越好，适合自己的才是最好的，主打一个接地气。

Eslint

Eslint 是一个用于检查 JavaScript 代码的工具，帮助开发者遵循最佳实践和代码规范。Eslint 支持自定义规则和插件，可以与 Airbnb Style Guide 等代码规范结合使用，确保代码的一致性和质量。
优点：

1. 强大的自定义规则和插件支持。
2. 与多种编辑器集成，提供即时反馈。
3. 帮助发现潜在错误和保持代码一致性。

缺点：

1. 初次配置可能较为复杂。
2. 需要根据项目需求不断调整和更新规则。

网址：https://eslint.org

stylelint

stylelint 是一个强大的 CSS 检查工具，支持多种 CSS 预处理器和自定义规则。通过 stylelint，开发者可以定义和执行 CSS 代码规范，保持样式的一致性和可维护性。
优点：

1. 强大的 CSS 检查能力，支持多种预处理器。
2. 自定义规则和插件丰富，灵活性高。
3. 有助于保持样式一致性和减少错误。

缺点：

1. 初次配置较为复杂，需了解 CSS 规范。
2. 对于小型项目，可能显得过于繁琐。

网址：https://stylelint.io

commitlint

commitlint 是一个用于检查提交消息的工具，确保提交消息遵循指定的规范。通过 commitlint，团队可以保持提交历史的清晰和一致，提高代码管理的效率。
优点：

1. 确保提交消息的一致性，提高提交历史的可读性。
2. 支持自定义规则，适应不同团队需求。
3. 与 CI/CD 工具集成，自动检查提交消息。

缺点：

1. 需要团队成员遵循规范，否则效果有限。
2. 配置可能较为复杂，需要时间熟悉。

网址：https://commitlint.js.org

prettier

prettier 是一个代码格式化工具，支持多种编程语言和代码规范。prettier 可以自动格式化代码，确保代码风格的一致性和可读性，减少人为的格式化错误。
优点：

1. 自动格式化代码，确保代码风格一致。
2. 支持多种语言和框架，适用范围广。
3. 减少人为格式化错误，提高开发效率。

缺点：

1. 某些格式化规则可能不符合个人或团队习惯。
2. 对于大规模项目，初次格式化可能影响较大。

网址：https://prettier.io

husky & lint-staged

husky 和 lint-staged 是两个用于 Git hooks 的工具。通过 husky，可以在 Git 操作前后执行指定的命令，如代码检查和测试。lint-staged 则可以在提交代码前，对暂存区的文件进行检查和修复，确保代码质量。
优点：

1. 在 Git hooks 中执行命令，确保代码质量。
2. 自动检查和修复暂存区文件，减少提交错误。
3. 易于与其他工具集成，增强工作流程。

缺点：

1. 初次配置较为复杂，需要熟悉 Git hooks。
2. 对于频繁提交的项目，可能增加提交时间。

网址：

• https://typicode.github.io/husky
• https://github.com/lint-staged/lint-staged

未来的发展

上面提到的都是大家经常接触到的一些已经成型的规范和工具，不过随着前端技术的发展，代码规范和工具也在不断演进，现在涌现出了非常多智能化、自动化的工具，帮助开发者更高效地编写和维护代码。
主要体现在下面两块：
AI 驱动的代码审查

• 自动检测和修复：基于 AI 的代码审查工具能够自动检测代码中的潜在问题，包括语法错误、性能瓶颈和安全漏洞。这些工具通过机器学习算法不断学习和改进，提供更准确的建议。
• 智能推荐：这些工具不仅可以发现问题，还能够提供智能建议，比如代码优化、重构建议，甚至是根据上下文推荐最佳实践。

自动化测试和 CI/CD 集成

• 自动化测试：随着智能化工具的发展，自动化测试也越来越智能。例如，通过 AI 驱动的测试工具能够自动生成测试用例，预测潜在的测试覆盖缺口。
• 集成到 CI/CD：这些工具与 CI/CD 系统紧密集成，能够实时分析提交的代码，并在构建和部署过程中进行检查和优化。

上面说到的两块其实也不叫未来了，已经都在逐步实现了，只是很多产品都还在完善当中，各个大厂也都基本在自己的发布平台集成了或多或少的相关插件去做一些质量上的管理，其目的都是为了让代码更加规范。

结语

代码规范是一个老生常谈的问题，每个团队都有自己团队的风格，也可能定制出不一样的编码规则，但是基本上业界的标准是通用的，只是在团队的实施过程中会有少许差异。
代码规范其目的不是为了束缚某个人，而是抹平整个团队代码风格的差异。对于网上那些贩卖焦虑说要写出独一无二的代码不被取代的，这种话听听就行，一个优秀的开发者应该专研于技术和业务实现，而不是在绞尽脑汁写出不可取代的代码上，你的核心竞争力是你对业务场景能给出优秀的技术解决方案并成功落实它。
以上观点纯属个人观点，不喜勿喷。大家有其他问题可以在评论区进行讨论。