जुवाल लोवी का सी # कोडिंग मानक प्रश्न

Question

मैं आनंद लेता हूं और अत्यधिक अनुशंसा करता हूं Juval Lowy's - C# Coding Standard। मानक तंग रखने के लिए जुवल स्पष्ट रूप से प्रत्येक निर्देश के लिए तर्क को टालता है (प्रस्तावना देखें)। हालांकि, कुछ निर्देश हैं जिनके लिए मैं खुद को तर्क के रूप में उत्सुकता प्राप्त करता हूं।

लोवी के सी # मानक से निम्नलिखित निर्देशों के लिए विशिष्ट तर्क क्या है?
उम्मीद है कि इनके लिए कठिन (गैर-व्यक्तिपरक) उत्तर हैं।

1.13 पूरी तरह से योग्य प्रकार के नाम से बचें। इसके बजाय "उपयोग" कथन का प्रयोग करें।
क्या यह एक प्रदर्शन मुद्दा है? कभी-कभी मुझे केवल पूरी तरह से योग्य नाम के एक उदाहरण की आवश्यकता होती है और का उपयोग करके भारी लगता है।

1.26 पैरामीटर रहित-अज्ञात विधियों पर खाली कोष्ठक का उपयोग करें। केवल ब्रांड्स को छोड़ दें यदि अज्ञात विधि किसी भी प्रतिनिधि पर उपयोग की जा सकती थी।
वास्तव में मैं दूसरी वाक्य से उलझन में हूं। उदाहरण के साथ स्पष्टीकरण मदद करेगा, धन्यवाद।

2,19 बचें परिभाषित करने कस्टम अपवाद कक्षाएं
क्या उनकी संख्या को कम करने में विचार कर रहे हैं? (वह अगले दिशा-निर्देश देता है अगर आप (उन्हें परिभाषित 2.20 में करते हैं)।)

2,29 बचें पाठक को पचाने के लिए, या अन्य कारणों के लिए त्रिगुट सशर्त ऑपरेटर
का उपयोग कर बहुत कठिन?

2.31 बूलियन सशर्त बयान में फ़ंक्शन कॉल से बचें। स्थानीय चर में असाइन करें और उन पर जांच करें।
मुझे नहीं लगता कि मैं ऐसा करता हूं, लेकिन मैं उत्सुक हूं ... क्यों नहीं?

2.47 एक सदस्य के साथ इंटरफेस से बचें।
क्योंकि यह हमेशा/आमतौर पर क्या करने के लिए अधिक प्राप्य होता है? एक विधि काम करता है जब काम करता है?

2,53 स्पष्ट इंटरफेस कार्यान्वयन
क्यों का उपयोग कर पसंद करते हैं? इसके अलावा, Jon Skeet disagrees here।

अग्रिम धन्यवाद! रॉबर्ट

Answer 1

जाहिर है, मैं Juval नहीं हूँ, लेकिन मैं इन

1.13 बचें पूरी तरह से योग्य प्रकार के नाम पर एक चाकू ले जा सकते हैं। इसके बजाय "उपयोग" कथन का प्रयोग करें।

प्रदर्शन यहां समस्या नहीं हो सकती है। मुझे यकीन है कि मुद्दा पठनीयता है।

1.26 पैरामीटर रहित-अज्ञात विधियों पर खाली कोष्ठक का उपयोग करें। केवल ब्रांड्स को छोड़ दें यदि अज्ञात विधि किसी भी प्रतिनिधि पर उपयोग की जा सकती थी।

public delegate void Foo1(); 
public delegate void Foo2(int val); 

public void Foo() 
{ 
    Foo1 first = delegate { Console.WriteLine("Hello world"); }; 
    Foo2 second = delegate { Console.WriteLine("Hello world"); }; 
    Foo1 third = delegate() { Console.WriteLine("Hello world"); }; 
    Foo2 fourth = delegate() { Console.WriteLine("Hello world"); }; // does not compile 
} 

कोष्ठक के बिना, गुमनाम प्रतिनिधि किसी भी प्रतिनिधि के लिए लागू किया जा सकता है। माता-पिता के साथ, आप प्रतिनिधि के हस्ताक्षर के बारे में विशिष्ट हैं। दूसरे वाक्यविन्यास को तब तक पसंद करें जब तक आपको वास्तव में लचीलापन की आवश्यकता न हो।

2,19 बचें परिभाषित करने कस्टम अपवाद कक्षाएं

फिर, पठनीयता यहां मुद्दा यह है। ढांचे अपवाद वर्ग समृद्ध और अच्छी तरह से समझा जाता है। उन्हें बदलते समय सावधान रहें।

2,29 त्रिगुट सशर्त ऑपरेटर

प्रयोग करने से बचें यह एक पठनीयता और विस्तार बात है। मैं वास्तव में सहमत नहीं हूं, लेकिन यह एक मानक धार्मिक लड़ाई है।

2.31 बूलियन सशर्त बयान में फ़ंक्शन कॉल से बचें। स्थानीय चर में असाइन करें और उन पर जांच करें।

आंशिक रूप से यह पठनीयता है, और आंशिक रूप से यह डिबगिंग की आसानी के लिए है। मैंने लगभग सब कुछ अस्थायी चर के लिए असाइन करना शुरू कर दिया है ताकि वे बाद में डीबगर में आसानी से पाए जा सकें।

2.47 एक सदस्य के साथ इंटरफेस से बचें।

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

2.53 स्पष्ट इंटरफेस कार्यान्वयन

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

Answer 2

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

1.13 पूरी तरह से योग्य प्रकार के नाम से बचें। इसके बजाय "उपयोग" कथन का प्रयोग करें।

पठनीयता। जब आपको पूरी तरह से योग्य प्रकार के नाम पढ़ना पड़ता है तो कोड को पढ़ना कठिन होता है।

2.19 बचें परिभाषित करने कस्टम अपवाद कक्षाएं

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

2.29 बचें त्रिगुट सशर्त ऑपरेटर

मुझे लगता है कि इस वजह से वह सोचता है कि लोगों ऑपरेटर नहीं समझ सकते हैं सबसे अधिक संभावना है, लेकिन मैं इससे सहमत नहीं इस्तेमाल करते हैं।

2.47 एक सदस्य के साथ इंटरफेस से बचें।

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

2.31 बूलियन सशर्त बयान में फ़ंक्शन कॉल से बचें। स्थानीय चर में असाइन करें और उन पर जांच करें।

कुछ कारणों से मैं यहां सोच सकता हूं। पठनीयता। यह सशर्त बयान को समझने में कठोर परिश्रम कर सकता है यदि आप उनमें फ़ंक्शन कॉल कर रहे हैं। साथ ही, अगर आप नहीं देख रहे हैं तो डीबग करना मुश्किल है।

2.53 स्पष्ट इंटरफेस कार्यान्वयन

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

Answer 3

यहाँ मेरी प्रतिक्रियाओं में से कुछ जिनमें से मैं उन्हें जवाब देने :)

1,13 बचें पूरी तरह से योग्य प्रकार के नाम की हिम्मत कर रहे हैं। इसके बजाय "उपयोग" कथन का प्रयोग करें। मैं असहमत हूं। यह निश्चित रूप से प्रदर्शन से संबंधित नहीं है। यह var foo = new Foo() के बजाय var foo = new MyCompany.MyNamespace.Helpers.Xml.Foo() के अलावा बेहतर पठनीयता के लिए नेतृत्व कर सकता है लेकिन इसके अलावा - नहीं।

2.19 कस्टम अपवाद वर्गों को परिभाषित करने से बचें यह बकवास imho है। आपको अनुप्रयोग अपवाद से प्राप्त कस्टम अपवाद बनाने से बचना चाहिए, लेकिन कस्टम अपवादों के साथ कुछ भी गलत नहीं है (जब तक कि आप मौजूदा अपवादों को फिर से शुरू नहीं कर रहे हैं)।

2.29 टर्नरी सशर्त ऑपरेटर का उपयोग करने से बचें मुझे नहीं पता कि यह एक दिशानिर्देश क्यों होगा। मैंने पढ़ा है कि सभी लोग इसका उपयोग नहीं करते हैं और इसे पहचान नहीं सकते हैं, लेकिन उपयोगी ऑपरेटर का उपयोग न करने का यह वैध कारण नहीं है।

2.31 बूलियन सशर्त बयान में फ़ंक्शन कॉल से बचें। स्थानीय चर में असाइन करें और उन पर जांच करें। यह मेरी राय में बस एक पठनीयता मुद्दा है।

2.47 एक सदस्य के साथ इंटरफेस से बचें। मैं यहां भी असहमत हूं। आपको 'मार्कर' इंटरफेस से बचना चाहिए - हालांकि मार्कर के साथ इंटरफेस, लेकिन जो सिर्फ इस उद्देश्य को पूरा करता है कि कुछ ... 'ble' है। लेकिन, एक इंटरफ़ेस पर एक विधि मेरे लिए ठीक लगती है।

Answer 4

1,26 के बारे में पूर्व लैम्ब्डा delegate { } वाक्य रचना है।

// #1 Empty parenthesis on parameterless-anonymous methods would be: 
delegate() { } 
// #2 ... anonymous method could have been used on any delegate, is: 
delegate { } 

याद रखें, बाद के किसी भी प्रतिनिधि सौंपा जा सकता है, इसके मापदंडों की परवाह किए बिना। प्रतिनिधि कुछ संकलक चालबाजी का उपयोग करके इन्हें अनदेखा करता है।

यदि आप किसी प्रतिनिधि को कोई पैरामीटर नहीं लेते हैं, तो स्पष्ट रूप से # 1 का उपयोग करके कहें। "कोष्ठक छोड़ दें क्योंकि आपका प्रतिनिधि किसी भी पैरामीटर को नहीं लेता है"।

Answer 5

इन दिशानिर्देशों का एक बहुत अच्छा सॉफ्टवेयर डिजाइन (अर्थात रख-रखाव, विश्वसनीयता, पुनर्प्रयोग, testability, विस्तार, debugability, अंतर है, और क्या अन्य -ilities आप नाम कर सकते हैं) की "गुणवत्ता विशेषताओं" करने के लिए बोलते हैं।

अक्सर लोगों कोड उस समय ठीक काम करता है लेकिन सबसे अच्छा विकल्प नहीं हो सकता है जब सभी गुणवत्ता विशेषताओं (पर विचार के अर्थ में "जहां इस सॉफ्टवेयर भविष्य में जा सकते हैं" या "किसी और को है बनाने इस कोड का भी प्रयोग करें ")।

उदाहरण के लिए:

2,29 बचें त्रिगुट सशर्त ऑपरेटर

का उपयोग कर रहा, त्रिगुट भाव, दर असल साथ कोई समस्या नहीं है लेकिन कोड लिख कर, जैसे कि: पूर्णांक परिणाम = CheckMethod()? OnTrueDoThis(): OnFalseDoThat() ... आप कह रहे हैं, "मेरे पास एक सशर्त है कि, यदि सत्य (या झूठा) है, तो आप एक और केवल एक चीज कर सकते हैं।" पूरे निर्माण विस्तारशीलता को हतोत्साहित करता है। आपको निर्माण को फिर से बनाना होगा (अगर किसी भी कथन के साथ)।

इसी तरह ...

2,31 बचें समारोह बूलियन सशर्त बयान में कहता है। स्थानीय चरों में असाइन करें और उन पर जांच करें।

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

, का आनंद लें

रॉबर्ट सी Cartaino

Answer 6

2.29 त्रिगुट सशर्त ऑपरेटर मैं त्रिगुट ऑपरेटर के "सरल" का उपयोग करता है के साथ कोई समस्या नहीं है, लेकिन प्रयोग करने से बचें एक नेस्टेड फैशन में इसे प्रयोग के खिलाफ की सिफारिश की है:

// This is fine 
x := (conditionA) ? true_resultA : false_resultA; 

// This would probably be clearer using if-then-elseif 
x := (conditionA) ? 
     ((conditionA1) ? true_resultA1 : (condition2) ? true_result2 : false_result2) : 
     ((conditionA2) ? true_resultA2 : false_resultA2); 

Answer 7

1,13 के बारे में (पूरी तरह से योग्य बचें नाम टाइप करें। इसके बजाय "उपयोग" कथन का उपयोग करें):

यह पठनीयता से थोड़ा अधिक हो सकता है। यदि आपके पास फ़ाइल की शुरुआत में बहुत अधिक उपयोग हैं, तो आपके पास एक कक्षा है जो कई नामस्थानों से कक्षाओं के साथ मिलती है।

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

Answer 8

2.29 त्रिगुट ऑपरेटर

के साथ शुरू करने के लिए, यदि आप त्रिगुट ऑपरेटर का उपयोग करने के लिए शुरू करते हैं, एक नियमित रूप से अगर-तो-और कुछ से अधिक त्रिगुट ऑपरेटर के उपयोग के लिए एक कारण होना चाहिए। का निरीक्षण करें:

if (x == 0) {...} else{...} //A set of statements demand a regular If-then-else 

//A simple assignment can be handled by the ternary operator 
y = (x == 0)? 1 : 0 //this is readable and how it should be used 


(x==0)? callSomething() : callSomethingElse() //this is NOT how it should be used 

त्रिगुट बयान सशर्त यह मूल्यांकन कर रही है पर निर्भर करता है दो में से एक मान लौटने के लिए है। एफपी करते समय यह बेहद आसान है। कॉल स्टेटमेंट्स के लिए जो मान वापस नहीं करते हैं, आपको फिर से वापस लेना चाहिए।