为什么java包名应该是小写的？

实际上这完全是一个理论问题。但有趣的是，为什么java规范不允许在包中使用大写字母，并导致编写如下内容：

com.mycompany.projname.core.remotefilesystemsynchronization.*

而不是

com.myCompanyName.projName.core.remoteFileSystemSynchronization.*

直接来自

包名用小写字母书写，以避免与 类或接口的名称

但有趣的是，为什么java规范不允许在包中使用大写字母，并导致编写如下内容：

com.mycompany.projname.core.remotefilesystemsynchronization.*

规格允许它只是罚款。使用所有小写字母只是一种惯例

正如gtgaxiola所说，这确实避免了与类型名的冲突。。。在.NET命名约定中，确实会发生这种情况，这会给您带来建议。当然，使用camelCase包可以完全避免冲突

---

我怀疑现实情况是，在创建包命名约定时没有充分考虑它。就我个人而言，我很少发现这是一个问题——如果我最终看到一个包含“remotefilesystemsynchronization”元素的包那么大写并不是我关心的主要问题：）

这只是另一个惯例——人们可能会问，为什么类名总是以大写字母开头，或者方法名总是以小写字母开头，然后以驼峰字母开头。Java不会强迫您以这种方式使用。只是一组带下划线的规则有助于作为Java开发人员的广大社区为大多数遵循约定的人编写易于理解的代码

---

没有明确的理由可以这样说。这正是当时大多数程序员在编写约定时感觉良好并付诸实践的东西。但是，是的，在编写约定之前，指导原则肯定会存在。我不是说这是一部异想天开的作品。制定指导原则的目的是，只要看一下各种元素，我们就应该能够知道它的类、方法或包——通过以下约定，它已经实现了这么久。

True@Jon！同样，以大写字母开头的类名也是如此。因此，基本上，以小写字母开头的包子部分名称和大写字母后面的单词（如方法）将不会与类发生冲突，只要它们都以大写字母开头，对吗？：），但最重要的是，这将是唯一与之相关的有问题的冲突，因为我看不到包子部分名称与方法名称冲突…包名称也与文件系统目录一起使用，文件系统目录通常对大小写本身有限制。谁使用不支持大写的文件系统？您有ext3、NTFS或mac之类的东西，我们不再是九十年代的“为了避免与类名冲突”->您不能将com.site.myName与类名混淆，因为在类的情况下，它将是com.site.myName（以大写字母开头）。因此，没有任何逻辑支持“我的名字”方法。我认为“我的名字”更好，因为它更容易阅读。例如，“com.marvel.movies.gardiansofthegalaxy”理论上是的。但实际上并非如此。很遗憾，这只是一个惯例。我来这里是因为我需要更改我同事的代码，他使用了一个包名，格式为

company.AppName.something.else

。一旦允许使用大写字母，就会有人错误地使用它们。如果我现在想添加一个class

company.AppName

，我需要重命名整个包——不管怎样，我迟早都会这么做的顺便说一句，remoteFileSystemSynchronization对于包名来说不是有点太长了吗？在你的例子中，AppName并不像@joro所说的那样低（在你的例子中，我可能会扼杀创建AppName的人，就像我想扼杀我们公司中创建以小写开头的类的人一样…）。我是开发人员中的一员，他们认为com.pany.app.tableOfContents比com.pany.app.tableOfContents（或com.pany.app.toc）更容易阅读。而com.pany.app.table.of.contents则更糟糕……可能是重复的No，这不是重复的No，因为在本文中，我对这些约定的原因很感兴趣。