Java에 대한 일반 유형 매개 변수 명명 규칙 (여러 문자 포함)?


125

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

뭔가 ....

Map<Key,Value>

대신에 ...

Map<K,V>

그러나 메소드에 관해서는 유형 매개 변수가 자바 클래스처럼 보이며 혼란 스럽습니다.

public void put(Key key, Value value)

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

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

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

9
왜 새로운 대회를 만들고 싶습니까?
Amir Afghani

13
@AmirAfghani 질문에서 : 코드를 더 읽기 쉽게 만듭니다.
SantiBailors 2015 년

기술적으로 IDE에있는 제네릭의 다양한 색상이 충분한 지표 역할을해야합니다
Sudix

답변:


182

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

유형 매개 변수 명명 규칙

규칙에 따라 유형 매개 변수 이름은 단일 대문자입니다. 이것은 이미 알고 있는 변수 명명 규칙 과는 뚜렷한 대조를 이루며 그럴만 한 이유가 있습니다.이 규칙이 없으면 형식 변수와 일반 클래스 또는 인터페이스 이름의 차이를 구분하기 어려울 것입니다.

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

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

Java SE API 및이 단원의 나머지 부분에서 이러한 이름이 사용되는 것을 볼 수 있습니다.

나는 개발자와 가능한 유지 보수 자들 사이의 혼란을 피하기 위해 그것을 고수 할 것입니다.


14
새로운 스트림 프레임 워크는 R결과 및 A누산기 에도 사용 합니다 .
vandale

32
Blech, 단일 문자 이름 지정. 관습이 설명적인 이름보다 더 중요하기 때문에이 관습을 따르지만 이것이 그들이 생각 해낼 수있는 최선이라는 것이 슬프다.
warbaker 2014 년

4
@warbaker : 매개 변수화 된 유형을 실제 클래스와 구별하는 좋은 방법입니다. 예를 들어 Elementin List<Element>이 매개 변수화 된 유형인지 클래스 인지 어떻게 알 수 있습니까?
BalusC

1
BiFunction<T, U, R>이 규칙을 따르는 것 같지 않습니다 . 그랬다면 BiFunction<T, S, R>.
michaelsnowden

4
매개 변수화 된 유형을 실제 클래스와 구별하는 것이 왜 걱정입니까? 그들은 있는 클래스. 무엇이든 파일의 어딘가에서 위로 스크롤하여 정의 된 내용을 찾아야합니다. 그리고 가져 오기 또는 매개 변수화 된 유형입니다.
Vectorjohn

47

추가 Type

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

Erwin Mueller의 의견을 참조하십시오. 그의 제안은 나에게 완벽하게 분명하게 이해가됩니다. Append the wordType .

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

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

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

추가 T

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


3
나는이 대답을 좋아한다. "유형"을 추가하는 것은 매우 명확하며 설명적인 이름을 가질 수 있습니다. 나는 다른 정당화없이 "이건 컨벤션이기 때문에해라"라고 말하는 사람들이 지겨워 요. 그것이 나쁜 관습이라면 새 관습이 필요할 수도 있습니다.
Drew

16

공식 명명 규칙에서 단일 문자 사용을 권장하는 이유 는 다음과 같습니다.

이 규칙이 없으면 유형 변수와 일반 클래스 또는 인터페이스 이름의 차이를 구분하기 어려울 것입니다.

현대 IDE에서는 이유가 더 이상 유효하지 않다고 생각합니다. IntelliJ Idea는 일반 클래스와 다른 색상으로 일반 유형 매개 변수를 표시합니다.

IntelliJ Idea 2016.1에 표시된 일반 유형의 코드 IntelliJ Idea 2016.1에 표시된 일반 유형의 코드

이러한 구별 때문에 일반 유형과 동일한 규칙으로 일반 유형에 대해 더 긴 설명 이름사용 합니다. T 또는 Type과 같은 접두사 및 접미사를 불필요한 노이즈로 간주하고 더 이상 제네릭 유형을 시각적으로 구분할 필요가 없기 때문에 추가하지 않습니다.

참고 : Eclipse 또는 Netbeans 사용자가 아니기 때문에 유사한 기능을 제공하는지 여부를 알 수 없습니다.


각 사람이 같은 파일을 읽고 수정하는 도구의 가정 된 기능을 기준으로 명명 규칙을 사용하지 않습니다. 개인적으로 IDE가 아닌 코딩 (Sublime Text)에 텍스트 편집기를 사용하고 싶습니다. 텍스트 편집기는 일반적으로 구문 색상이 있지만 유형 변수 이름의 색상을 올바르게 지정하는 데 필요한 기본 코드 구조에 대한 깊은 이해는 없습니다. 색에 대한이 주장의 근거는 본질적으로 색각이 좋지 않은 사람들에게 배타적입니다 (저는
적녹

1
색각이 나쁜 사람들에게 좋은 점입니다. IDE를 사용하지 않는 것과 관련하여 사람들이 간단한 텍스트 편집기를 선호하는 경우 괜찮지 만 더 가벼운 도구를 위해 IDE가 제공하는 기능을 자발적으로 희생합니다. 이것은 누락 된 기능 중 하나 일 수 있습니다. 결국 한 글자 대신 설명적인 이름을 사용하면 IDE없이 색상 코딩없이 이름을 기반으로 의미를 알 수 있어야합니다. 색상 코딩은 이것을 더 빠르게 만듭니다.
Vojtech Ruzicka

16

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

이것은 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> {

Google 스타일

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

5.2.8 유형 변수 이름

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

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

  • 클래스에 사용되는 형식의 이름 (섹션 5.2.2, 클래스 이름 참조) 뒤에 대문자 T가옵니다 (예 : RequestT, FooBarT).

이슈

"이 규칙이 없으면 유형 변수와 일반 클래스 또는 인터페이스 이름의 차이를 구분하기 어려울 것입니다." – Oracle 자습서에서 "일반 유형"

위에서 살펴본 것처럼 단일 문자 이름이 유형 매개 변수를 클래스 이름과 구별하는 유일한 방법은 아닙니다.

JavaDoc에서 의미하는 유형 매개 변수를 문서화하지 않는 이유는 무엇입니까?

@paramJavaDoc 요소가 더 긴 설명을 제공 할 수 있다는 것은 사실입니다 . 그러나 JavaDocs가 반드시 표시되지 않는 것도 사실입니다. (예를 들어, 유형 매개 변수 이름을 표시하는 컨텐츠 지원이 Eclipse에 있습니다.)

다중 문자 유형 매개 변수 이름은 Oracle 규칙을 따르지 않습니다!

Sun의 많은 원래 규칙은 Java 프로그래밍에서 거의 보편적으로 따릅니다.

그러나이 특별한 관습은 그렇지 않습니다.

경쟁 관례 중 최선의 선택은 의견의 문제입니다. 이 경우 Oracle이 아닌 다른 규칙을 선택하는 결과는 미미합니다. 귀하와 귀하의 팀은 귀하의 필요에 가장 적합한 대회를 선택할 수 있습니다.


15

javadoc을 사용하여 최소한 일반 클래스의 사용자에게 단서를 제공 할 수 있습니다. 나는 여전히 그것을 좋아하지 않지만 (@ chaper29에 동의합니다) 문서가 도움이됩니다.

예 :

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

}

내가 알려진 다른 일은 내 IDE를 사용하여 규칙을 위반하는 클래스를 리팩토링하는 것입니다. 그런 다음 코드를 작업하고 단일 문자로 다시 리팩터링합니다. 어쨌든 많은 유형 매개 변수가 사용되는 경우 더 쉽게 만듭니다.


1
유형 매개 변수에 대한 Javadoc 주석은 일반적으로 필수라고 말하고 싶습니다.
migu
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.