java.io.File 的静态最终字段的命名不标准

发布于 2024-11-02 15:53:08 字数 195 浏览 4 评论 0原文

我正在准备 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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

喜你已久 2024-11-09 15:53:08

从技术上讲,这些都不是常量(请参阅 的定义常量表达式)。常量的值在编译时就已知。我相信大写加下划线的命名约定仅适用于实际常量,而不仅仅是任何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 final field. 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 final fields regardless of whether they're technically constants or not.)

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文