속성의 Javadoc을 작성하는 방법?


93

속성과 getter 및 setter (DTO 스타일) 만 보유하는 "간단한"POJO 클래스의 속성 / 멤버에 대한 javadoc을 작성할 때 종종 딜레마가 발생합니다 ....

1) 속성에 대한 javadoc 작성
또는 ...
2) getter에 대한 javadoc 작성

속성에 대한 javadoc을 작성하면 나중에 코드 완성을 통해 POJO에 액세스 할 때 내 IDE (Eclipse)가 (당연히) 이것을 표시 할 수 없습니다. 그리고 getter-javadoc를 실제 속성 javadoc에 연결할 수있는 표준 javadoc 태그가 없습니다.

예 :

public class SomeDomainClass {

  /**
   * The name of bla bla bla
   */
  private String name;

  /**
   * @return INSERT SOME SMART JAVADOC TAG LINKING TO name's javadoc
   */
  public String getName() {  
    return name;  
  }  

따라서 기본적으로 javadoc 주석을 복제하지 않고도 Eclipse IDE가 getter에 대한 javadoc 속성 설명을 표시하도록하는 방법을 다른 사람들이 듣는 것은 흥미로울 것입니다.

지금은 속성이 아닌 게터 만 문서화하는 연습을 고려하고 있습니다. 하지만 최선의 해결책은 아닌 것 같습니다 ...


1
이것에 대한 흥미로운 토론 : stackoverflow.com/questions/1028967/… . 수락 된 답변은 Eclipse / javadoc에 대해 질문 한 내용을 다룹니다.
b.roth

그들이 내가 고려한 것으로 결론을 내린 것 같습니다 ... getter에서만 속성 javadoc을 작성하십시오.

이클립스에서 작동하고 런타임에 수집 할 수있는 주석으로이 작업을 수행하는 방법을 찾았습니다. 옵션이 될까요?
Aquarius Power

개인 회원은 javadoc이 필요합니까?
teon

BLA BLA BLA의 이름 : 좋은 예
로드리고 에스피 노자

답변:


76

Javadocs를 생성하는 동안 (-private 사용) 개인 구성원을 포함시킨 다음 @link를 사용하여 해당 필드 속성에 연결할 수 있습니다.

public class SomeDomainClass {
    /**
     * The name of bla bla bla
     */
    private String name;

    /**
     * {@link SomeDomainClass#name}
     */
    public String getName() {
        return name;
    }
}

또는 모든 개인 멤버에 대해 Javadoc을 생성하지 않으려면 모든 getter를 문서화하고 setter에서 @link를 사용하는 규칙을 가질 수 있습니다.

public class SomeDomainClass {
    private String name;

    /**
     * The name of bla bla bla
     */
    public String getName() {
        return name;
    }

    /**
     * {@link SomeDomainClass#getName}
     */
    public void setName(String name) {
        this.name = name;
    }
}

2
@link와 @see 태그를 모두 실험했습니다.하지만 ... 적어도 Eclipse는 이것을 제대로 표시하지 않습니다. Eclipse는 링크를 ... (드럼 롤) .... 링크로 표시합니다. 링크는 내용을보기 위해 클릭해야합니다. 실제로 getter를 검색 할 때 속성에 대한 javadoc을 가져 오거나 코드 완성을 활성화 할 수 있기를 원합니다 ...

13
@Kenny-Eclipse의 사용성 관점에서 JavaDoc 사례를 모델링하지 마십시오. 올바른 (또는 충분히 좋은) JavaDoc 출력을 얻는 POV에서 수행하십시오. IDE가 변경되고 오늘 부족한 부분이 내일 해결 될 수 있습니다 (또는 실제로 IDE를 완전히 변경할 수 있습니다.)
luis.espinal 2011 년

1
@luis @link는 실제 javadoc을 보려면 클릭 해야하는 링크를 의미합니다. Eclipse 사용성 문제가 아니라 사용하기 쉬운 javadocs를 제공하는 잘못된 솔루션입니다.
NateS

4

Lombok 은 이러한 작업에 매우 편리한 라이브러리입니다.

@Getter
@Setter
public class Example {
    /**
     * The account identifier (i.e. phone number, user name or email) to be identified for the account you're
     * requesting the name for
     */
    private String name;
}

그게 전부입니다! @Getter주석은 각 개인 필드에 대한 getter 메소드를 생성하고 여기에 javadoc에 연결합니다.

추신 : 라이브러리에는 체크 아웃하고 싶을 수있는 멋진 기능이 많이 있습니다.


3

Eclipse의 자동 완성 기능을 사용하여 둘 다 수행합니다.

먼저 속성을 문서화합니다.

/**
 * The {@link String} instance representing something.
 */
private String someString;

그런 다음 이것을 복사하여 getter에 붙여 넣습니다.

/**
 * The {@link String} instance representing something.
 */
public String getSomeString() {
    return someString;
}

eclipse를 사용하면 @return 문에 자동 완성 기능이 있으므로 Gets라는 단어를 추가하고 "t"를 소문자로하고 소문자 "t"로 문장을 복사합니다. 그런 다음 @return (Eclipse 자동 완성 사용)을 사용하고 문장을 붙여 넣은 다음 리턴에서 T를 대문자로 사용합니다. 그러면 다음과 같이 보입니다.

/**
 * Gets the {@link String} instance representing something.
 * @return The {@link String} instance representing something.
 */
public String getSomeString() {
    return someString;
}

마지막으로 해당 문서를 setter에 복사합니다.

/**
 * Gets the {@link String} instance representing something.
 * @return The {@link String} instance representing something.
 */
public void setSomeString(String someString) {
    this.someString = someString;
}

그런 다음 수정하고 Eclipse 자동 완성을 사용하면 @param 태그뿐만 아니라 매개 변수 이름도 얻을 수 있습니다.

/**
 * Sets the {@link String} instance representing something.
 * @param someString The {@link String} instance representing something.
 */
public void setSomeString(String someString) {
    this.someString = someString;
}

이제 끝났습니다. 내 생각에이 템플릿은 반복을 통해 속성이 의미하는 바를 기억할 수있을뿐만 아니라 측면을 추가하려는 경우 getter 및 setter에 추가 주석을 더 쉽게 추가 할 수 있도록 장기적으로 훨씬 쉽게 만듭니다. 효과 (예 : null 속성 허용 안 함, 문자열을 대문자로 변경 등). 이 목적을 위해 Eclipse 플러그인을 만드는 것을 조사했지만 JDT에 대한 적절한 확장 점을 찾을 수 없어 포기했습니다.

문장이 항상 T로 시작하는 것은 아닙니다. 붙여 넣을 때 첫 글자 만 대문자로 표시하거나 다시 대문자로 표시해야합니다.


24
복사 / 붙여 넣기는 사악하고 시간이 많이 걸립니다. 이 단계는 많은 작업처럼 보이며 javadoc이 변경되면 3 개의 다른 위치를 업데이트 할 수 있습니다. 나는 플러그인이 이것을 정당화 할 것이라고 생각하지 않는다. 적어도 플러그인은 예를 들어 javadoc 속성을 마스터로 간주하고 getter (및 setter)를 덮어 써야한다. 내가 달성하고 싶은 것은 한 곳에서 javadoc을 작성하고 getter와 속성 javadocs가 동일한 설명을 가정하도록하는 것입니다 ...

일반적으로 속성은 자주 변경되지 않습니다. 그리고 Eclipse의 자동 완성 기능을 사용하는 복사 및 붙여 넣기 작업은 Javadoc 속성이 생성 된 후 30 초도 채 걸리지 않습니다.
MetroidFan2002 2010

4
나는 확신하지 못한다 ... 이런 유형의 복사 / 붙여 넣기 방식의 도입은 IMHO가 불일치를 초래할 수밖에 없다. 나는 나중에 코드를 편집하는 다른 요리사 (또는 나 자신)에 대한 믿음이 거의 없습니다. 또한 최소한 완전한 선행 설계가없는 경우 javadoc 속성은 적어도 실험 / 설계 단계에서 변경 될 수 있습니다. 그리고 코드가 신선 할 때 작성하면 javadoc의 품질이 더 좋아질 것입니다 ... 내가 우는 소리처럼 보이면 죄송합니다 ;-)

1
죄송합니다. 속성을 편집 하면 불일치가 발생할 수 있습니다. 어떤 방식 으로든 강력하게 유지 관리하지 않는 한 Javadoc은 어떤 방식 으로든 실패하는 경향이 있습니다. javadoc 속성을 노출하는 쉬운 방법이 있더라도 javadoc 속성 자체가 업데이트되지 않을 가능성이 높습니다. 정말 팀의 코딩 규칙과 코드 리뷰의 문제입니다. 행운을 빕니다. 이것이 제가하는 일이기 때문에 잊지 마세요.
MetroidFan2002 2010

@Metroid- 어떤 방식으로 강력하게 유지되지 않는 한 -음 , 소스 코드 자체의 일부로 취급 된다면 강력하게 유지되어야 합니다. 그리고 Javadoc 주석 (및 다른 언어의 주석)을 코드의 본질적인 부분으로 취급하지 않는 것은 슬프게도 표준 관행이지만 많은 악의 근원입니다. 최악의 댓글은 구식이 된 댓글입니다. 기껏해야 프로그래머가 코드에 대한 이해를 늦출 수 있습니다 (오래된 주석을 지속적으로 재 검증하고 승인 / 거부해야하므로). 더 나쁜 경우에는 오류가 발생하기 쉽고 버그를 유발하는 정보를 제공합니다.
luis.espinal 2011-08-09

0

나는 그것이 문제라고 생각하며 공식 Javadoc 가이드 는 그것에 대해 아무것도 말하지 않습니다. C #은 속성 사용을 통해 우아한 방식으로이 문제를 해결할 수 있습니다 (C #로 코딩하지는 않지만 정말 멋진 기능이라고 생각합니다).

그러나 나는 추측이 있습니다 : someString이 무엇인지 설명해야한다면 코드에 대한``나쁜 작은 ''일 수 있습니다. SomeClass를 작성하여 someString을 입력해야 함을 의미 할 수 있으므로 SomeClass 문서에서 someString이 무엇인지 설명하고 getter / setter의 javadocs가 필요하지 않습니다.


1
코드에서 문자열을 적절하게 사용하지 않는 것에 대해서는, Effective Java 책에서 "Avoid strings where other types are more appropriate"를 확인하십시오.
Leonardo Leite 2012-06-01
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.