HarmonyOS鸿蒙Next中你在团队里是怎么统一代码风格的？

用 ESLint？Prettier？还是靠 Code Review 硬扛？有没有适配 ArkTS 的成熟配置方案？

eggper 1楼

在HarmonyOS Next团队中，统一代码风格主要依赖以下工具和规范：

ArkTS语言规范：遵循华为官方定义的ArkTS编码规范。
自动化工具：使用DevEco Studio内置的代码格式化功能，结合ESLint等静态检查工具自动校验。
配置共享：通过团队共享的编辑器配置文件（如.prettierrc、.eslintrc）确保格式一致。
代码审查：在合并请求中强制检查代码风格，不符合规范的代码不予通过。

更多关于HarmonyOS鸿蒙Next中你在团队里是怎么统一代码风格的？的实战系列教程也可以访问 https://www.itying.com/category-93-b0.html

phonegap100 2楼

在HarmonyOS Next的ArkTS项目开发中，统一代码风格是保证团队协作效率和代码质量的关键。我们通常采用工具自动化与人工审查相结合的方式，而不是单纯依赖某一种方法。

1. 核心工具链：ESLint + Prettier 这是目前最主流和高效的自动化方案。我们通过配置ESLint进行代码质量检查（如语法错误、潜在问题），同时使用Prettier进行代码格式化（如缩进、换行、引号等）。两者结合，可以实现提交代码前的自动修复。

2. 针对ArkTS的配置方案 对于ArkTS，华为官方提供了基础的ESLint规则支持。在此基础上，团队通常会根据项目规范和最佳实践，在项目根目录的 .eslintrc.js 配置文件中进行扩展和自定义。一个典型的配置会继承 @ohos/eslint-config 等官方或社区推荐的规则集，并覆盖团队特定的风格要求（如命名约定、组件规范等）。Prettier的配置则相对独立，在 .prettierrc 文件中定义。

3. 集成到开发流程

开发阶段：在IDE（如DevEco Studio）中配置保存时自动格式化或运行ESLint检查，让开发者即时修正。
提交阶段：通过Git的 pre-commit 钩子（使用husky等工具），在代码提交前自动运行ESLint和Prettier，确保进入仓库的代码风格统一。
合并阶段：在CI/CD流水线中集成代码检查任务，作为合并请求（Merge Request）的一道强制关卡。

4. Code Review 的作用 工具无法覆盖所有场景，尤其是业务逻辑和架构设计。Code Review 是必不可少的补充环节，用于审查代码的可读性、设计合理性以及工具规则可能遗漏的细节。它和自动化工具是相辅相成的关系，而非“硬扛”。

总结：成熟的方案是 “ESLint（定制化ArkTS规则）+ Prettier（统一格式化）+ Git钩子/CI自动化检查 + Code Review（人工逻辑审查）” 的组合拳。建议团队在项目初期就协商并固化这些工具的配置，将其作为工程规范的一部分提交到代码库中。