गुणों का जावेदोक कैसे लिखें?


93

मैं अक्सर अपने आप को एक दुविधा के साथ पाता हूँ जब गुणों के लिए javadoc लिखते हैं / एक "सरल" POJO वर्ग के सदस्यों के लिए केवल गुण और गेटर्स और सेटर (DTO-style) पकड़े होते हैं ...।

1) संपत्ति के लिए javadoc लिखें
या ...
2) पाने वाले के लिए javadoc लिखें

यदि मैं संपत्ति के लिए javadoc लिखता हूं, तो मेरी IDE (ग्रहण) (स्वाभाविक रूप से) यह प्रदर्शित करने में सक्षम नहीं होगी जब मैं बाद में कोड पूरा होने के माध्यम से पीओजेओ तक पहुंचता हूं। और कोई मानक javadoc टैग नहीं है जो मुझे getter-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;  
  }  

इसलिए, मूल रूप से यह सुनना दिलचस्प होगा कि आपके ग्रहण आईडीई होने के बारे में दूसरों को कैसे पता चलता है कि आपके गेटवे की संपत्ति का विवरण आपके जेवार्डोक टिप्पणी की नकल किए बिना है।

अब तक मैं केवल प्रैक्टिस करने के लिए अपना विचार बना रहा हूं, न कि केवल प्रापकों को प्रलेखित करने के लिए। लेकिन यह सबसे अच्छा समाधान की तरह प्रतीत नहीं होता है ...


1
इस पर दिलचस्प चर्चा यहां: stackoverflow.com/questions/1028967/… । ग्रहण / javadoc के बारे में आपसे जो पूछा गया है, उसका उत्तर दिया गया पता।
b.roth

लगता है जैसे उन्होंने निष्कर्ष निकाला कि मैं क्या विचार कर रहा था ... संपत्ति जायदाद को केवल पाने वालों में लिखें।

मुझे एनोटेशन के साथ ऐसा करने का एक तरीका मिला जो ग्रहण में काम करता है और इसे रनटाइम पर भी एकत्र किया जा सकता है, क्या यह एक विकल्प होगा?
कुंभ राशि

प्राइवेट मेंबर्स को क्या चाहिए?
23:11 पर चेरी

ब्ला ब्ला ब्ला का नाम: सबसे अच्छा उदाहरण
रॉड्रिगो एस्पिनोजा

जवाबों:


75

जावदोक्स (-पिरिटिव) का उपयोग करते हुए आप निजी सदस्यों को शामिल कर सकते हैं और फिर उस फ़ील्ड प्रॉपर्टी से लिंक करने के लिए @link का उपयोग कर सकते हैं।

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

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

वैकल्पिक रूप से, यदि आप सभी निजी सदस्यों के लिए Javadoc उत्पन्न नहीं करना चाहते हैं, तो आप सभी गेटर्स को दस्तावेज़ित करने और बसने वालों पर @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 टैग दोनों के साथ प्रयोग किया है .. लेकिन ... कम से कम ग्रहण इसे ठीक से प्रदर्शित नहीं करता है। ग्रहण लिंक को एक ... (ड्रमोल) .... लिंक के रूप में प्रदर्शित करता है .. ताकि सामग्री को देखने के लिए किसी को क्लिक करना पड़े। मैं कोड को पूरा करने (या माउस द्वारा) को सक्रिय करने में सक्षम होना चाहता हूं जब मुझे वास्तव में एक

13
@ केनी - ग्रहण की प्रयोज्यता से अपने JavaDoc प्रथाओं को मॉडल न करें। इसे सही (या पर्याप्त रूप से अच्छा-पर्याप्त) JavaDoc आउटपुट प्राप्त करने के POV से करें। आईडीई बदल जाते हैं, और आज जो कमी हो सकती है उसे कल संबोधित किया जा सकता है (या आप वास्तव में आईडीई को पूरी तरह से बदल सकते हैं।)
luis.espinal

1
@ ल्लिस का @linkअर्थ है एक कड़ी जिसे वास्तविक जावदोक को देखने के लिए क्लिक करना पड़ता है। यह एक ग्रहण प्रयोज्य मुद्दा नहीं है, यह उन javadocs प्रदान करने के लिए गलत समाधान है जिनका उपयोग करना आसान है।
नैट्स

4

लोम्बोक ऐसे कार्यों के लिए बहुत सुविधाजनक पुस्तकालय है।

@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एनोटेशन प्रत्येक निजी क्षेत्र के लिए एक गेटर विधि बनाकर उसे जावाडोक देते हैं।

पुनश्च : पुस्तकालय में कई शांत विशेषताएं हैं जिन्हें आप जांचना चाहते हैं


3

मैं ग्रहण के स्वत: पूर्ण होने के बाद दोनों को सहायता करता हूं।

सबसे पहले, मैं संपत्ति का दस्तावेज:

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

फिर, मैं इसे पाने वाले को कॉपी और पेस्ट करता हूं:

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

ग्रहण के साथ, @ ग्रेट के बयानों में एक स्वत: पूर्णता होती है - इसलिए, मैं शब्द को जोड़ देता हूं, "t" को कम कर देता है, और वाक्य को "t" के साथ कॉपी करता है। मैं तब @return (ग्रहण स्वत: पूर्ण के साथ) का उपयोग करता हूं, वाक्य पेस्ट करता हूं, और फिर वापसी में टी को ऊपर ले जाता हूं। यह तो इस तरह दिखता है:

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

अंत में, मैं उस दस्तावेज़ को सेटर में कॉपी करता हूँ:

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

फिर, मैं इसे संशोधित करता हूं और ग्रहण के स्वत: पूर्ण होने पर आप न केवल @param टैग बल्कि पैरामीटर का नाम भी प्राप्त कर सकते हैं:

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

फिर, मैं कर रहा हूँ। मेरी राय में, यह गतिरोध बहुत आसान बनाता है, लंबे समय में, न केवल खुद को याद दिलाना है कि संपत्ति का पुनरावृत्ति के माध्यम से क्या मतलब है, बल्कि यह भी आसान है कि अगर आप पक्ष जोड़ना चाहते हैं, तो गेट्टर और सेटर में अतिरिक्त टिप्पणियां जोड़ना आसान हो जाता है। प्रभाव (जैसे अशक्त गुणों की अनुमति नहीं है, अपरकेस के लिए तार बदलना, आदि)। मैंने इस उद्देश्य के लिए एक ग्रहण प्लगइन बनाने की जांच की, लेकिन मुझे जेडीटी के लिए उपयुक्त विस्तार बिंदु नहीं मिला, इसलिए मैंने छोड़ दिया।

ध्यान दें कि वाक्य हमेशा T से शुरू नहीं हो सकता है - यह केवल पहला अक्षर है जिसे चिपकाने में अनपेक्षित / पुनर्पूंजीकृत किया जाना है।


23
कॉपी / पेस्ट बुराई है ... और समय लगता है। ये चरण बहुत काम की तरह लगते हैं, और अगर javadoc में परिवर्तन होता है तो आपके पास अपडेट करने के लिए 3 अलग-अलग स्थान होंगे। मुझे नहीं लगता कि एक प्लगइन या तो इसे सही ठहराएगा ... कम से कम, तो प्लगइन को उदाहरण के लिए संपत्ति javadoc को मास्टर मानना ​​होगा और फिर गेटर्स (और सेटर्स) को अधिलेखित करना होगा। जो मैं पूरा करना चाहता हूं वह 1 एकल जगह में javadoc लिखने के लिए है, और उसके बाद दोनों गेटर्स और संपत्ति javadocs समान विवरण मान लें ...

आमतौर पर, गुण अक्सर वह सब नहीं बदलते हैं। और कॉपी और पेस्ट संचालन, ग्रहण के स्वत: पूर्ण होने के साथ, संपत्ति के जावदोक के निर्माण के बाद 30 सेकंड से भी कम समय लगता है।
MetroidFan2002

4
मैं आश्वस्त नहीं हूं ... इस प्रकार की कॉपी / पेस्ट योजना का परिचय IMHO विसंगतियों को जन्म देने के लिए बाध्य है। मुझे बाद में कोड को संपादित करने वाले अन्य रसोइयों (या स्वयं) पर बहुत कम विश्वास है। इसके अलावा, कम से कम अगर आप एक पूर्ण अप-फ्रंट डिज़ाइन नहीं कर रहे हैं, तो javadoc गुण अक्सर परिवर्तन के अधीन होते हैं, कम से कम एक प्रयोगात्मक / डिज़ाइन चरण के दौरान। और javadoc बेहतर क्वालिटी का होगा अगर लिखा जाए तो कोड दिमाग में ताज़ा है ... माफ करना अगर मैं एक whiner की तरह लगता हूं ;-)

1
क्षमा करें, लेकिन संपादन गुण विसंगतियों को जन्म देने के लिए बाध्य है - जिस तरह से आप इसे खेलते हैं, जब तक कि यह कुछ फैशन में बनाए नहीं रखा जाता है, तब तक Javadoc रास्ते से गिर जाता है। यहां तक ​​कि अगर संपत्ति javadoc को उजागर करने का एक आसान तरीका था, तो यह केवल संभावना है कि संपत्ति javadoc खुद को अपडेट नहीं किया जाएगा। यह वास्तव में टीम के कोडिंग सम्मेलनों, आदि और कोड समीक्षाओं की बात है, जैसे सामान - आपके लिए शुभकामनाएं, यह सिर्फ तरीका है जो मैं इसे करता हूं इसलिए मैं भूल नहीं करता।
MetroidFan2002

@Metroid - जब तक कि यह कुछ फैशन में सख्ती से बनाए रखा है - ठीक है, यह माना जाता है कि अगर इसे स्रोत कोड के हिस्से के रूप में माना जाता है, तो इसे सख्ती से बनाए रखा जाना चाहिए । और कोड के आंतरिक भाग के रूप में Javadoc टिप्पणियों (और अन्य भाषाओं में उनके समकक्ष) का इलाज नहीं करना, हालांकि दुख की बात है मानक अभ्यास, यह कई बुराइयों की जड़ है। सबसे खराब टिप्पणी वह है जो दिनांकित हो गई है। सबसे अच्छे रूप में, वे प्रोग्रामर को कोड पर पकड़ बनाने से धीमा कर देते हैं (जैसा कि उन्हें लगातार अमान्य करना पड़ता है और पुरानी टिप्पणी को स्वीकार / अस्वीकार करना पड़ता है।) इससे भी बदतर, वे त्रुटि-प्रवण, बग-परिचय जानकारी देते हैं।
luis.espinal

0

मुझे वास्तव में लगता है कि यह एक समस्या है और आधिकारिक जवादोक गाइड इसके बारे में कुछ नहीं बताता है। C # गुणों के उपयोग के साथ एक सुरुचिपूर्ण तरीके से इसे हल कर सकता है (मैं C # में कोड नहीं करता, लेकिन मुझे वास्तव में लगता है कि यह एक अच्छी सुविधा है)।

लेकिन मेरे पास एक अनुमान है: यदि आपको यह समझाने की आवश्यकता है कि कुछ स्ट्रिंग क्या है, तो शायद यह आपके कोड के बारे में `` बुरा छोटा '' है। इसका मतलब यह हो सकता है कि आपको SomeString टाइप करने के लिए SomeClass लिखना चाहिए, इसलिए आप बताएंगे कि SomeClring प्रलेखन में कुछString क्या है, और बस गेटवे / सेटर में javadocs आवश्यक नहीं होगी।


1
कोड में स्ट्रिंग्स के सही उपयोग के बारे में नहीं, प्रभावी जावा पुस्तक में `` उन स्ट्रिंग्स से बचें जहां अन्य प्रकार अधिक उपयुक्त हैं ''।
लियोनार्डो लेइट
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.