首先，我知道不要在类名中使用美元符号，因为内部类在其 .class 文件名中使用美元符号。我还看到过合成变量名称，例如 this$0 ，所以我倾向于像任何优秀的 Java 程序员一样避免在标识符中使用美元符号。
但是，我发现单字母类型参数，例如 <T>令人反感。例如，如果我正在创建一个具有请求和响应参数的泛型类，我就会遇到命名问题。我应该用什么，<TRequest, TResponse> ？ <R1, R2> ？毛。
我已经开始做 <$Request, $Response> 。它是可读的，它是独特的，我无法想象任何 .class 文件命名冲突。在我看来，让 Java 代码更具可读性似乎是唾手可得的成果。任何 JVM 专家或有洞察力的开发人员都想告诉我为什么这是一个糟糕的主意吗？
编辑:至于可读性，我可能会因为使用其他语言而被吸引，其中变量以美元符号为前缀，而泛型类型是比类类型具有更多可变性质的类型。至于惯例，是的，我是一个粉丝；我想知道这是否可以作为一种惯例，或者是否有一些技术问题会阻止它。
最佳答案
惯例，惯例，惯例。
虽然你可以随心所欲地做，但一般约定可以在 in the Java Trails 找到。 .
The most commonly used type parameter names are:
- E - Element (used extensively by the Java Collections Framework)
- K - Key
- N - Number
- T - Type
- V - Value
- S,U ,V etc. - 2nd, 3rd, 4th types
You'll see these names used throughout the Java SE API...
只有在以下情况下才应打破这些约定:
- 遵循上述协议(protocol)会使通用更加使用起来更加困惑
- 其他合作者可以轻松识别可读性的提升
对于 $，JLS 明确提出了反对的建议 using $ as a generic identifier.
The
$sign should be used only in mechanically generated source code or, rarely, to access pre-existing names on legacy systems.
关于java - 有什么理由不在 Java 类型参数前加上美元符号？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/34322807/