前端代码风格检查实施细则

前端代码风格检查实施细则一、总则（一）目的明确。为规范前端代码风格，提升代码可读性与可维护性，本细则旨在统一代码规范，促进团队协作，确保代码质量。（二）适用范围。本细则适用于公司所有前端开发项目，包括但不限于Web应用、移动端H5页面及小程序开发。（三）基本原则。代码风格检查应遵循统一性、一致性、可读性、可维护性原则，确保代码风格符合行业标准与团队规范。二、代码格式规范（一）命名规范。变量名、函数名、类名等应使用驼峰命名法，首字母小写；常量名应全大写，单词间用下划线分隔。（二）缩进规范。代码缩进统一使用4个空格，禁止使用Tab键；每行代码长度建议控制在80-120字符内，超出部分应进行换行。（三）注释规范。关键逻辑、复杂算法应添加注释，注释内容应简洁明了；文件头部需添加版权声明、作者信息、创建日期等。（四）空行规范。函数、类定义之间需空一行；逻辑块之间根据复杂程度空0-2行。（五）分号规范。JavaScript代码必须以分号结尾，禁止使用自动分号插入（ASI）。（六）括号规范。代码块必须使用大括号包裹，且左右大括号各占一行；条件语句、循环语句的括号内即使只有单一语句也需保留。三、代码结构与组织（一）文件结构。每个前端模块应单独成文件，文件名与模块名一致；文件内部按功能模块划分，如组件定义、工具函数、API调用等。（二）模块划分。大型项目应按功能模块划分，模块间通过接口或事件进行解耦；每个模块应包含独立的入口文件与出口文件。（三）组件规范。组件文件应包含模板、脚本、样式三部分，模板部分使用单文件组件（SFC）格式；组件名必须使用大写字母开头。（四）样式规范。CSS样式应使用BEM命名法，避免全局样式污染；推荐使用CSS预处理器（Sass/Less）进行样式管理。（五）脚本规范。JavaScript代码应遵循ES6+规范，避免使用过时语法；工具函数应独立封装，避免污染全局命名空间。四、代码质量标准（一）代码复用。通用功能应封装为工具函数或组件，避免重复代码；通过组件化、模块化实现代码复用。（二）性能优化。关键渲染路径应进行性能优化，如避免重绘与回流；长列表、大数据渲染应使用虚拟滚动技术。（三）可访问性。前端代码必须符合WCAG2.0标准，确保残障人士可访问；表单控件、按钮等应添加适当的ARIA属性。（四）安全性规范。敏感数据传输必须使用HTTPS；避免XSS、CSRF等常见安全漏洞；API接口应进行权限校验。（五）测试覆盖。核心功能应编写单元测试，测试用例覆盖率不低于80%；推荐使用Jest、Mocha等测试框架。五、检查与执行机制（一）检查工具。团队统一使用ESLint、Prettier、Stylelint等工具进行代码风格检查；工具配置应全团队统一。（二）提交规范。代码提交前必须通过风格检查工具校验；提交信息应遵循“类型：描述”格式，如“fix：修复登录按钮样式”。（三）代码审查。每次代码提交必须经过至少一名其他成员审查；审查重点包括代码风格、逻辑正确性、性能优化等。（四）自动化检查。持续集成（CI）流程中必须包含代码风格检查环节；提交未通过检查的代码将无法合并。（五）违规处理。首次违规应口头警告，多次违规需进行书面通报；严重违规将影响绩效评估。六、培训与维护（一）培训计划。每月组织一次前端代码规范培训，内容包括新规范解读、工具使用技巧等；新成员入职后必须接受规范培训。（二）文档更新。本细则每年修订一次，修订内容需经过团队讨论通过；修订后的细则需全员学习并签字确认。（三）问题反馈。团队成员可随时提出规范优化建议；建议需经过技术负责人评估，合理部分纳入细则修订。（四）版本管理。本细则使用Git进行版本管理，每次修订需记录修订人、修订日期、修订内容；主分支为最新有效版本。（五）责任分工。技术负责人负责细则的解释与监督执行；前端开发组长负责日常检查与反馈；全体成员需遵守细则要求。七、附则（一）生效日期。本细则自发布之日起生效，旧版规范文件同时作废。（二）解释权。本细则由技术部负责解释，如有争议需提交技术委员会裁决。（三）执行监督。各部门主管需监督本细则执行情