2010-05-25 14 views
5

मुझे मिलने वाली प्रतिक्रिया के आधार पर, मैं अपने सहयोगियों के साथ यह "मानक" बढ़ा सकता हूं। यह कस्टम स्टाइलकॉप नियम बन सकता है। क्या पहले से ही एक लिखा है?क्या .net टिप्पणियां पूंजी पत्र से शुरू होनी चाहिए और अवधि के साथ समाप्त होनी चाहिए?

तो, स्टाइलकॉप पहले ही summary, param, और return दस्तावेज़ टैग के लिए इसे निर्देशित करता है।

क्या आपको लगता है कि टिप्पणियों से इसकी मांग करना समझ में आता है?

संबंधित नोट पर: यदि कोई टिप्पणी पहले से ही लंबी है, तो इसे उचित वाक्य के रूप में लिखा जाना चाहिए?

उदाहरण के लिए (शायद मैं एक बुरा टिप्पणी वर्णन करने के लिए भी बहुत कोशिश की):

//if exception quit 

बनाम

// If an exception occurred, then quit. 

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

//if exception quit 
if (exc != null) 
{ 
    Application.Exit(-1); 
} 

और

// If an exception occurred, then quit. 
if (exc != null) 
{ 
    Application.Exit(-1); 
} 

बेशक, एक एक टिप्पणी बिल्कुल जरूरत नहीं है, लेकिन एक के बाद से प्रदान की जाती है, मुझे लगता है कि एक दूसरे के लिए बेहतर है लगता होगा।

कृपया अपनी राय का बैक अप लें। क्या आपके पास टिप्पणी की कला के लिए अच्छा संदर्भ है, खासकर यदि यह .NET से संबंधित है?

धन्यवाद।

+0

व्यक्तिगत रूप से मैं उन प्रकार की टिप्पणियों को कोड ब्लॉक में डाल दूंगा ताकि यदि कोई मौजूद हो तो आप अन्य स्थिति के लिए टिप्पणी कर सकते हैं। –

उत्तर

5

मैं अक्सर ऐसी टिप्पणियां लिखता हूं जो मुझे कोड के अनुभाग खोजने में मदद करने के लिए हैं। उदाहरण के लिए (मैं भी इस के लिए क्षेत्रों का उपयोग करें।):

// SERVER

क्योंकि आईडीई टिप्पणी colorizes, यह काम समय पर इस तरह कम टिप्पणी है करने के लिए खंडों में मानसिक रूप से अवरुद्ध बातों में सहायता करने के लिए बनाता है। मैं आमतौर पर कोड के केवल एक दर्जन या तो लाइनों के लिए ऐसा करता हूं। यदि यह लंबा है, तो #region बेहतर लगता है।

मैं भी अक्सर नोट मेरी टिप्पणी में, कभी कभी इस तरह खुद के लिए एक संदर्भ के रूप में लिखने:

// NOTE: -273.15 is absolute zero in °C, used for a MinValue below

यह एक व्याकरण की दृष्टि से सुंदर या पूरा वाक्य नहीं है, लेकिन यह समझ में आता है।

मैं कहां से अधिक पूर्ण, संरचित वाक्य का प्रयोग करते हैं, मेरी विधियों में से सारांश में है इस तरह:

/// <summary> 
/// Populates the properties of a Sensor object based on 
/// the XML components of its data file. 
/// </summary> 

उन मुझे लगता है अधिक किसी और के द्वारा पढ़ा जाने की संभावना है और यह शब्दाडंबर करने में मदद करता और साफ स्वरूपण।

+0

+1 सारांश बिट के लिए, यह काफी अच्छा है। मेरे कुछ सहयोगियों ने सभी "पारंपरिक" टिप्पणियों को बाहर करने के लिए रिशेर्पर को सेटअप किया। –

+0

आप अपने कोड में ºs टाइप करते हैं? – igul222

+1

ज़रूर! यह सिर्फ alt + 176 है। मैं अपने काम में एक * बहुत * उस प्रतीक के साथ सौदा! :) – JYelton

2

स्पष्ट, पठनीय, समझने योग्य टिप्पणियां लिखने के लिए समय लेना कभी बर्बाद नहीं होता है। कुछ समय बाद मैंने उन्हें समझने के लिए संघर्ष करने के लिए अपनी टिप्पणियों को कितनी बार पढ़ा है। जो लोग बेवकूफ या बुरी तरह से तैयार टिप्पणियां लिखते हैं वे अक्सर अपने कोड में समान गुणों को लागू करते हैं।

6

कोड एक टिप्पणी की जरूरत है, तो यह अच्छी तरह से गठन किया जाना चाहिए, वहाँ शायद एक (गैर तुच्छ) अवधारणा है कि समझा जरूरत है, क्योंकि IMO।

जैसे आपके उदाहरणों की तरह

तुच्छ टिप्पणियों से बचना चाहिए। वे शोर के अलावा कुछ भी नहीं जोड़ते हैं।

+0

+1 छोटी टिप्पणियों से बचने के बारे में टिप के लिए +1 –

1

यदि आप दृश्य स्टूडियो में विधियों पर टिप्पणी करते हैं तो आपको विधि के शीर्ष पर सारांश और पैरा का उपयोग करने पर विचार करना चाहिए। इस तरह आपके पास कोड पूर्ण होने के दौरान विधि के बारे में विस्तार है। यहाँ एक उदाहरण

/// <summary> 
    /// you summary here 
    /// </summary> 
    /// <param name="param1">Describe parameter usage</param> 
    /// <param name="param2">Describe parameter usage</param> 
+0

ओपी उद्धरण "तो, स्टाइलकॉप पहले से ही संक्षेप में, पैरामीटर, और रिटर्न दस्तावेज टैग के लिए निर्देशित करता है" ... – spender

3

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

सामान्य रूप से, हालांकि, खुद को पूर्ण लिखने के लिए मजबूर करना, उचित वाक्य आपको इस बारे में अधिक सोचने के लिए मजबूर करता है कि आप वास्तव में टिप्पणी के साथ क्या कहने की कोशिश कर रहे हैं। मैंने अक्सर खुद को पुनर्विचार कर लिया है जो मैं वास्तव में इसे पूरी तरह से लिखकर टिप्पणी में शामिल करना चाहता हूं।

ब्रेवटी की वेदी पर स्पष्टता बलिदान करने का कोई अच्छा कारण नहीं है। किसी को भविष्य में कोड को समझने की आवश्यकता होगी। टिप्पणियां उनके लिए हैं, इसलिए उन्हें ग्रोक करना आसान बनाते हैं।

संबंधित मुद्दे