在鸿蒙发展初期就提 Clean Code，可能很多读者会觉得现在还不到时候，能用起来再谈优化成为很多人挂在嘴边的一句话。实际上这个问题很简单，Clean Code 是木桶其中的一块板，需要让它跟其它木板平衡起来，既不需要过度追求比其它木板长很多，也不能放任不管让它漏水。目前来说还没有精力对 134 个仓库一一分析，只能就我看到的范围内逐步深入，先写一篇权作引子，同时也是抛砖引玉希望能引出大神来一起讨论。

首先，整体而言，134 个仓库在命名上相当的规范，小写加下划线分隔几乎贯彻了全部仓库。其中有少数例外是保持了第三方软件的本来拼写，例如 third_party_FreeBSD、third_party_NuttX 等等。但是在这里其实没有必要保留第三方的大小写，统一成全小写更整齐也更容易遵从，毕竟浏览一遍仓库之后会发现比如 third_party_unity(Unity)、third_party_freetype(FreeType) 等等没有遵循原第三方软件拼写的库，两种情况实际上差不多各占一半，还是略有混乱。当然这点不是特别重要，只是一点小问题。

然后，在仓库命名方面还是能够发现另外一些规律，比如上面提到的第三方库都是 third_party 开头，此外还有一些规律也比较明显，例如这一组

还有这一组

包括更复杂一点的

会发现一个什么现象呢，摆在一起很有规律，如果说规律是什么说不出来，甚至无法预测（比如 kits 在上述库中什么作用？有的 frameworks 后面不跟 kits 有的后面跟着 kits）。这可能会造成一个问题，当鸿蒙的仓库继续扩大规模之后（这是必然发生的）命名会造成很大的困扰。

这里可以参考一下 Debian/Ubuntu 的软件包处理方式，库或者软件本身使用一个名字（像上面图中的 services, frameworks 仓库可以命名为 communication_ipc, communication_wifi, aafwk_services 等），头文件等开发所需的文件（对应上面图中的 interfaces）在名字后面增加 -dev 后缀，cli 工具等增加 -utils 后缀。这样会显得更加清晰，在几千几万个仓库时也能够很简单地统一命名。

限于篇幅就先讲这两个小问题，在后面的文章里可能还要讲一下作者看到的示例代码和源代码中的一些特点。

本文参与了「解读鸿蒙源码」技术征文，欢迎正在阅读的你也加入。