泛型类型参数名称通常包含一个大写字母字符。 如果您开始阅读有关泛型的官方ORACLE文档，则第一个示例是
/*** Generic version of the Box class.* @param <T> the type of the value being boxed*/
public class Box<T> {// T stands for "Type"private T t;public void set(T t) { this.t = t; }public T get() { return t; }
} 通用类型的名称为T 一个字母，意义不大，通常与其他标识符命名样式相对。 它仅广泛用于泛型。 奇怪。 是什么原因呢？
到目前为止，我已经听到了以下论点：
- 一个类或方法不需要很多类型变量名，因此您不会用完ABC的字母。
- 基于这种推理，我们还应该使用一个字符方法名称吗？
- 因为有JavaDoc，所以一个字符不会固有地解释类型不是问题。 您可以解释类型名称的实际含义。
- 而且我们还应该忘记我们所学到的有关干净代码和变量命名的所有内容。
- 具有一个字符的类型名称使它们与变量，方法和类名称以及常量名称区分开。
- 这是一个好点。
- 但是Google Code Style允许您使用多种字符类型的名称。
- 哦是的
然后怎样呢？
如果您不喜欢泛型的单个字符命名，则可以使用_或$前缀来命名它们。 这是您可以在stackoverflow上看到的建议。 至于我：这很奇怪。 使用$可以使我感到“欢欣”，温暖的感觉使我想起了我在编写Perl时的青春。 我不再这样做了，这是有充分理由的。 时代改变了，技术改变了，我改变了。
$通常由编译器和某些代码生成器用来命名生成的字段和方法。 在Java源代码级别上使用$可能会导致某些命名冲突，导致编译器难以找到合适的名称，但是在这方面，当前版本的Java编译器相当容易出错。 他们只是一直尝试通过一些简单的算法来找到一个合适的名称，直到找到一个不会与任何Java源代码名称冲突的名称为止，因此这不会成为问题。
下划线 ：嗯，实际上是我们过去使用的东西，而不是空间。 在旧的矩阵打印机上，下划线字符打印得很差，以至于您无法将其与空格区分开，因此使用多字变量名称是一个丑陋的窍门。 由于名称开头的下划线是一个完全反模式的恕我直言，实际上是使用相同的名称来命名两件事。 几乎就像没有下划线字符一样。
您也可以使用T_前缀，因为这是C ++和C＃中的惯例（我不太熟悉T_前缀，对此我不确定）。 但这和没有T一样丑陋。
我的喜好是使用有意义的名称，并在常量的情况下遵循相同的约定。 例如使用
public final class EventProducer<LISTENER extends IEventListener<EVENT>,EVENT> implements IEventProducer<LISTENER, EVENT> {代替
public final class EventProducer<L extends IEventListener<E>,E> implements IEventProducer<L,E> {即使那是我的个人，高级，专业，专家意见，但我不使用它。 为什么？ 因为我在团队中的企业环境中工作。 使用比官方默认设置更具可读性的内容所获得的收益并不像辩论和分歧所造成的损害那样高。 除此以外，新员工还必须适应当地的风格，而且也要花钱。 使用可用但不是最佳的全局样式比使用良好的局部样式更好。 忍受它。
我们可以走向全球吗？
你可以试试。 这是我最多能说的。 如果最初的建议设定编码标准比1960年代的样式一字母法更好，那将是更好的选择，但这已经是历史了。 损坏已经完成。 而且，这与在OO中引入null的绝妙想法所造成的损害无可比拟。
只要Java仍然存在，我们将只使用一个字符的泛型。 而且由于我快50岁了，所以这段时期比我的寿命更长。 请注意，COBOL仍然有效。 我们应该对Java有所期待。
翻译自: https://www.javacodegeeks.com/2015/05/generics-names.html
方法)
