कोई भी .NET '#region निर्देश' सम्मेलन विचार?

Question

मैं वास्तव में आपके कोड में क्षेत्रों को परिभाषित करने की संभावना की सराहना करता हूं, क्योंकि यह पठनीयता को बेहद कम करता है।

• निजी फील्ड्स
• कंस्ट्रक्टर्स
• कक्षा गुण:

  फिर भी, मैं ही सम्मेलन की तरह सभी वर्गों में उपयोग करते हुए (सभी क्षेत्रों के पूर्वनिर्धारित क्रम के साथ) हर किसी को करना चाहते हैं

• ईवेंट हैंडलर्स
• आदि ...

क्या आपके पास कोई प्रस्ताव है कि यह विभाजन कैसा दिख सकता है (किन क्षेत्रों में समझ है और उनके नाम क्या हैं) और किस क्रम में उन्हें परिभाषित किया जाना चाहिए?

Answer 1

मेरा सम्मेलन उनका उपयोग नहीं करना है।

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

Answer 2

एक बार किसी ने कहा कि उपरोक्त के समान एक सम्मेलन होने:

• निजी फील्ड्स
• कंस्ट्रक्टर्स
• कक्षा गुण
• ईवेंट हैंडलर्स
• आदि ...

एक टेबल स्थापित करने जैसा है जहां सभी प्लेटें एक साथ हैं, सभी चम्मच एक साथ हैं, सभी चाकू एक साथ हैं और सभी कांटे एक साथ हैं।

#region समस्या पर मेरा लेना संबंधित तरीकों, घटना परिभाषाओं और गुणों को एक क्षेत्र में एक साथ रखना है। हालांकि, ऐसा करने के लिए एक कोड गंध इंगित करेगा (या तो आपकी कक्षा बहुत बड़ी है या बहुत सी चीजें करता है) लेकिन यह बेहतर वर्ग में इसे पुन: सक्रिय करने में एक अच्छा पहला कदम है।

Answer 3

आपको इस do you say no to c# regions में रुचि हो सकती है।

मुझे लगता है कि जब तक आप अपने प्रोजेक्ट में लगातार होते हैं, इससे कोई फर्क नहीं पड़ता कि आप उन्हें किस क्रम में लिखते हैं। साथ ही उन पर अधिक ध्यान देने से सावधान रहें (इसलिए प्रारंभिक लिंक!)।

एक बंद कन्स्ट्रक्टर क्षेत्र खोजने से भी कुछ भी बुरा नहीं है जो कोड की केवल एक पंक्ति छिपा रहा है।

मुझे लगता है कि अंत में यह व्यक्तिगत स्वाद के नीचे है। जैसा कि मैंने कहा है, स्थिरता कुंजी है!

Answer 4

उनके बारे में अन्य टिप्पणियों के रूप में सोचें: आपके कोड के साथ मिश्रित अतिरिक्त जानकारी, जिसमें पर कोई औपचारिक जांच नहीं की गई है। इसलिए यह कोड के साथ तिथि से बाहर निकल जाएगा।

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

केवल अतिरिक्त जानकारी जोड़ें।

विशेष रूप से, इस तथ्य को पुन: स्थापित करने के लिए क्षेत्रों का उपयोग करना कि कुछ सदस्य गुण, घटनाएं इत्यादि पूरी तरह से व्यर्थ हैं। सबसे आम समस्या यह है कि आप "निजी विधियों" के लिए एक क्षेत्र बनाते हैं, और फिर आप इसे सार्वजनिक बनाने के लिए उनमें से एक को संपादित करते हैं। अब आपको इसे स्थानांतरित करना है, जिसका अर्थ है कि पुराने संस्करण के साथ एक अंतर में, सरल परिवर्तन को समझना बहुत कठिन होता है।

Answer 5

#region Lotsa boring code and lookup tables 

मैं इसे स्क्रीन अचल संपत्ति को बचाने के लिए उपयोग करते हैं, और कुछ नहीं :)

Answer 6

जब भी मैं क्षेत्र देखने मुझे लगता है कि कोड या तो उत्पन्न होता है या फिर से फैक्टरिंग की जरूरत होती।

उनका उपयोग करने से बचें और जब आप उनकी आवश्यकता महसूस करते हैं, तो आप जो भी कर रहे हैं उसकी पुनः जांच करें और अपनी कक्षा को छोटे से विभाजित करने का प्रयास करें। आखिरकार यह क्षेत्र की उपयोग करने से अधिक आवेदन की पठनीयता में मदद करेगा।

Answer 7

मैं वी.एस. 2008 के लिए अपने ही क्षेत्र कोड का टुकड़ा लिखा था जो मैं हमेशा का उपयोग करें:

<?xml version="1.0" encoding="utf-8" ?> 
<CodeSnippets xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet"> 
<CodeSnippet Format="1.0.0"> 
    <Header> 
     <Title>#class region</Title> 
     <Shortcut>#classregion</Shortcut> 
     <Description>Code snippet for #region in classes</Description> 
     <Author>Simon Linder</Author> 
     <SnippetTypes> 
      <SnippetType>Expansion</SnippetType> 
      <SnippetType>SurroundsWith</SnippetType> 
     </SnippetTypes> 
    </Header> 
    <Snippet> 
     <Declarations> 
      <Literal> 
       <ID>name</ID> 
       <ToolTip>Region name</ToolTip> 
       <Default>MyRegion</Default> 
      </Literal> 
     </Declarations> 
     <Code Language="csharp"> 
      <![CDATA[#region Variables 
        $selected$ $end$ 
       #endregion 

      #region Construction/Destruction 
        $selected$ $end$ 
       #endregion 

      #region Properties 
        $selected$ $end$ 
       #endregion 

      #region Public Methods 
        $selected$ $end$ 
       #endregion 

      #region Private/Proteced Methods 
        $selected$ $end$ 
       #endregion]]> 
     </Code> 
    </Snippet> 
</CodeSnippet> 

आप मैं Variables, Construction/Destruction, Properties, Public और Private तरीकों के लिए क्षेत्रों का उपयोग करते हैं देख सकते हैं। मैं अक्सर events नामक निजी क्षेत्र में एक और उप-क्षेत्र जोड़ता हूं। क्षेत्रों का क्रम भी StyleCop के साथ ठीक काम करता है।

Answer 8

व्यक्तिगत रूप से मैं कोड कोड को आपके कोड सम्मेलन का हिस्सा बनाने की अनुशंसा नहीं करता। जो संभवतः जैसे मुद्दों को जन्म दे सकता मुख्य कारण यह है कि क्षेत्रों कोड छुपाने के लिए,:

• डेवलपर्स स्रोत कोड के कुछ महत्वपूर्ण भाग से छूट सकते हैं
• औसत एक ही फाइल में एलओसी की राशि देता है बढ़ाने के लिए

आप अपनी टीम में एक कोडन शैली सम्मेलन को लागू करने में रुचि रखते हैं, Microsoft StyleCop पर एक नज़र है। ध्यान दें कि वर्तमान में टूल केवल सी # के लिए काम करता है।

Answer 9

मैं निम्नलिखित क्षेत्रों का उपयोग करें:

Private Member Variables 
Constructor 
Public Properties 
Private Methods 
Public Methods 
Events 

कारण कोड का बेहतर प्रबंधन के कारण है।
मैं उन फ़ाइलों के साथ काम करता हूं जिनमें कोड की 2000 से अधिक पंक्तियां हो सकती हैं और बिना किसी क्षेत्र के कोड को बनाए रखना बहुत मुश्किल है।

Answer 10

मुझे लगता है कि क्षेत्रों में कोई आवश्यकता नहीं है। वे सुगम नहीं हैं। यदि आपको अपनी कक्षा में एक राशि कोड की आवश्यकता है (सोचो, क्या आपको वास्तव में आवश्यकता है?), आप कक्षा तर्क इकाइयों को विभाजित करने के लिए 'आंशिक' वर्ग का उपयोग कर सकते हैं।