Programming

Java에 대한 제네릭 형식 매개 변수 명명 규칙 (여러 문자 포함)?

procodes 2020. 7. 19. 18:23
반응형

Java에 대한 제네릭 형식 매개 변수 명명 규칙 (여러 문자 포함)?


일부 인터페이스에서는 코드를 더 읽기 쉽도록 하나 이상의 문자로 일반 유형 매개 변수의 이름을 지정하고 싶습니다.

뭔가 ....

Map<Key,Value>

이 대신에 ...

Map<K,V>

그러나 메소드와 관련하여 type-parameters는 혼란스러워하는 Java 클래스처럼 보입니다.

public void put(Key key, Value value)

이것은 Key와 Value가 클래스 인 것처럼 보입니다. 나는 몇 가지 표기법을 발견하거나 생각했지만 Sun의 관습이나 일반적인 모범 사례와 같은 것은 없습니다.

내가 추측하거나 찾은 대안 ...

Map<KEY,VALUE>
Map<TKey,TValue>

Oracle은 Java Tutorials> Generics> Generic Types 에서 다음을 권장합니다 .

유형 매개 변수 명명 규칙

관례 적으로, 유형 매개 변수 이름은 단일 대문자입니다. 이것은 이미 알고 있는 변수 이름 지정 규칙 과 뚜렷한 대조를 이룹니다 .이 규칙이 없으면 형식 변수와 일반 클래스 또는 인터페이스 이름의 차이를 구분하기가 어렵습니다.

가장 일반적으로 사용되는 유형 매개 변수 이름은 다음과 같습니다.

  • E-요소 (Java Collections Framework에서 광범위하게 사용)
  • K-키
  • N-숫자
  • T 형
  • V-가치
  • S, U, V 등-2 차, 3 차, 4 차 유형

이 이름은 Java SE API 및이 학습의 나머지 부분에서 사용됩니다.

개발자와 가능한 관리자 사이의 혼란을 피하기 위해 그것을 고수했습니다.


추가 Type

DZone 페이지의 매개 변수화 된 유형에 대한 명명 규칙에 대한 주석에서 좋은 토론을 찾을 수 있습니다 .

Erwin Mueller의 코멘트를 참조하십시오. 그의 제안은 나에게 완벽한 분명 의미가 있습니다 : 단어를 추가합니다Type .

사과는 사과, 자동차는 자동차라고 부릅니다. 문제의 이름은 데이터 유형의 이름입니다. (에서 OOP는 , 클래스는 기본적으로 새로운 데이터 유형을 정의합니다.) 그래서 "형"이라고 부른다.

원래 게시물의 기사에서 가져온 뮬러의 예 :

public interface ResourceAccessor <ResourceType, ArgumentType, ResultType> {
    public ResultType run (ResourceType resource, ArgumentType argument);
}

추가 T

중복 질문은 Andy Thomas 의이 답변제공합니다 . 여러 문자 유형 이름이 단일 대문자로 끝나야한다고 제안하는 Google 스타일 가이드에서 발췌 한 내용을 참고하십시오 T.


예, 클래스 이름과 명확하게 구별되는 한 유형 변수에 여러 문자 이름을 사용할 수 있습니다.

이것은 2004 년에 제네릭을 도입하면서 Sun이 제안한 규칙과 다릅니다.

  • 하나 이상의 규칙이 존재합니다.
  • 다중 문자 이름은 Google의 Java 스타일과 같은 다른 Java 스타일과 일치 합니다.
  • 읽을 수있는 이름은 (놀람!) 더 읽기 쉽습니다.

가독성

일부 인터페이스에서는 코드를 더 읽기 쉽도록 두 개 이상의 문자로 일반 유형 매개 변수의 이름을 지정하고 싶습니다.

가독성이 좋습니다.

비교:

    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> {

또는 Google의 다중 문자 규칙을 사용하여 :

    public final class EventProducer<ListenerT extends IEventListener<EventT>,EventT> 
           implements IEventProducer<ListenerT, EventT> {

    public final class EventProducer<ListenerT extends IEventListener<EventT>,EventT> 
           implements IEventProducer<ListenerT, EventT> {

구글 스타일

구글 자바 스타일 가이드가 있습니다 단일 문자 이름과 멀티 문자 클래스와 같은 T.로 끝나는 이름을 모두

5.2.8 타입 변수 이름

각 유형 변수는 두 가지 스타일 중 하나로 이름이 지정됩니다.

  • 임의로 하나의 번호 뒤에 단일 대문자 (예컨대 E, T, X, T2)

  • A name in the form used for classes (see Section 5.2.2, Class names), followed by the capital letter T (examples: RequestT, FooBarT).

Issues

“Without this convention, it would be difficult to tell the difference between a type variable and an ordinary class or interface name.” – from the Oracle tutorials, “Generic types”

Single-character names are not the only way to distinguish type parameters from class names, as we’ve seen above.

Why not just document the type parameter meaning in the JavaDoc?

It’s true that the @param JavaDoc elements can provide a longer description. But it’s also true that the JavaDocs are not necessarily visible. (For example, there’s a content assist in Eclipse that shows the type parameter names.)

Multi-character type parameter names don’t follow the Oracle convention!

Many of Sun’s original conventions are followed nearly universally in Java programming.

However, this particular convention is not.

The best choice among competing conventions is a matter of opinion. The consequences of choosing a convention other than Oracle’s in this case are minor. You and your team can choose a convention that best meets your needs.


You can use javadoc to at least give users of your generic class a clue. I still don't like it (I agree with @chaper29) but the docs help.

eg,

/**
 * 
 * @param <R> - row
 * @param <C> - column
 * @param <E> - cell element
 */
public class GenericTable<R, C, E> {

}

The other thing I have been known to do is use my IDE to refactor a class breaking the convention. Then work on the code and refactor back to single letters. Makes it easier for me anyway if many type parameters are used.


The reason why the official naming convention reccommends using single letter is the following:

Without this convention, it would be difficult to tell the difference between a type variable and an ordinary class or interface name.

I think with modern IDEs that reason is no longer valid as eg. IntelliJ Idea shows generic type parameters with different colors than regular classes.

Code with generic type as displayed in IntelliJ Idea 2016.1 Code with generic type as displayed in IntelliJ Idea 2016.1

Because of that distinction I use longer descriptive names for my generic types, with same convention as regular types. I avoid adding prefixes and suffixes such as T or Type as I consider them unnecessary noise and no longer needed to visually distinguish generic types.

Note: As I am not a user of Eclipse or Netbeans, I do not know whether they offers a similliar feature.

참고URL : https://stackoverflow.com/questions/2900881/generic-type-parameter-naming-convention-for-java-with-multiple-chars

반응형