कक्षाओं में वस्तुओं का क्रम: फ़ील्ड, गुण, निर्माता, विधियाँ

Question

क्या वर्ग संरचना के संदर्भ में वस्तुओं के क्रम के लिए एक आधिकारिक सी # दिशानिर्देश है?

क्या यह जाता है:

• सार्वजनिक क्षेत्र
• निजी क्षेत्र
• गुण
• कंस्ट्रक्टर्स
• तरीके
  ?

अगर वस्तुओं के क्रम के बारे में कठोर और तेज़ नियम है तो मैं उत्सुक हूँ? मैं सभी जगह की तरह हूँ। मैं एक विशेष मानक के साथ रहना चाहता हूं इसलिए मैं इसे हर जगह कर सकता हूं।

वास्तविक समस्या मेरे अधिक जटिल गुण हैं जो बहुत कुछ विधियों की तरह दिखते हैं और वे कंस्ट्रक्टर से पहले शीर्ष पर जगह से बाहर महसूस करते हैं।

कोई सुझाव / सुझाव?

Comments

दरअसल, वास्तविक प्रश्न का उत्तर देने के लिए, नहीं, कोई आधिकारिक दिशानिर्देश नहीं है। स्टाइलकॉप माइक्रोसॉफ्ट में एक विशेष समूह के भीतर उपयोग के लिए विकसित दिशानिर्देशों को लागू करता है। यह एक आधिकारिक दिशानिर्देश नहीं है, और Microsoft में समूहों के बीच समान भी नहीं हो सकता है।

— जॉन साउन्डर्स

एक आसान चाल यह है कि कुछ जटिल वर्ग के मेटाडेटा को .net (वी 12 वीएस में) देखें। आपको पता चल जाएगा कि कम से कम सदस्यों publicऔर protectedसदस्यों के लिए इसका ऑर्डर कैसा है ।

— नवफाल

यह प्रश्न राय-आधारित नहीं है, क्योंकि यह पूछता है कि क्या कोई आधिकारिक दिशानिर्देश है। या तो एक दिशानिर्देश है या वहाँ नहीं है!

— साइमन एमकेन्ज़ी

@nawfal मुझे एहसास है कि यह एक पुरानी टिप्पणी है, मुझे आपके द्वारा बताई गई चाल पसंद है, लेकिन यह ध्यान देने योग्य है कि यह privateया internalसदस्यों को नहीं दिखाएगा (मुझे विश्वास है)। देखने का अच्छा तरीका है publicऔर protected, हालांकि। हम .NET फ्रेमवर्क कक्षाओं के स्रोत देख सकते हैं, यहाँ referenceource.microsoft.com भी है

— एडम प्लोचर

Answer 1

के अनुसार StyleCop नियम प्रलेखन आदेश के रूप में इस प्रकार है।

एक वर्ग, संरचना या इंटरफ़ेस के भीतर: (SA1201 और SA1203)

• लगातार क्षेत्र
• खेत
• कंस्ट्रक्टर्स
• फाइनल (विध्वंसक)
• प्रतिनिधियों
• आयोजन
• enums
• इंटरफेस ( इंटरफ़ेस कार्यान्वयन )
• गुण
• indexers
• तरीके
• structs
• कक्षाएं

इन समूहों में से प्रत्येक तक पहुँच के अनुसार: (SA1202)

• जनता
• अंदर का
• संरक्षित आंतरिक
• संरक्षित
• निजी

प्रत्येक पहुंच समूह के भीतर, स्थैतिक द्वारा आदेश, फिर गैर-स्थैतिक: (SA1204)

• स्थिर
• गैर स्थिर

खेतों के प्रत्येक स्थिर / गैर-स्थिर समूह के भीतर, आसानी से, फिर गैर-पठनीय रूप से ऑर्डर करें: (SA1214 और SA1215)

• सिफ़ पढ़िये
• गैर केवल पढ़ने के लिए

एक अनियंत्रित सूची 130 लाइनों की है, इसलिए मैं इसे यहां नहीं रखूंगा। विधि भाग अनियंत्रित है:

• सार्वजनिक स्थैतिक विधियाँ
• सार्वजनिक तरीके
• आंतरिक स्थैतिक तरीके
• आंतरिक विधियाँ
• संरक्षित आंतरिक स्थैतिक तरीके
• संरक्षित आंतरिक तरीके
• संरक्षित स्थैतिक तरीके
• संरक्षित तरीके
• निजी स्थिर विधियाँ
• निजी तरीके

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

Comments

इस पोस्ट में प्रयास करने के लिए मैं आपको धन्यवाद देना चाहूंगा। मैं स्टाइलकॉप सामान को एक मानक बनाने की कोशिश कर रहा हूं (भले ही बस सुसंगत हो और चीजों को ढूंढना आसान हो) और यह मूल्यवान है।

— केनी मान

व्यक्तिगत रूप से, मुझे स्टैटिक विधियों का क्रम कष्टप्रद लगता है। मैं पहले आने वाले स्थिर सार्वजनिक तरीकों के लिए तर्क देख सकता हूं, लेकिन मैं आमतौर पर सदस्यों के बाद निजी स्थिर तरीके चाहता हूं। वे सब के बाद उपयोगिताओं रहे हैं।

— जोनाथन राइट

मुझे आंशिक वर्ग टिप पसंद है

— कीथ सिरमन्स

केवल आंशिक वर्गों पर एक नोट। यह देखते हुए कि संकलित समय के दौरान सभी भाग एक ही प्रकार में संकलित किए जाते हैं, मैं हमेशा उस अतिरिक्त ओवरहेड को बनाने के लिए एक अच्छा कारण सुनिश्चित करने का प्रयास करूंगा। आंशिक कक्षाओं का मुख्य कारण ऑटो-जनरेट सोर्स कोड का विस्तार करना या बड़ी परियोजनाओं पर काम करते समय कई डेवलपर्स को एक ही क्लास या अलग-अलग फाइलों पर काम करने की अनुमति देना है।

— नहीं

@ फ़्राँस्वा वॉहाल क्या ओवरहेड कंपाइलर के साथ आंशिक वर्गों के संयोजन को एक ही प्रकार में जोड़ता है?

— dav_i

Answer 2

दृश्यता के आधार पर या आइटम के प्रकार (क्षेत्र, संपत्ति, विधि, आदि) के बजाय, कार्यक्षमता द्वारा समूहीकरण के बारे में कैसे?

Comments

अगर StyleCop सिफारिशों का उपयोग करके "सॉर्ट करना" यह एक प्रकार की कार्यक्षमता है। एक अच्छा कारण है कि कुछ तरीके सार्वजनिक हैं और अन्य निजी हैं। कोड वास्तव में बेहतर पठनीय है: यदि किसी वर्ग की .cs फ़ाइल खोलने पर मैं तुरंत सार्वजनिक विधियों को देखता हूं जो निजी लोगों की तुलना में "अधिक महत्वपूर्ण" हैं (उस वर्ग का उपयोग करने वाले व्यक्ति के लिए)

— hfrmobile

यदि आपको अपनी कक्षा में इतने सारे तरीके, गुण, आदि मिले हैं, जिन्हें आपको उन्हें अनुभाग द्वारा समूहित करने की आवश्यकता है, तो शायद यह संकेत है कि वर्ग बहुत कुछ कर रहा है?

— रयान लुनडी

भले ही वर्ग छोटा हो, लेकिन क्या यह सार्वजनिक तरीकों को उनके संबंधित निजी तरीकों के साथ समूह बनाने का कोई मतलब नहीं होगा जो केवल इस सार्वजनिक विधि द्वारा कहे जाते हैं?

— मार्कस मेयेर

+1 अगर सार्वजनिक विधि फू () एक संरक्षित / निजी इंटरनलफू () को कॉल करती है, तो उस दूसरी विधि को स्रोत में DoFoo () के नीचे बेहतर होना चाहिए, अन्य संरक्षित / निजी तरीकों के बीच कहीं और नीचे नहीं।

— एंडर्स फोर्सग्रेन

कार्यक्षमता द्वारा समूहीकरण को एक वर्ग कहा जाता है

— मृदोसु

Answer 3

यह एक पुराना, लेकिन फिर भी बहुत ही प्रासंगिक प्रश्न है, इसलिए मैं इसे जोड़ूंगा: जब आप एक क्लास फाइल खोलते हैं, तो आप पहली बात यह देखते हैं कि आप पहले पढ़ सकते हैं या नहीं? खेत? गुण? मैंने अनुभव से महसूस किया है कि लगभग हमेशा मैं निर्माणकर्ताओं के लिए शिकार करने जाता हूं, क्योंकि यह समझने के लिए सबसे बुनियादी बात है कि इस वस्तु का निर्माण कैसे किया जाता है।

इसलिए, मैंने निर्माणकर्ताओं को प्रथम श्रेणी की फाइलों में रखना शुरू कर दिया है, और इसका परिणाम मनोवैज्ञानिक रूप से बहुत सकारात्मक रहा है। अन्य चीजों के झुंड के बाद कंस्ट्रक्टर लगाने की मानक सिफारिश असंगत लगती है।

C # 6 में आने वाली प्राथमिक निर्माता सुविधा इस बात का प्रमाण देती है कि एक निर्माणकर्ता के लिए प्राकृतिक स्थान एक वर्ग के शीर्ष पर है - वास्तव में प्राथमिक कंस्ट्रक्टर खुले ब्रेस से पहले भी निर्दिष्ट हैं।

यह अजीब बात है कि इस तरह से किए गए अंतर का कितना अंतर है। यह मुझे याद दिलाता है कि पहले कैसे usingसिस्टम नेमस्पेस के साथ बयान दिए जाते थे। विजुअल स्टूडियो के "ऑर्गेनाइज़ यूजिंग्स" कमांड ने इस आदेश का उपयोग किया। अब usingकेवल वर्णानुक्रम में आदेश दिया जाता है, सिस्टम नेमस्पेस को कोई विशेष उपचार नहीं दिया जाता है। परिणाम बस सरल और साफ लगता है।

Comments

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

— डेविड कुलप

वास्तव में, वे जिस क्रम को मनुष्यों द्वारा देखा जाना चाहते हैं, उस साहित्यिक प्रोग्रामिंग की धारणा है कि कोड को पहले मनुष्यों द्वारा पठनीय होना चाहिए।

— उज्ज्वल

ध्यान दें कि प्राथमिक निर्माणकर्ताओं को C # 6: stackoverflow.com/a/26915809/5085211 के

— fuglede

10 में से 9 बार, मैं सार्वजनिक इंटरफ़ेस की तलाश में हूं, यही वजह है कि मैंने सभी सार्वजनिक सदस्यों को पहले रखा, उसके बाद आंतरिक, उसके बाद संरक्षित, और अंत में निजी सदस्यों ने।

— मैट डेविस

Answer 4

मुझे किसी भाषा या उद्योग मानक के बारे में जानकारी नहीं है, लेकिन मैं इस क्रम में चीजों को #region में लिपटे प्रत्येक खंड के साथ रखता हूं:

कथन का उपयोग करना

नाम स्थान

कक्षा

निजी सदस्य

सार्वजनिक गुण

कंस्ट्रक्टर्स

सार्वजनिक तरीके

निजी तरीके

Comments

यह ठीक उसी तरह है जैसे मैं इसे करता हूं। कक्षा और निजी सदस्यों के बीच में, मेरे पास कोई सार्वजनिक कॉन्स्टेंट और

— एनम

हां, मैं निजी तरीकों के बाद सार्वजनिक संपत्ति रखना पसंद करता हूं। अन्य लोग निर्माता को सार्वजनिक संपत्तियों से पहले रखना पसंद करते हैं ... लेकिन मेरे दिमाग में उस क्रम में मूल्य / निर्माता / व्यवहार होना पसंद करते हैं। फिर "मान" को स्थिरांक / PrivateMembers / गुण और के रूप में विभाजित किया गया है। आमतौर पर मैं क्षेत्रों का उपयोग नहीं करता, कुछ बड़े दृश्य-मॉडल को छोड़कर ... अच्छी तरह से, WPF viewmodels विशेष तरह के होते हैं, और, इस मामले में मैं आमतौर पर प्रत्येक सार्वजनिक संपत्ति से ठीक पहले बैकिंग निजी फ़ील्ड डालता हूं। इस मामले में, निजी क्षेत्र और सार्वजनिक सदस्य का सेट एक ही इकाई है

— zameb

Answer 5

मैं IDesign या ब्रैड अब्राम की वेबसाइट पर सूचीबद्ध लोगों से कोडिंग मानकों का उपयोग करने की सलाह दूंगा । वे सबसे अच्छे दो हैं जो मुझे मिले हैं।

ब्रैड कहेंगे ...

वर्गों के सदस्य को वर्णानुक्रम में जोड़ा जाना चाहिए, और वर्गों में बांटा जाना चाहिए (फ़ील्ड, कंस्ट्रक्टर, गुण, घटनाएँ, विधियाँ, निजी इंटरफ़ेस कार्यान्वयन, नस्ट प्रकार)

Comments

यह लिंक इन दिनों IDesign होम पेज पर ले जाता है। ऐसा प्रतीत होता है कि कोडिंग मानक इन दिनों एक ईमेल डाउनलोड लिंक के पीछे छिपे हैं # अन्याय

— लाइम

दिशानिर्देशों में औचित्य होना चाहिए। इसके लिए तर्क यह है: 1. ताकि आप समझें, 2. ताकि आप सीमा रेखा पर निर्णय ले सकें, सूक्ष्म, अस्पष्ट, अप्रत्याशित या परस्पर विरोधी मामले, 3. ताकि आप समायोजित कर सकें जब स्थितियां बदलती हैं और कुछ दिशानिर्देश अब लागू नहीं होते हैं।

— पाब्लो एच

Answer 6

जैसा कि पहले उल्लेख किया गया है कि लेआउट को निर्धारित करने वाली सी # भाषा में कुछ भी नहीं है, मैं व्यक्तिगत रूप से क्षेत्रों का उपयोग करता हूं, और मैं एक औसत वर्ग के लिए ऐसा कुछ करता हूं।

public class myClass
{
#region Private Members

#endregion
#region Public Properties

#endregion

#region Constructors

#endregion
#region Public Methods

#endregion
}

यह मेरे लिए वैसे भी समझ में आता है

Comments

यहाँ कहने के लिए (सिर्फ जानकारी के लिए) है कि StyleCop क्षेत्रों (SA1124 DoNotUseRegions) का उपयोग नहीं की सिफारिश करता है

— Gerwald

Microsoft स्वयं क्षेत्रों का उपयोग कर रहा है।

— zwcloud

@zwcloud ज़रूर, 5538 लाइनों वाली फ़ाइल में, क्षेत्र आवश्यक हैं, लेकिन इसका मतलब यह नहीं है कि आपको सामान्य फ़ाइलों में क्षेत्रों का उपयोग करना चाहिए।

— घोस्ट ४ मैन २ Ghost ’

@Gerwald: मुझे लगता है कि StyleCop का उपयोग करने वाले लोगों के लिए StyleCop ही है। यह कई मानकों में से एक है

— zameb

@ ज़ेम्ब: मैं कहूंगा, स्टाइलकॉप नियम सी # के लिए सबसे आम कोडिंग दिशानिर्देशों में से एक है। किसी भी भाषा में कोडिंग करते समय, मैं हमेशा कोडिंग दिशानिर्देशों का सबसे आम सेट खोजने की कोशिश करता हूं, और उनका पालन करता हूं।

— गेरवाल्ड

Answer 7

स्टाइलकॉप से

निजी क्षेत्र, सार्वजनिक क्षेत्र, निर्माता, गुण, सार्वजनिक विधियाँ, निजी विधियाँ

जैसा कि स्टाइलकॉप एमएस निर्माण प्रक्रिया का एक हिस्सा है, जिसे आप एक वास्तविक मानक के रूप में देख सकते हैं

Comments

दिलचस्प। क्या आप स्टाइलकॉप का नियमित रूप से उपयोग करते हैं?

— 21 फरवरी को mmcdole

एक परियोजना के लिए हाँ, क्योंकि यह अब और फिर से कुछ एमएस अनुबंध काम के लिए इस्तेमाल किया जाता है। यह बहुत ही कष्टप्रद मुस्कराहट है

— प्रहसन

एक लंबे समय के लिए स्टाइलकॉप का उपयोग करना और अगर उस सिफारिश का उपयोग करना कोड को वास्तव में बेहतर पठनीय बनाता है: यदि एक वर्ग की .cs फ़ाइल खोलने पर मुझे तुरंत सार्वजनिक तरीके दिखाई देते हैं जो निजी लोगों की तुलना में "अधिक महत्वपूर्ण" हैं। जनता वर्ग के "इंटरफेस" हैं जो इसे प्रदान करता है और जिसे परीक्षण किया जा सकता है (पसंद TDD, और टेस्ट-प्रथम)

— hfrmobile

स्टाइलकॉप के

— माइकल फ्रीजिम

"स्टाइलकॉप एमएस निर्माण प्रक्रिया का हिस्सा है" से आपका क्या अभिप्राय है? क्या Microsoft अपने सभी कोड के लिए StyleCop का उपयोग कर रहा है?

— रिको सीटर

Answer 8

आमतौर पर मैं अगले पैटर्न का पालन करने की कोशिश करता हूं:

• स्थैतिक सदस्यों (आमतौर पर एक अन्य संदर्भ है, धागा-सुरक्षित होना चाहिए, आदि)
• उदाहरण के सदस्य

प्रत्येक भाग (स्थिर और उदाहरण) में निम्न सदस्य प्रकार होते हैं:

• ऑपरेटर (हमेशा स्थिर होते हैं)
• फ़ील्ड (निर्माणकर्ताओं से पहले आरंभिक)
• कंस्ट्रक्टर्स
• विध्वंसक ( निर्माणकर्ताओं का पालन करने की परंपरा है )
• गुण
• तरीकों
• आयोजन

फिर सदस्यों को दृश्यता के आधार पर हल किया जाता है (कम से अधिक दृश्यमान तक):

• निजी
• अंदर का
• आंतरिक संरक्षित
• संरक्षित
• जनता

आदेश एक हठधर्मिता नहीं है: सरल कक्षाओं को पढ़ना आसान है, हालांकि, अधिक जटिल वर्गों को संदर्भ-विशिष्ट समूह की आवश्यकता है।

Answer 9

मेरी प्राथमिकता तरह से ऑर्डर करना और फिर निम्नानुसार दृश्यता कम करना है

public methods
public events
public properties

protected methods
protected events
protected properties

private methods
private events
private properties
private fields

public delegates
public interfaces
public classes
public structs

protected delegates
protected interfaces
protected classes
protected structs

private delegates
private interfaces
private classes
private structs

मुझे पता है कि यह स्टाइल कॉप का उल्लंघन करता है और अगर कोई मुझे एक अच्छा कारण दे सकता है तो मुझे इसके इंटरफ़ेस से पहले एक प्रकार के कार्यान्वयन विवरण को जगह देना चाहिए जिसे मैं बदलने के लिए तैयार हूं। वर्तमान में, मेरे पास निजी सदस्यों को अंतिम रूप देने के लिए एक मजबूत प्राथमिकता है।

नोट: मैं सार्वजनिक या संरक्षित क्षेत्रों का उपयोग नहीं करता।

Comments

माना। मैं वास्तव में आश्चर्य करता हूं कि अगर पहले निजी सदस्यों को रखने की धारणा सी दिनों की पकड़ नहीं है, जहां चर पहले घोषित किए जाने थे। मैं लगभग हमेशा सार्वजनिक इंटरफ़ेस को देखना चाहता हूं, न कि क्लास के इंटर्न को।

— मैट डेविस

यह वास्तव में बहुत मायने रखता है। मुझे यकीन है कि यह सी से एक पकड़ मिली है

— Aluan हद्दाद

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

— रयान द लीच

Answer 10

निकटतम आपके द्वारा "डिजाइन दिशानिर्देश, प्रबंधित कोड और .NET फ्रेमवर्क" खोजने की संभावना है ( ब्रैड अब्राम द्वारा http://blogs.msdn.com/brada/articles/361363.aspx )

यहां कई मानकों को रेखांकित किया गया है। प्रासंगिक खंड 2.8 मुझे लगता है।

Answer 11

इसके लिए सुझाए गए एकमात्र कोडिंग दिशानिर्देशों को कक्षा की परिभाषा के शीर्ष पर फ़ील्ड रखना है।

मैं बगल में कंस्ट्रक्टर लगाता हूं।

मेरी सामान्य टिप्पणी यह ​​होगी कि आपको प्रति फ़ाइल एक कक्षा से चिपके रहना चाहिए और यदि कक्षा इतनी बड़ी है कि गुणों बनाम विधियों का संगठन एक बड़ी चिंता का विषय है, तो कक्षा कितनी बड़ी है और क्या आपको इसे फिर से बनाना चाहिए? क्या यह कई चिंताओं का प्रतिनिधित्व करता है?

Comments

और एक बार जब आप क्षेत्रों की जरूरत है ... आप खो दिया है।

— हमीश स्मिथ

Answer 12

मैं कंस्ट्रक्टर (ओं) के साथ निजी क्षेत्रों को शीर्ष पर रखना पसंद करता हूं, फिर उसके बाद सार्वजनिक इंटरफ़ेस बिट्स, फिर निजी इंटरफ़ेस बिट्स डालना चाहता हूं।

इसके अलावा, यदि आपकी कक्षा की परिभाषा वस्तुओं के ऑर्डर के लिए बहुत अधिक लंबी है, तो संभवत: एक कोड गंध है जो यह संकेत देता है कि आपकी कक्षा बहुत भारी और जटिल है और आपको रिफ्लेक्टर करना चाहिए।

Answer 13

मैं इसे यथासंभव सरल रखता हूं (कम से कम मेरे लिए)

एनुमरेशन्स
डिक्लेरेशन
कंस्ट्रक्टर्स
ओवरराइड
मेथड्स
प्रॉपर्टी
इवेंट हैंडलर

Answer 14

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

Comments

मैं क्षेत्रों को दृश्यता से अलग करने के लिए उपयोग करता हूं, और एक क्षेत्र कोड लेआउट होने से मुझे ईमानदार बना रहता है। rauchy.net/regionerate

— भूल गए अर्धविराम

मुझे # वर्णनों का उपयोग करने में कोई समस्या नहीं दिखती है, हालाँकि मुझे अक्सर लगता है कि जैसे ही मुझे एक क्षेत्र में डालने के लिए लुभाया जाता है, यह मुझे अपनी कक्षाओं को विभाजित करने पर विचार करने के लिए प्रेरित करता है।

— mikecamimo

Answer 15

मुझे पता है कि यह पुराना है लेकिन मेरा आदेश इस प्रकार है:

सार्वजनिक, संरक्षित, निजी, आंतरिक, सार के क्रम में

• स्थिरांक
• स्थैतिक चर
• खेत
• आयोजन
• निर्माता (रों)
• तरीके
• गुण
• प्रतिनिधियों

मुझे इस तरह के गुणों को लिखना पसंद है (शॉर्टहैंड दृष्टिकोण के बजाय)

// Some where in the fields section
private int someVariable;

// I also refrain from
// declaring variables outside of the constructor

// and some where in the properties section I do
public int SomeVariable
{
    get { return someVariable; }
    set { someVariable = value; }
}