कोडिंग दिशानिर्देश: विधियों में 7 से अधिक कथन नहीं होने चाहिए?

Question

मैं C # के लिए AvSol कोडिंग दिशानिर्देशों के माध्यम से देख रहा था और मैं लगभग हर चीज से सहमत हूं लेकिन मैं वास्तव में यह देखने के लिए उत्सुक हूं कि एक विशिष्ट नियम के बारे में अन्य क्या सोचते हैं।

AV1500

विधियाँ 7 कथनों से अधिक नहीं होनी चाहिए एक विधि जिसमें 7 से अधिक कथनों की आवश्यकता होती है वह बहुत अधिक कर रही है, या बहुत अधिक जिम्मेदारियाँ हैं। कोड को क्या करना है यह समझने के लिए सटीक बयानों का विश्लेषण करने के लिए मानव मन की भी आवश्यकता होती है। इसे कई छोटे और ध्यान केंद्रित नामों के साथ छोटे तरीकों से तोड़ें।

क्या आप में से अधिकांश इस नियम का पालन करते हैं? भले ही बहुत अधिक पठनीयता बढ़ने से अलग एक नया तरीका (आपका कोड अभी भी DRY है ) बनाने से बचा जा सकता है? और क्या आपकी संख्या अभी भी 7 से कम है? मैं 10 की ओर अधिक रुख करूंगा।

मैं यह नहीं कह रहा हूं कि मैं इस नियम का पूरी तरह से उल्लंघन करता हूं - इसके विपरीत, मेरे तरीके 95% छोटे और केंद्रित हैं, लेकिन यह कहते हुए कि आपको इस नियम का कभी भी उल्लंघन नहीं करना चाहिए।

मैं वास्तव में केवल यह जानना चाहता हूं कि हर कोई इस नियम का उल्लंघन करने के बारे में क्या सोचता है (यह कोडिंग मानक पर एक '1' है - जिसका अर्थ यह नहीं है)। लेकिन मुझे लगता है कि आपको एक कोडबेस खोजने में परेशानी होगी जो नहीं करता है।

Comments

क्या वे caseएक अकेले में switchभी बयानों को गिनते हैं? किसी भी तरह से, यह एक बेकार, बेकार आवश्यकता के अलावा और कुछ नहीं है। जिन लोगों ने इसे लिखा है, वे प्रोग्रामिंग के बारे में कुछ नहीं जानते हैं।

— एसके-तर्क

एकमात्र नियम जो कोडिंग मानक पर '1' होना चाहिए, वह नियम होना चाहिए "आप सभी कोडिंग दिशानिर्देशों को नमक के दाने के साथ ले जाएंगे।"

— माइक नाकिस

@ एसके-लॉजिक 1027 बुरा नहीं है - यह मजेदार लेखन कोड होना चाहिए, जिसमें लापता डेटा को संभालना है, अगर आपको रिक्त स्ट्रिंग के बराबर शून्य स्ट्रिंग का इलाज करना है।

— मात्रा_देव

इस दिशानिर्देश को पढ़ते समय मैं एक कोडबेस से भरा देखने की उम्मीद करूंगा: शून्य DoSomething () {DoSomethingFirstSevenLines (); DoSomethingSecondSevenLines (); DoSomethingThirdSevenLines (); आदि; }

— tugs

अधिकांश .NET फ्रेमवर्क को दर्शाने का प्रयास करें और देखें कि कितने तरीकों में 7 से कम कथन हैं ...

— डेविड बोइक

Answer 1

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

Comments

+1 के लिए "छंद द्वारा micromanagement।" मुझे संदेह है कि किसी ने "7 प्लस या माइनस 2" नियम ( en.wikipedia.org/wiki/… ) के बारे में पढ़ा और लंबी अवधि के भंडारण के साथ अल्पकालिक तथ्य प्रतिधारण को भ्रमित किया, जैसा कि आप जानते हैं, एक कोड संपादक।

— शराबी

कोई भी समझदारी से सोचे-समझे मानक कोड में जादू की संख्या को प्रतिबंधित करता है, है ना? आपको लगता है कि कोडिंग मानक उस मानक के लिए भी आयोजित किया जाएगा। संख्या 7 में निश्चित रूप से एक "जादू" गुणवत्ता है।

— एडम क्रॉसलैंड

यदि दस्तावेज़ का शीर्षक " GuidlinesC # 3.0 और 4.0 के लिए कोडिंग नहीं था तो आपका जवाब और अधिक समझ में आता है ।

— एंडी

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

— Spoike

मैंने इस दस्तावेज़ को डाउनलोड किया और इसके माध्यम से देखना शुरू किया। 1.6 में, यह कहा गया है: "दस्तावेज़ में यह नहीं कहा गया है कि परियोजनाओं को इन दिशानिर्देशों का पालन करना चाहिए, न ही यह कहता है कि कौन से दिशानिर्देश दूसरों की तुलना में महत्वपूर्ण हैं। हालांकि, हम खुद को यह तय करने के लिए परियोजनाओं को प्रोत्साहित करते हैं कि क्या दिशानिर्देश महत्वपूर्ण हैं, क्या एक परियोजना का विचलन करेंगे।" उपयोग करें, जो संदेह के मामले में सलाहकार हैं और स्रोत कोड के लिए किस तरह के लेआउट का उपयोग किया जाना चाहिए। " भले ही 1 का अर्थ "दिशानिर्देश है कि आपको कभी भी छोड़ना नहीं चाहिए और सभी समाधानों पर लागू होना चाहिए", आप इसे संशोधित करना चुन सकते हैं।

— Chrish

Answer 2

सामान को छोटे तरीकों में विभाजित करना आमतौर पर एक अच्छा विचार है। लेकिन महत्वपूर्ण बात यह है कि चीजों को विभाजित करना जहां यह समझ में आता है।

यदि यह विभाजित होने का कोई मतलब नहीं है, तो विभाजित न करें। यह अक्सर कुछ प्रक्रियाओं या जीयूआई कोड के लिए होता है।

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

हमेशा दिशानिर्देशों के साथ, यह याद रखना अच्छा है कि बाधाओं का अस्तित्व क्यों है, इसलिए आप सीख सकते हैं कि यह कब लागू नहीं होता है। अधिकांश कोड में विधियां कम होंगी, या आपको शायद DRY या चिंताओं को अलग करने की समस्या है । लेकिन अगर ऐसा नहीं है, तो ठीक है।

Comments

बहुत बढ़िया जवाब। अंतिम दो लाइनें विशेष रूप से घर को ड्राइव करती हैं।

— Xonatron

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

— hugomg

कोड पूरा अच्छा सामान से भरा है। प्रत्येक प्रोग्रामर को हर दिन दोपहर के भोजन में इसका एक टुकड़ा खाना चाहिए।

— deadalnix

Answer 3

इसे अंगूठे का नियम माना जाना चाहिए।

"पाठ के 80 (100,120 से अधिक) कॉलम," प्रति विधि एक निकास बिंदु "," घोंसले के 2 से अधिक स्तर नहीं "जैसी चीजें हैं, मैं कोड गंध के संकेतकों के लिए थ्रेसहोल्ड कहूंगा। यदि आप उन्हें इस अवसर पर उल्लंघन करते हैं, तो इसका मतलब जरूरी नहीं है कि कोड खराब है। यदि आप खुद को लगातार उनका उल्लंघन करते हुए पाते हैं तो कोड में कुछ बदबू आ रही है और आप रोकना चाहते हैं और अपने दृष्टिकोण पर पुनर्विचार कर सकते हैं।

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

Comments

"80/100/120" कॉलम की सीमा है इसलिए हम कोड पढ़ सकते हैं। अधिकांश टर्मिनल 80 स्तंभों पर खुलते हैं, और लेखक को 80 कॉलमों से लपेटने के लिए यह कम प्रयास है कि हर पाठक अपने टर्मिनल का आकार हर बार कोड को पढ़ना चाहता है। अन्य सीमाओं के विपरीत, एन-कॉलम सीमा कोड के शब्दार्थ को प्रभावित नहीं करती है, यह एक विशुद्ध रूप से शैलीगत नियम है; उसी श्रेणी में "4-स्पेस टैब का उपयोग करें" या "अपनी लाइन पर कार्यों के लिए ओपनिंग ब्रेसेस लगाएं"।

— डिट्रीच एप्प

दी, यह एक अर्थ पहलू से अधिक एक सौंदर्य पहलू है। हालाँकि, यह वह जगह है जहाँ मेरा अंतिम वाक्य लागू होता है। जावा स्टेटमेंट को खोजने के लिए यह असामान्य नहीं है कि लाइन को विभाजित करने के लिए "अच्छा" जगह के साथ 80 कॉलम नियम से अधिक न हो। इससे कोड की पठनीयता और समझ प्रभावित होती है। यह डिमेटर

— सेजगी

21 वीं सदी में, मेरी आईडीई में "डायनेमिक वर्ड रैप" नामक यह सुविधा है।

— ग्योर्गी एंडरसेक

@ GyörgyAndrasek: लेकिन हर कोई हमेशा अपने आईडीई का उपयोग नहीं कर रहा है: हम, साथ टर्मिनलों में GitHub में कोड को देखो less, में vimऔर emacs; और ऑटोमैटिक रैपिंग सबसे अच्छा लगता है। कोडिंग मानक आपके लाभ के लिए नहीं हैं, वे उन लोगों के लाभ के लिए हैं जो टीमों में काम करते हैं।

— डिट्रीच एप्प

@DietrichEpp व्यक्तिगत रूप से मेरे पास एक कठिन समय पढ़ने वाला कोड है जो हमेशा कॉलम 80 पर लिपटा रहता है। मुझे हाल ही में एक जावा प्रोजेक्ट पर काम करना था जहां मानक ग्रहण फॉर्मेटर का उपयोग किया गया था। और एक विधि के अंदर लाइनों का ट्रैक रखना बहुत मुश्किल था जो दो या तीन लाइनों पर चला गया था (मैं उस के लिए अन्य फॉर्मेट सेटिंग्स को दोष देता हूं)। लब्बोलुआब यह है कि मुझे लगता है कि 80 थोड़ा पुराना है। मैं व्यक्तिगत रूप से 120 की सीमा का उपयोग करता हूं, मेरे संपादकों ने इसे लागू करने के लिए सेट किया है, एक कंसोल है जो 120 कॉलम चौड़ा है और जीथब वास्तव में 125 कॉलम प्रदर्शित करता है। और मुझे लगता है कि यह बहुत अधिक पठनीय है।

— प्रहार करें

Answer 4

मैंने अपने तरीकों में वास्तव में बयानों की संख्या को गिनने के लिए समय नहीं लिया है, लेकिन मैं उन तरीकों को लिखने का प्रयास करता हूं जो सफाई से एक ही, स्पष्ट उद्देश्य का प्रदर्शन करते हैं। जब तक आपका कोड साफ, पठनीय है, और DRY और सिंगल रिस्पॉन्सिबिलिटी सिद्धांतों का पालन करता है, तब तक आप अपना काम कर सकते हैं। मुझे लगता है कि केवल सात-कथन की सीमा को लागू करने के लिए मनमाने तरीके से विभाजन करने से आपके कोड को कम पठनीय / बनाए रखा जा सकता है।

Comments

पठनीयता के लिए +1। अगर कोई विधि 20, 30 या 50 रेखाओं से लंबी है तो भी इससे कोई फर्क नहीं पड़ना चाहिए। यदि DRY और SRP आपके लक्ष्य हैं, तो यह मायने नहीं रखेगा कि क्या विधियां लंबी ओर से थोड़ी छोटी लगती हैं ... हालांकि सबसे अधिक बार आप पाएंगे कि जितना अधिक पठनीय आप अपने कोड को बनाने की कोशिश करते हैं, उतनी ही कम आपके तरीके स्वाभाविक रूप से बन जाएगा।

— S.Robins

Answer 5

यह अनुमानित है

इस प्रकार के नियमों को बहुत ही शाब्दिक रूप से नहीं लिया जाना चाहिए। वे कह सकते थे " विधियाँ कम होनी चाहिए "। हालांकि, कुछ लोगों ने व्याख्या की होगी कि "1 से कम पृष्ठ" और अन्य के रूप में "2 पंक्तियाँ।"

मैं मानूंगा कि उन्होंने आपको एक मोटा विचार देने के लिए "7 कथन" कहा (हालांकि मुझे लगता है कि उन्हें "7 के बारे में" कहना चाहिए था)। यदि आपको एक बार में 9 की आवश्यकता है, तो इसे पसीना मत करो। लेकिन अगर आप 20 वर्ष के हैं, तो आपको पता होगा कि आप इस नियम के लिए सही बॉलपार्क में नहीं हैं।

Comments

यह तो एक बहुत स्पष्ट सन्निकटन बनाता है। यह "दिशानिर्देशों के तहत चिह्नित है कि आपको कभी भी छोड़ना नहीं चाहिए और सभी स्थितियों पर लागू होना चाहिए"।

— ब्रायन

@ ब्रायन - शायद गाइडलाइन लेखकों ने गलती से "मोटे तौर पर" शब्द को छोड़ दिया, या शायद वे पागल तानाशाह-प्रकार थे। मेरा कहना है कि ओपी को इसे बॉलपार्क नंबर के रूप में लेना चाहिए। संकलक या दुभाषिया लागू नहीं करता है किसी भी नियम सिर्फ एक सुझाव है।

— नाथन लॉन्ग

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

— ब्रायन

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

— Spoike

Answer 6

7 पूरी तरह से बिना किसी महत्व के पूरी तरह से मनमानी संख्या है।

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

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

उदाहरण के लिए एक स्विच / केस स्टेटमेंट लें। यदि आपके पास 7 से अधिक संभावित मान हैं, तो आपको मूल्यांकन को कई तरीकों से तोड़ने की आवश्यकता है? बेशक, यह मूर्खतापूर्ण नहीं होगा।

केवल 7 के तहत बयानों की संख्या को बनाए रखने के लिए कृत्रिम तरीके से और अधिक तरीकों से कोड को तोड़ना आपके कोड को बदतर बनाता है।

दिशानिर्देश होना चाहिए प्रत्येक विधि को 1 काम करना चाहिए और अपना कोड DRY रखना चाहिए।

Comments

+1: मनमानी सीमाएं केवल मनमाने ढंग से उपयोगी हैं। एक विधि में एक एकल अमूर्त स्तर पर एक सुसंगत ऑपरेशन होना चाहिए। ऐसी परमाणु इकाई को तोड़ने से कोड अधिक जटिल हो जाता है, जिससे कोड को समझना कठिन हो जाता है।

— एलन ग्रेलनेक

DRY ओवर-रेटेड है। अक्सर इसका मतलब है कि किसी चीज़ के दो पहलुओं को कसकर युग्मित करना जो कि कसकर युग्मित नहीं होना चाहिए।

— ब्रैड थॉमस

Answer 7

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

Comments

आप बॉयलरप्लेट कोड को अपनी विधि में सार नहीं कर सकते हैं?

— 15

मैंने पोस्ट करने के बाद देखा कि यह C # जावा नहीं है बल्कि मैं इस तरह की सोच रहा हूं। stackoverflow.com/questions/321418/…

— Jaydee

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

— केविन क्लाइन

व्यक्तिगत रूप से, मुझे और अधिक पठनीय होने के लिए staight लाइन कोड की कुछ अतिरिक्त लाइनें मिल रही हैं। लेकिन शायद सिर्फ मैं ही हूं।

— Jaydee

@Jaydee जुड़ा हुआ प्रश्न सामान्य लेकिन अजीब अभ्यास दिखाता है: अपवाद और लॉगिंग लपेटना। अगले स्तर पर आप ऐसा ही कर सकते हैं ... इस तरह एक एकल अपवाद लॉग में कई बार दिखाई देता है। फेंकने की विधि को घोषित करना बेहतर होगा और आपने 3 पंक्तियों को सहेजा है। एक सहायक विधि दोनों को बंद करने लिखें psऔर rsऔर एक दूसरे को बचाने के। या एक विधि लिखें List<Row> readDb(String sql, Object... args)जो पूरे काम करता है (केवल परिणाम के लिए काम करता है, मेमोरी में फिटिंग सेट करता है, लेकिन बहुत अधिक डेटा लाने का तात्पर्य आमतौर पर डीबी में काम करना चाहिए)।

— माॅर्टिनस

Answer 8

सब कुछ एक व्यापार है। प्रस्तावित दृष्टिकोण के साथ समस्या - कई तरीकों और कक्षाओं में फिर से भरना ताकि प्रत्येक विधि कम हो - हालांकि यह अलग-अलग कारणों के लिए, अपठनीय कोड की ओर जाता है जब इसे अपने चरम पर ले जाया जाता है।

एक ऐसी विधि की कल्पना करें जिसमें foo()7 चीजें हों। आप तर्क दे सकते हैं कि 7 चीजें बहुत अधिक हैं। हो सकता है कि कई मामलों में आप सही हों। दूसरी ओर, ये 7 चीजें निकटता से संबंधित हो सकती हैं; तर्क आसानी से बह सकता है और गद्य की तरह पढ़ सकता है; आपको इसे समझने में कोई परेशानी नहीं हो सकती है जब आपको वास्तव में आवश्यकता होगी। जो बहुत बुरा हो सकता है, वह यह है कि उन 7 चीजों को एक बड़े स्रोत के पेड़ पर वितरित किया जाए, ताकि यदि आप देखें foo()तो आपको पता नहीं चलेगा कि यह 7 अलग-अलग स्थानों में देखे बिना क्या करता है।

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

Answer 9

यह एक बुरा दिशानिर्देश नहीं है। जब तक वे समूहीकृत और पर्याप्त रूप से परस्पर संबंध नहीं रखते हैं, तब तक मुझे विधियों और कक्षाओं में विभाजित होने का पछतावा नहीं है (मुझे कभी नहीं मिला था)।

चाल को इसे लंबवत रूप से विभाजित नहीं करना है (बस एक बिंदु पर एक विधि बंद करें और एक नया शुरू करें)। चाल, जैसे इकाई परीक्षण के साथ, इस तरह के नियम को शुरू से ही ध्यान में रखना है ताकि आप वास्तव में बेहतर डिजाइन करें, 3 या 4 स्टेटमेंट को दूसरी विधि से पास कर दें क्योंकि एक विधि कॉल का वर्णन करता है कि आप क्या बेहतर कर रहे हैं आपके कोड के बीच में वे 3 या 4 स्टेटमेंट।

इस तरह के विभाजन, भले ही यह मनमाना हो और केवल एक बार उपयोग किया जाता हो, बाद में कोड की एक नई स्पष्टता के कारण बेहतर रिफ्लेक्टरिंग हो सकती है, यह छोटी कक्षाओं के साथ भी सच है।

इसे ऐसे समझें कि आप इकाई परीक्षण करेंगे। यदि आप इस तथ्य के बाद इकाई परीक्षण को जोड़ने का प्रयास करते हैं तो यह मुश्किल है और कभी-कभी असंभव लगता है लेकिन यदि आप इसे शुरू से ही डिजाइन करते हैं तो यह वास्तव में आपके सभी कोड को बेहतर बनाता है।

सारांश? अगर "मैं 7 से अधिक कथनों का उपयोग करता हूं" की गंध से "7 से कम कथन का उपयोग करें" की डिज़ाइन गंध की तुलना करें, तो मैं कोड गंध को समाप्त कर दूंगा।

Answer 10

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

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

मैंने भी कभी विशेषज्ञ होने का दावा नहीं किया। लेकिन मैं इस पेशे में 15 साल से हूँ, लगभग 4 साल का सी ++ अनुभव और 11 साल का सी # अनुभव। यह मूल रूप से इंडस्ट्रियल स्ट्रेंथ C ++ पर आधारित था, लेकिन मैं तब से इसे रिफाइन कर रहा हूं, जब कम्युनिटी से इनपुट मिला है।

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

Comments

आप में झंकार करने के लिए अच्छा है, और मुझे लगता है कि आप एक उचित तर्क देते हैं। उन्होंने कहा, मैं आपके तर्क से सहमत नहीं हूं "वे हमेशा ऐसे डेवलपर्स होते हैं जो अपने दिशानिर्देशों को स्पष्ट करना चाहते हैं": आप हमेशा बेवकूफों को पूरा नहीं कर सकते हैं, और आपको कोशिश नहीं करनी चाहिए। दिशानिर्देश स्पष्ट करना अच्छा है, जब तक कि यह उन्हें गलत तरीके से प्रस्तुत नहीं करता है: अब यह दिशानिर्देश नहीं है, यह एक मनमाना नियम है। मनमानी संख्याओं का परिचय, जैसा कि आपने देखा है, गोली मारने का एक निश्चित तरीका है, और उचित है।

— कोनराड रुडोल्फ

Answer 11

सबसे पहले: यह एक दिशानिर्देश है, एक नियम नहीं है। इसे एक दिशानिर्देश कहा जाता है, इसलिए कृपया इसे ऐसा ही मानें। तात्पर्य यह है कि आपका अपना निर्णय भी आवश्यक है (हमेशा की तरह)

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

Answer 12

मैं अपने ऊपर दिए गए बयान से सहमत हूं। यह सिर्फ दिशानिर्देश है और एक आदर्श दुनिया में सब कुछ वस्तुओं होगा, हर कार्यक्रम में पुन: उपयोग किया जाता है, और दुनिया एक सुंदर जगह होगी। यह हमेशा सच नहीं होता है और कभी-कभी यह बहुत सारे उपरि या बर्बाद संसाधनों को जन्म देगा। आपको यह भी ध्यान में रखना होगा।

Comments

"मैं अपने ऊपर दिए गए बयान से सहमत हूं" स्टैकएक्सचेंज साइटों में इस तरह के वाक्यों से बचें। याद रखें कि जो उत्तर पोस्ट किए गए हैं वे जरूरी नहीं कि जिस क्रम में वे प्रदर्शित हों।

— luiscubal

मुझे पता है, मैंने तब तक नहीं सोचा था जब तक बहुत देर हो चुकी थी। लेकिन मैं अभी भी आपको मेरे मस्तिष्क के गोज़ को इंगित करने के लिए +1 करूंगा।

— फाल्कन 165o

Answer 13

बहुत ही मूर्खतापूर्ण जब आप मिश्रण में अपवाद हैंडलिंग जोड़ते हैं।

"प्रयास, पकड़, अंत में" के बाद आपको प्रति विधि चार बयानों के साथ छोड़ दिया जाता है!

20 फ़ील्ड फॉर्म के लिए "वैलिडेटफॉर्म" की एक विधि पर भी विचार करें, भले ही आप अलग-अलग तरीकों से सभी व्यक्तिगत मान्यताओं को संभाल लें, फिर भी आपके पास 20 फ़ील्ड सत्यापन विधियों को लागू करने के लिए है। इन दिशानिर्देशों के अनुसार, आप कुछ मान्य विभाजन जैसे कि "validateTopOfScreen", "validateMiddleOfScreen" और "validateBottomOfScreen" के साथ समाप्त हो जाएंगे।

Comments

मुझे लगता है यह कहना है कि बहुत सुरक्षित है try/ catch/ finallyसी # में बयान नहीं कर रहे हैं। एकमा -334 .3 12.3.3.15 और आसपास के खंड देखें। (संक्षिप्त) " फॉर्म का

— एक ट्राइ

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

— डेनिस डॉमेन

@ डेनिस - सच है, बहुत लंबे समय से HTML फॉर्म कर रहे हैं!

— जेम्स एंडरसन

@ जेम्स और यही इस विशेष दिशानिर्देश के लिए है। आपको वैकल्पिक, संभवतः बेहतर, समाधान के बारे में सोचने की कोशिश कर रहा है।

— डेनिस डॉमेन

Answer 14

सवाल "दिशा-निर्देशों" के साथ "नियम" का सामना कर रहा है। नियमों का पालन करने का मतलब है - दिशा-निर्देश सलाह हैं जो आपको यह विचार करने के लिए प्रेरित करते हैं कि आप क्या कर रहे हैं और यदि यह वास्तव में बेहतर तरीके से किया जा सकता है।

मैं कहता हूं, औसतन, अधिकांश प्रोग्रामिंग संभवतः दिशानिर्देशों का पालन करके सुधार किया जाता है, लेकिन हमेशा ऐसे मामले होंगे जहां दिशानिर्देशों का हठपूर्वक पालन करने से वे अधिक समस्याएं पैदा करेंगे, जिनका वे इरादा रखते थे। इसलिए उन्हें नियम के रूप में नहीं, बल्कि दिशानिर्देशों के रूप में प्रस्तुत किया जाता है।

एक पिछले उत्तरदाता ने दिखाया है कि दिशा-निर्देशों के लेखकों ने उन्हें कभी भी सैद्धांतिक रूप से लागू करने का इरादा नहीं किया और अपने दस्तावेज़ में इस आशय के बयान शामिल किए।

Answer 15

मैं ऊपर की टिप्पणियों के साथ सहमत हूँ। मेरे लिए 7 मनमानी है और कुछ भाषाओं में उपयोगी हो सकती है जहाँ माणिक, लेकिन C #, Java, C ++ जैसी भाषाओं के लिए मुझे इस "7 लाइन" सम्मेलन पर संदेह है। मैं आपको एक उदाहरण देता हूं। मेरे वर्तमान एप्लिकेशन में 22 टेक्स्ट फ़ील्ड हैं और मैं सर्वर साइड सत्यापन करता हूं। विधि को वैद्युत इंपुट () कहा जाता है और मेरी प्राथमिकता एक विधि में सभी क्षेत्रों को तब तक के लिए मान्य है जब तक कि मुझे चेकइमार्टमेट () जैसे कुछ जटिल मान्य न हो। इसलिए मूल रूप से मेरा वैद्युत विधि विधि कोड 108 बार जटिल सत्यापन के लिए कॉल के साथ है।

अब कल्पना करें कि क्या मैंने प्रत्येक क्षेत्र को मान्य करने के लिए 25 तरीके कहे। यदि कोई नया डेवलपर आता है, तो उसे 25 तरीकों से कूदने के लिए मुख्य विधि से अंदर और बाहर जाना होगा, जो संभवत: कुछ अन्य को कॉल कर सकता है। वह बड़ी परियोजनाओं में खो जाने के लिए बाध्य है।

मैं अपने कोड को स्पष्ट करने के लिए वास्तव में क्या करता हूं, स्वच्छ टिप्पणियां प्रदान करता हूं जो मूल रूप से कहती हैं कि ये 4 लाइनें पूर्व क्या कर रही हैं -

validateInput (UserObj उपयोगकर्ता) {

// पहला नाम मान्य करें ....... ......

// मान्य अंतिम नाम ...... ......

// मान्य ईमेल ..... // बहुत जटिल है ईमेल प्रारूप की नियमित जांच करने के लिए जाँच करेंईमेलफ़ॉर्मैट (); .... .....

और इसी तरह.. }

Comments

जेम्स एंडरसन के सवाल पर मेरी प्रतिक्रिया भी देखें। आपके विशेष मामले में, मुझे आश्चर्य है कि यदि वह मान्य विधि एक ही समय में कई सिद्धांतों और दिशानिर्देशों का उल्लंघन नहीं कर रही है।

— डेनिस डॉमेन

Answer 16

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

कोड की पंक्तियाँ जटिलता की एक मनमानी गिनती हैं। विस्तार के तरीकों से मैं जैसे कोड बना सकता हूं

                Parallel.ForEach(regions, region => {   Console.Write(region.Resorts.Where(x => x.name == "Four Seasons").OrderBy(x => x.RegionId).ThenBy(x => x.ResortId).ThenBy(x => x.name).ToList());   });

Comments

एक ही विधि में बहुत अधिक करने का एक बड़ा उदाहरण फिर से। लगभग हर प्रतिवाद में लोग एकल उत्तरदायित्व सिद्धांत (एक विधि के संदर्भ में) का उल्लंघन कर रहे हैं।

— डेनिस डूमेन

Answer 17

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

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