怎样给文件命名才显得比较专业？

[hujiulong]

前言

写这篇博客的动机很简单，就是我周末闲的无聊，爬了github上star数前1000的js项目的所有文件的名称，看看大佬们都喜欢给文件和目录取什么名字，我跟着学两招也好显得我比较专业。

注意是js项目啊，你要是搞java的搞PHP的，也跟着学搞不好会被拿去祭天。

统计结果

排除掉了.babelrc，package.json，.github这类文件，得到了93117个文件名。

然后我对文件名计数，同一个项目中多次出现的名称只计算一次。也就是1000个项目中，出现频次最高的名称也不会超过1000。

结果这里写不下，可以点击这里看所有结果，我画了个图大家感受一下就行了

有点意外，出现次数最多的是test，565次，其次才是是src，556次

顾名思义，src是源代码，test就是测试，同样js，css，img这些目录名都很直观。

但是也有一些不太直观的名字在这些项目中也大量出现，比如legacy，benchmarks，fixtures等等。

常用名称

下面列出了一些常用的名称，并不是按出现频次排序，但是列出来的都是出现频次非常高的
单复数形式都出现了的只列出次数最多的
注意，都是目录名称，不是文件名

• src，source
  源代码，用src居多

• test，__tests__
  测试文件，也经常用__test__，facebook的测试框架jest默认的测试文件目录就是__test__

• docs
  文档

• lib
  库文件，library的缩写

• dist
  用来放打包编译后的文件，应该是distribution的缩写

• build，scripts
  构建脚本

• utils，tools，helpers
  工具代码

• controllers，views，middlewares，models
  MVC对应的models，views，controllers，还有中间件middlewares

• router
  路由

• server
  用来放服务端代码

• adapters
  适配器，适配器模式是一种很常用的设计模式
  栗子：https://github.com/hubotio/hubot/tree/master/src/adapters

• legacy
  一般用来放兼容历史版本或兼容旧浏览器的代码
  栗子：https://github.com/julianshapiro/velocity/tree/master/legacy

• config
  配置文件

• benchmarks
  benchmarks测试，又叫基准测试或性能测试。用来测试版本的性能变化

• unit，spec
  单元测试，一般在test目录下

• e2e
  端对端测试，一般在test目录下

• assets，vendor
  资源，一般用来放图片或css文件

• static
  静态资源

• examples，demo
  示例

• component
  组件

• plugins
  插件

• bin
  命令脚本，命令行工具经常会用到
  栗子：https://github.com/vuejs/vue-cli/tree/dev/packages/%40vue/cli/bin

• common
  公用的文件

• packages
  很多项目会打包出多个npm包，用来减小体积，一般会用packages来放不同的包
  栗子：https://github.com/babel/babel/tree/master/packages

• misc
  杂项，miscellaneous的缩写
  栗子：https://github.com/babel/babel/tree/master/packages/babel-plugin-transform-modules-commonjs/test/fixtures/misc

• core
  核心文件
  栗子：https://github.com/mrdoob/three.js/tree/dev/src/core

还有一大堆，总共500多个，我不一一解释了，有兴趣可以点击看统计结果

后话

其实大部分文件名看名字就能知道意思，也有一些是约定俗成的缩写。
相比之下更有意义的是对变量和函数名称的分析，我下次把这些项目的所有js文件内容爬下来然后再做一个分析。

[birkhoff2017]

赞

[archoak]

期待后续

[52cik]

收藏

[lglong519]

有意思，很适合命名困难症的人

[buxuku]

这次文件夹的命名，下次可以分析一下文件的命名，比如js文件，静态资源的文件命名。比如图片文件，有的是以中模线，有些用的是下划线。

[hackshen]

同意楼上说的

[hhking]

期待后续的分析

[nightire]

test 和 src 的数量差其实倒不用觉得意外了，这是显而易见的事情：几乎所有写了测试的项目都会把测试文件夹命名为 test，只有极个别例外，比如说：a）受 BDD 影响颇深的，一定要叫 specs 而不是 test；b）喜欢把测试和源码放在一起的，压根儿用不着 test；c）测试是什么？不存在的……等等；

但源码却不见得要放在 src 里了，这个的选择范围相当的广，比如说放在 module(s)/client/app(s)/component(s)/package(s)……等等等等。这么一来 test 会超过 src 的数量岂非寻常？我还觉得这个差距不够明显嘞！不过考虑取样是 stars 前一千的，那么恐怕绝大多数都是框架和工具类项目，所以这个比例也可以理解。

说到取样范围，如果想要揭示的是项目的多样性的话，硬生生取 stars 前一千我觉得是下策。因为对大多数 JSer 来说，日常工作的项目都不会是在这个范围里的，而因为工作范畴和性质的不同也会导致命名倾向性和考量角度的差异化。

Stars 拿的多的一般都是框架或工具，这种项目的命名讲究的是“精准的抽象”，而大部分 JSer 日常工作的项目则追求的是“简洁的具体”。这俩概念我想有点经验的人多少都能领会，这里就懒得展开了。

Anyway，这种游戏还是很有意思的，也期待更多的尝试。

[hujiulong]

@nightire 很深刻的分析。写这篇文章没有什么明确的目的，所以也没仔细考虑怎么取样，另外其实也没什么别的好取样的方法，通过stars排名算是唯一比较靠谱的方式了

[limars874]

等变量分析，拯救命名困难症患者。

[nightire]

@limars874 你那个病要根治唯一的办法就是增加词汇量，这就是个下功夫的活，没诀窍。

[michalliu]

博主那个横七竖八的文字图是用什么工具生成的

[hujiulong]

博主那个横七竖八的文字图是用什么工具生成的

echarts 词云

[nonusx]

有意思，很适合命名困难症的人

👍

[nonusx]

等变量分析，拯救命名困难症患者。

👍👍 👍 👍 👍

[nonusx]

⭐

[dohooo]

🆒

[Palien-zhang]

标记一下

[leonyh7]

您好，您的邮件我已收到。