违反Java泛型命名约定？ [重复]

问题描述

| 这个问题已经在这里有了答案：

解决方法

自1990年代中期以来，我开始反对使用单字符约定。我发现可读性更好的名称。这有助于理解泛型类型的实现和接口。对于Java，歧义性问题似乎被夸大了。几乎没有全大写的类名。常量与类名不在同一上下文中使用。确实，@ param JavaDoc元素可以提供更长的描述。但是，JavaDoc不一定是可见的也是正确的。（例如，Eclipse中有一个内容助手，它显示类型参数名称。）例如，比较：

public final class EventProducer<L extends IEventListener<E>,E> 
    implements IEventProducer<L,E> {

至：

public final class EventProducer<LISTENER extends IEventListener<EVENT>,EVENT> 
    implements IEventProducer<LISTENER,EVENT> {

尽管Sun / Oracle已建议将单字符名称作为约定，但可以更改约定。挑战该公约的后果很小。如果您和您的团队更喜欢使用有意义的名称作为类型参数，那么我个人会这样做。编辑（2015） Google Java样式允许以T结尾的单字母名称和类似多字符类的名称。 5.2.8类型变量名称每个类型变量以两种样式之一命名：单个大写字母，可选后跟单个数字（例如E，T，X，T2）以类的形式使用名称（请参阅第5.2.2节，类名称），后跟大写字母T（例如：RequestT， FooBarT）。 , 我想知道是否可以（应该）打破Java命名约定来做到这一点：不，应避免这种情况，因为它会更容易将类型参数与常量和其他标识符混淆。这是来自官方关于仿制药的引用：类型参数命名约定按照约定，类型参数名称是单个大写字母。这与您已经知道的变量命名约定形成了鲜明的对比，并且有充分的理由：如果没有该约定，将很难分辨类型变量与普通类或接口名称之间的区别。最常用的类型参数名称为： E-元素（由Java Collections Framework广泛使用） K-键 N-数 T-类型 V-价值 S，U，V等-第二，第三，第四类型您将看到在Java SE API和本教程其余部分中使用的这些名称。 ,在C＃中，使用TDescription非常普遍。它既保留T名称，又同时具有描述性，如下所示：

public interface FindByNamedQuery<
    TEntityType extends Serialiazble,TReturnedContainer extends Collections<TEntityType>> extends Command 
{     
    TReturnedContainer executeNamedQuery(String namedQuery); 
}

正如其他人所说，“ 11”几乎总是表示一个常数。 IMO，“很难说出类型变量与普通类或接口名称之间的区别。”在这里不适用，因为T前缀很容易将其标识为类型变量。同样，这是C＃，但请参见MSDN：泛型命名约定在其他所有情况下，官方 Microsoft通用准则命名约定为：用描述性名称命名通用类型参数，除非使用单个名称字母名称完全是自己的说明性和描述性名称不会增加价值。

public interface ISessionChannel<TSession> 
{...}

public delegate TOutput Converter<TInput,TOutput>(TInput from);

考虑以参数名称指示对类型参数施加的约束。例如，约束到ISession的参数可以称为TSession。 ,编译器可能不会抱怨，但是您的队友可能不会在您期望类型参数的地方使用看起来像常量的东西来欣赏您。 ,我认为这是许多使用泛型的人的抱怨。我不太同意Sun的说法，即如果您使用完整的名称，那么它将与现有的类名或其他名称混淆。在这种情况下，我们可以用这样的美元开头的占位符名称：

public class HashMap<$Key,$Value> implements Map<$Key,$Value>{}

在他们理智的头脑中，没有人说出一个以美元符号开头的课程。而且美元符号还用于表示占位符，其中包含许多模板语言，速度，支撑，弹簧等。我认为这是要走的路。我对此有更多详细信息，并且如果有人感兴趣，不必在我的博客文章中使用单个字母符号即可。 http://readsethu.wordpress.com/2012/05/23/a-generic-class-and-why-is-it-confusing/ ,像以前的Allen一样，我的建议更多来自C＃（自5个月以来我广泛使用），而不是Java（我曾经玩过，但从未走过这么远……），但是我发现Java和C＃代码在本质上非常相似（也就是说，与C ++进行比较时）无论如何，当在简单类型上使用C＃/ Java泛型（或C ++模板）时，我通常使用T：

// C++
template<typename T>
class MyClass { /* ... */ } ;
// C#
public MyClass<T> { /* etc. */ }
// Java
public MyClass<T> { /* etc. */ }

通常，类型T与类一起使用，因此无需对其进行更多描述。但是，当真正描述类型会增加代码的清晰度时，我会这样做。或者，当我在相同的泛型/模板声明中有两个或多个类型时，这有助于使两种类型之间有所不同。例如（C＃中的现实示例）：

// C++
template<typename T_Data,typename T_Underlying>
class MyClass { /* ... */ } ;
// C#
public MyClass<T_Data,T_Underlying> { /* etc. */ }
// Java
public MyClass<T_Data,T_Underlying> { /* etc. */ }

这样，很容易在代码中区分两个类型名，其中T和U很好...有点匿名：对于使用Visual C ++的用户，请在Dinkumware的STL代码中进行调试，其中包含T，_U和其他单字母类型名称可能非常令人沮丧...我想对于C＃或Java代码也是如此。您会注意到，在每种情况下（C ++，Java或C＃），我都不遵循类型命名中的约定：原因是有时，即使您遵循其他规则，也不必尝试其他做法，即使最后，您会发现自己错了。在当前情况下，违反命名约定并不重要（Java中有比这种小小的犯罪还严重的问题），最后，您将亲自了解为什么它是错误的，而不是引用旧文档。如果最后发现您是对的，那么... ,我会在驼峰式命名法中命名与类型类似的类型变量，但以\“ _ \”为前缀。

public interface FindByNamedQuery
    <_EntityType extends Serialiazble,_ReturnedContainer extends Collections<_EntityType>> 
    extends Command 
{
    _ReturnedContainer executeNamedQuery(String namedQuery);
}

java java 命名泛型约定约定违反重复

违反Java泛型命名约定？ [重复]

问题描述

解决方法

相关问答