java.io.File 的静态最终字段的命名不标准
我正在准备 SCJP 并观察到有趣的事情。
常量不遵循 Sun 命名约定：
File.separatorChar
File.separator
File.pathSeparatorChar
File.pathSeparator
如何解释？
也许是一些历史问题或者只是拼写错误？
I'm preparing to SCJP and have observed interesting thing.
Sun naming conventions are not followed for constants:
File.separatorChar
File.separator
File.pathSeparatorChar
File.pathSeparator
How it can be explained?
Perhaps, some historical issue or just typo?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
从技术上讲，这些都不是常量（请参阅 的定义常量表达式）。常量的值在编译时就已知。我相信大写加下划线的命名约定仅适用于实际常量，而不仅仅是任何
static final字段。至于为什么它们不是常量，它们当然依赖于文件系统，并且必须在运行时查找当前文件系统。（不过，在 Java 代码中，对所有
static final字段使用相同的命名约定是很常见的，无论它们在技术上是否是常量。）None of those are constants, technically (see the definition of a constant expression). A constant's value is known at compile time. I believe that the uppercase-with-underscores naming convention only applies to actual constants and not just any
static finalfield. As to why they aren't constants, they are of course file system dependent and have to be looked up for the current file system at runtime.(It is, though, very common in Java code to use the same naming convention for all
static finalfields regardless of whether they're technically constants or not.)