其实这完全是理论上的问题。但有趣的是为什么 java 规范不允许在包中使用大写字母并导致写如下内容:
com.mycompany.projname.core.remotefilesystemsynchronization.*
代替
com.myCompanyName.projName.core.remoteFileSystemSynchronization.*
其实这完全是理论上的问题。但有趣的是为什么 java 规范不允许在包中使用大写字母并导致写如下内容:
com.mycompany.projname.core.remotefilesystemsynchronization.*
代替
com.myCompanyName.projName.core.remoteFileSystemSynchronization.*
直接来自Oracle 文档
包名全部小写,以避免与类名或接口名冲突。
但有趣的是为什么 java 规范不允许在包中使用大写字母并导致写如下内容:
该规范允许它很好。使用全小写只是惯例。
正如 gtgaxiola 所说,这确实避免了与类型名称的冲突......在 .NET 命名约定中确实会发生这种情况,导致建议您不要将类命名为与其 namespace 相同的名称。当然,使用 camelCase 包可以完全避免冲突。
我怀疑现实是在创建包命名约定时没有彻底考虑它。就我个人而言,我很少发现它是一个问题——如果我最终看到一个包含“remotefilesystemsynchronization”元素的包,那么大写并不是我关心的主要问题:)
它只是另一种约定——有人可能会问为什么类名总是必须以大写开头,或者方法名以小写开头,然后是驼峰式。Java不会强迫您使用这种方式。只是一组带下划线的规则有助于作为 Java 开发人员的庞大社区为大多数遵循约定的人编写易于理解的代码。
没有明确的理由可以这样分配。这正是当时大多数程序员在编写约定时感觉良好并且在实践中所使用的。但是是的,在编写约定之前肯定会有指导方针。我并不是说它是一个异想天开的作品。制定指南以便仅通过查看各种元素,我们就应该能够判断它的类、方法或包 - 并且通过遵循约定,它现在已经实现了很长时间。