使用数字为文件夹添加前缀有哪些可能的优缺点？

Question

我的公司强烈建议对较大的项目使用前缀为数字的子文件夹名称。这记录在公司代码约定文章中。

这看起来应该是这样的

ApplicationRoot/
    SomeSubFolder
        00_SubSubFolder/
        01_SubSubFolder/
        02_SubSubFolder/
    AnotherSubFolder
        00_SubSubFolder/
        01_SubSubFolder/
        02_SubSubFolder/

不知何故，这对我来说是一种无用的开销，但我没有反对的有效论据。

也许更有经验的人可以告诉我有关为什么这是一个坏习惯的情景或告诉我为什么它是好的 - 除了强迫文件夹处于某个特定状态的可能性为了吗

Answer 1

仅在订单很重要时才有用（例如，运行脚本的顺序）。否则它很糟糕（在我看来）。参数是：

• 有些产品不允许。例如java包结构直接映射到目录结构。但包名不能以数字开头。
• 不能使用约定优于配置。一些工具可以帮助你很多软件开发，他们认为你的做法和世界其他地方一样（因为这是一个很好的做法）。你会有很多配置让他们接受你的结构（例如maven）
• 人类感知。我们通过名称而不是数字来查找数据。当我导航到例如文件中时krusader /总指挥官和我有十几个dirs我打字，因为我知道文件夹名称。
• 混淆。如果这些数字毫无意义，那么就会给其他人带来混乱。他们总是会问'为什么'，他们总是会害怕修改添加，删除，因为他们会认为有人这样做是因为一些非常重要的原因。这明显违反了KISS和最少的意外原则（这些事情严重影响了新的开发人员进入障碍）
• 没有灵活性。有时候自定义文件夹名称很好。无论出于何种原因，例如在多个目录中自动搜索配置（通常在java / spring中使用）。但是这样的命名约定更难以实现。有时当你想使用自动命名翻译时，它也可能更难，因为你的目标格式可能不支持以数字开头的名字（例如登录）
• 开销。如果没有理由保留它，那么应该删除任何开销。再次：KISS
• 最后但并非最不重要。开发人员/建筑师总是决定软件设计，布局，使用过的技术等，如果他的手是紧身衣，因为上一个时代的非技术官僚发明了无意义的规则，那只不过是麻烦