blog
blog copied to clipboard
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文件内容爬下来然后再做一个分析。
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，这种游戏还是很有意思的，也期待更多的尝试。
@nightire 很深刻的分析。写这篇文章没有什么明确的目的，所以也没仔细考虑怎么取样，另外其实也没什么别的好取样的方法，通过stars排名算是唯一比较靠谱的方式了
