किस बिंदु पर छोरों के भीतर छोरों का होना वर्जित है?


23

बस उत्सुक। मेरे पास अब तक के लिए एक लूप के लिए एक लूप था, क्योंकि लिनुस टोरवाल्ड्स से इसे पढ़ने के बाद :

टैब 8 वर्ण हैं, और इस प्रकार इंडेंटेशन भी 8 वर्ण हैं। ऐसे आनुवांशिक आंदोलन हैं जो इंडेंटेशन 4 (या यहां तक ​​कि 2!) वर्णों को गहरा बनाने की कोशिश करते हैं, और यह पीआई के मान को 3 करने के लिए परिभाषित करने की कोशिश कर रहा है।

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

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

https://www.kernel.org/doc/Documentation/CodingStyle

मुझे लगा कि यह मेरे लिए लूपिंग की तीसरी परत पर जाने के लिए एक अस्वीकार्य अभ्यास था, और मेरे कोड (मुख्य रूप से क्यूटी) का पुनर्गठन करेगा।

क्या लिनुस मजाक कर रहा था?

क्या यह भाषा या अनुप्रयोग पर निर्भर करता है?

क्या कुछ चीजें हैं जो बिल्कुल तीन या अधिक स्तर के लूपिंग की आवश्यकता होती हैं?


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

5
लिनुस शायद (केवल) उस खंड में मज़ाक नहीं कर रहा है, लेकिन ध्यान दें कि यह केवल एक शैली गाइड है, और एक ही शैली गाइड तनाव देता है कि "कर्नेल कोडिंग शैली सुपर सरल है", अर्थात अन्य शैलियों की तुलना में अधिक।

5
@ अकिवा आप 4 नेस्टेड लूप्स के बिना 4-आयामी मैट्रिक्स के माध्यम से नहीं जा सकते। मुझे यह समझ में आता है कि कोई आपके पास होने वाले नेस्टेड छोरों की मात्रा को सीमित कर देगा। लिनुस स्पष्ट रूप से बहुत सामान्य था और आपको पवित्र शास्त्र के रूप में पढ़ा जाने वाला सब कुछ नहीं लेना चाहिए।
अल्टरनेटेक्स

9
@Alternatex आप 4 छोरों की जरूरत है कि इसका मतलब यह नहीं है कि वे किया जाना है lexically नेस्ट। यह उद्धरण से काफी स्पष्ट है कि हम कोड को व्यवस्थित करने के बारे में बात कर रहे हैं, निष्पादन के बारे में नहीं।

4
@delnan मैं नहीं कह रहा हूँ 4 नेस्टेड लूप्स नेत्रहीन मनभावन हैं और मुझे पता है कि इसके बारे में जाने के अन्य तरीके हैं लेकिन मुझे यह मूर्खतापूर्ण लगता है कि ओपी ने लिनुस के शब्दों को कैसे लिया। संसार का 4 वाँ स्तर = अंत। मुझे एक विराम दें।
अल्टरनेटेक्स

जवाबों:


19

कर्नेल दृढ़ता से सरल एल्गोरिदम को प्राथमिकता देता है

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

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


तो क्या आपको लगता है कि सी जैसे निचले स्तर की भाषाओं के साथ, गहराई से नेस्टेड लूप आम तौर पर becauseनिचले स्तर की भाषाओं का उपयोग करने वाली अधिक वर्जित परियोजनाएं हैं जो कोडिंग शैली से लाभान्वित होती हैं जो सरल एल्गोरिदम पर ध्यान केंद्रित करती हैं?
अकीवा

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

एक बहुत ही व्यावहारिक और उपयोगी टिप्पणी / उत्तर। बस उत्सुक; आज किस तरह का प्रोजेक्ट किया गया है जो निम्न स्तर की भाषा का उपयोग करता है, यह मजबूत, ऑडिट-सक्षम और सुरक्षित होने पर ध्यान केंद्रित नहीं करेगा?
अकीवा

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

49

एक हद तक, मैंने "टैब्स हैं 8 वर्ण" पर इस उद्धरण को गंभीरता से लेना बंद कर दिया । सारणीकारों की पूरी बात यह है कि वे एक निश्चित संख्या में वर्ण नहीं हैं (यदि कुछ भी हो, एक टैब एक वर्ण है)। क्या तोश का भार। इसी तरह, मैं पूरी तरह से आश्वस्त नहीं हूं कि "इंडेंटेशन के तीन स्तरों" का एक हार्ड-एंड-फास्ट नियम सेट करना समझदार है (किसी भी चीज़ के लिए हार्ड-एंड-फास्ट नियम सेट करना जितना आसान है)।

हालांकि, खरोज के अपने स्तर को सीमित है सामान्य एक उचित सुझाव में एक है कि आप के लिए एक आश्चर्य के रूप में आना चाहिए, और नहीं।

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

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


6
मेरा मानना ​​है कि "घोषणा" कि टैब 8 वर्ण हैं विशेष रूप से कर्नेल विकास के संदर्भ में हैं। यह उद्धरण एक विशिष्ट परियोजना के लिए एक कोडिंग दिशानिर्देश से लिया गया है और इसका सामान्य उपयोग दिशानिर्देश होने का इरादा नहीं है, और इस प्रकार यह काफी राय होने की उम्मीद है।
रेयान

6
@ लीरियन: तब यह अभी भी टॉस है - किसी भी चीज के लिए एक कोडिंग गाइडलाइन का कोई व्यवसाय तय नहीं है कि मैं अपना टैब कितना चौड़ा करूं! लेकिन मुझे शक है कि लिनुस को पता है।
मोनिका

6
और निश्चित रूप से यह भाषा पर निर्भर है - सी # में यह आम है कि आप अपने नाम स्थान के अंदर, अपनी कक्षा में, और अपनी पद्धति में .. आप नियंत्रण प्रवाह विवरण निकायों के बारे में बात करने से पहले ही पहले से ही 3 स्तर के इंडेंटेशन पर हैं। इंडेंट।
पीटरएल

3
@LightnessRacesinOrbit मैं व्याख्या करता हूं "टैब 8 वर्ण हैं" टिप्पणी का अर्थ यह नहीं है कि आपको व्यक्तिगत रूप से अपने संपादक में टैब 8 के रूप में देखना चाहिए, लेकिन स्टाइल गाइड में अन्य नियमों के उद्देश्य से (जैसे "लाइनों की लंबाई पर सीमा")। 80 कॉलम है और यह एक दृढ़ता से पसंदीदा सीमा है। ") टैब को 8 कॉलम्स के रूप में माना जाना चाहिए, यह फ़ंक्शन कॉल में तर्क संरेखण के बारे में अन्य नियमों के लिए भी प्रासंगिक है। फिर से, मुझे नहीं लगता कि उस लाइन का इरादा आपको टैब को देखने के लिए मजबूर कर रहा है, मैंने पहले 4 विस्तृत टैब के साथ कर्नेल पैचिंग की है और कोड को अंत में रिफिल किया है।
वैधता

4
@underscore_d: ऐसा प्रतीत होता है कि मैं गलत हूं: Outside of comments, documentation and except in Kconfig, spaces are never used for indentation, and the above example is deliberately broken.- ओपी में बोली से 6 पैराग्राफ नीचे।
स्लीपबेटमैन

16

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


11
ठीक ठीक। यह सुझाव देना बहुत आसान है कि टोरवाल्ड्स एक लोन है। (वह निश्चित रूप से है।) वह आपके स्वाद के लिए बहुत कठोर हो सकता है, लेकिन वह एक वास्तविक विकास चिंता का वर्णन कर रहा है जो वास्तविक समस्याओं का कारण बनता है। आपको उसके कहे अनुसार बिलकुल नहीं करना है, लेकिन आपको यह सोचना चाहिए कि वह ऐसा क्यों कह रहा है।
स्कंट रोजर

7
@ScantRoger वास्तव में, अगर आपकी हास्य की भावना नहीं मिलती है तो तोरवाल्ड्स-उद्धरण केवल बहुत कठोर लगता है। जैसा कि मुझे याद है, पहले इसी दस्तावेज में, वह GNU कोडिंग शैली दिशानिर्देशों की एक प्रति प्रिंट करने का सुझाव देता है, केवल उन्हें किसी प्रकार के समारोह में जलाने के लिए। आप शायद ही इसे गंभीरता से लेंगे, क्या आप? इस उद्धरण में, उनकी मुख्य बात यह है कि लिनक्स कर्नेल के लिए इंडेंटेशन को आठ रिक्त स्थान के रूप में परिभाषित किया जाए, इससे अधिक कुछ नहीं, और कुछ भी कम नहीं, यही वह है जिसके बारे में वह कठोर है। अंतिम वाक्य केवल उस बिंदु को रेखांकित करने के लिए है, यह कहने के लिए नहीं कि आपको इंडेंटेशन के अधिक स्तरों का उपयोग नहीं करना चाहिए - कोई कठोरता निहित नहीं है।
15

1
@cmaster संदर्भ के लिए धन्यवाद, ठीक है! आपके प्रश्न के उत्तर में, मैं शायद ही किसी चीज़ को गंभीरता से लेता हूँ। ;)
15-16 पर स्कैट रोजर

2
@cmaster और उसके बाद जीथब पुल अनुरोधों और प्रतिबद्ध संदेशों की लाइन लंबाई के लिए अपनी प्रतिक्रियाओं को पढ़ता है। वह कुल अखरोट-केस है।
गसडॉर

3
जीएनयू कोडिंग दिशानिर्देशों को औपचारिक रूप से जलाना वास्तव में आवश्यक नहीं हो सकता है, लेकिन यह किसी भी समय पूरी तरह से क्रम में है।
dmckee

13

क्या लिनुस मजाक कर रहा था?

टुकड़ा एक चंचल शैली में लिखा गया है जो बताता है कि लेखक गंभीर चिकित्सकों के बीच कोडिंग शैली पर चर्चा करने के तरीके से परिचित है: हम सभी की अपनी प्राथमिकताएं हैं, और हम उन्हें स्पष्ट रूप से बचाव करते हैं, लेकिन जीभ के साथ कम से कम आंशिक रूप से गाल में। हम पूरी तरह से अच्छी तरह से समझते हैं कि यह केवल व्यक्तिगत स्वाद का मामला है। वे कहते हैं, इतने सारे शब्दों में, "Coding style is very personal, and I won't _force_ my views on anybody"- कम से कम कोड के बाहर वह व्यक्तिगत रूप से रखता है। लेकिन किसी दिए गए प्रोजेक्ट में शैली की स्थिरता एक बहुत अच्छा विचार है। मैं एक शैली के लिए बहुत अधिक कोड चाहता हूं, मैं एक दिए गए फ़ंक्शन में कई शैलियों से निपटना पसंद करता हूं।

यहाँ स्पष्ट रूप से चंचल लेखन का एक उदाहरण है:

However, there is one special case, namely functions: they have the
opening brace at the beginning of the next line, thus:

int function(int x)
{
    body of function
}

Heretic people all over the world have claimed that this inconsistency
is ...  well ...  inconsistent, but all right-thinking people know that
(a) K&R are _right_ and (b) K&R are right.  Besides, functions are
special anyway (you can't nest them in C).

चंचल (1)।

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

दूसरी ओर, यदि कोई व्यक्ति लिनक्स कर्नेल को अक्सर इंडेंटिंग के तीन स्तरों से अधिक के बिना लिख ​​सकता है, तो तीन-स्तरीय सीमा आपके अपने कोड में थोड़ी देर के लिए प्रयास करने के लायक व्यायाम हो सकती है, बस यह देखने के लिए कि यह आपको कहां ले जाता है। यह एक लिंग परिवर्तन की तरह नहीं है, आप जानते हैं। यह जीवन भर की प्रतिबद्धता नहीं है।

यदि आप इंटरनेट पर किसी ऐसे व्यक्ति में भाग लेते हैं, जो सोचता है कि वह प्रोग्रामिंग को टॉर्वाल्ड्स (2) से बेहतर समझता है, तो आप जानते हैं कि किस तरह के लोग इंटरनेट पर बड़ी बात करना पसंद करते हैं।

दूसरी ओर, वह आठ-स्पेस टैब के बारे में आपराधिक रूप से गलत है। यह एक ऐसे आदमी का लालच है जिसे संयम में रखा जाना चाहिए और एक स्लॉट के माध्यम से खिलाया जाना चाहिए। चार स्थान स्पष्ट रूप से सही हैं।

(1) लेकिन ध्यान दें कि कैसे वह ग़लतियों से पहले एक जगह डालता है, और दो जगह उनके बाद, और दो जगह पूरी तरह से रुकने के बाद। गलत, गलत, गलत। और फिर वह चरवाहों को पालने के लिए ब्रेज़ेन पित्त है। विधर्मी तुम, Torvalds है! आप ही हैं!

(२) यदि आप " सोर्स कंट्रोल सिस्टम को कैसे डिज़ाइन करें " के बारे में बात करना चाहते हैं , तो बहस के लिए कुछ जगह हो सकती है।

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

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


3
वंडरफुल जवाब। उन मामलों में से एक जो +2 के लायक होगा ... (नोट: .इस टिप्पणी में आस-पास कोई गलत स्थान नहीं ; ;-))
सेमीस्टर

2
लाइनस का परिचय पैराग्राफ जो आपने बताया है, ऐसा करना बहुत महत्वपूर्ण है! मुझे लगता है कि पहला वाक्य संदर्भ के लिए भी बहुत महत्वपूर्ण है, विशेष preferred coding styleरूप से और साथ हीbut this is what goes for anything that I have to be able to maintain
क्रिस हास

9

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

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

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


3

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


1

यह कुत्ते को घेरने वाली पूंछ का एक पाठ्यपुस्तक मामला प्रतीत होता है।

यदि आपके पास एक 80 वर्ण का डिस्प्ले है, तो बेशक आप कोशिश कर रहे हैं और कोड को सबसे अच्छा बना सकते हैं, भले ही वह कोड के लिए सबसे अच्छी संरचना का उत्पादन न करे

शेष बिंदुओं को अपने सिर पर रखना:

मुझे लगा कि यह एक अस्वीकार्य अभ्यास है।

मुझे लगता है कि आप इसमें बहुत अधिक पढ़ रहे हैं। संदर्भ को ठीक से समझे बिना आप जो कुछ भी पढ़ते हैं उसे सुसमाचार के रूप में लेने के आग्रह का विरोध करें।

क्या वह मजाक कर रहा था?

संदर्भ का पता लगाना कठिन है, लेकिन ऊपर मेरा मूल बिंदु देखें।

क्या यह भाषा या अनुप्रयोग पर निर्भर करता है?

बहुत ज़्यादा। किसी भी मेनफ़्रेम / मिडरेंज भाषा को लें जहाँ आपको टर्मिनल (या टर्मिनल एमुलेटर) पर कोडिंग करने की संभावना हो।

क्या कुछ चीजें हैं जो बिल्कुल तीन या अधिक स्तर के लूपिंग की आवश्यकता होती हैं?

हां, कुछ पाशविक बल एल्गोरिदम में यह बहुत आम है। प्रॉजेक्ट 31 को प्रॉजेक्ट यूलर पर देखें । यह एक समस्या का एक उत्कृष्ट उदाहरण है जिसे कई लूप्स (8 सटीक होने के लिए) का उपयोग करके क्रूर बल के साथ हल किया जा सकता है।


1
ऐसा लगता है कि समस्या 31 को ब्रूटफोर्स की आवश्यकता नहीं है और इसे डायनेमिक प्रोग्रामिंग एल्गोरिथ्म का उपयोग करके हल किया जा सकता है (संपादित करें: जिसका अर्थ है कि यदि आप एक ब्रूटफोर्स एल्गोरिथ्म का उपयोग कर रहे हैं तो आपकी कोड संरचना सबसे अच्छी नहीं है)। इसके अलावा, लिनुस का कहना है कि यदि आपके कोड को कई स्तरों के इंडेंटेशन की आवश्यकता होती है, तो संभवतः यह कोड के लिए सबसे अच्छी संरचना नहीं है।
विंसेंट सैवर्ड

2
@VincentSavard ने कभी नहीं कहा कि इसके लिए बल की आवश्यकता है । अपने 2 अंक से असहमत - कभी-कभी यह सबसे स्पष्ट और सबसे रसीला दृष्टिकोण होता है, न कि कुछ मामलों में सबसे कुशल का उल्लेख करने के लिए।
रॉबी डी डे

1
इस तरह की समस्या के साथ मैं आमतौर पर छोरों को इंडेंट नहीं करता हूं। मुझे लगता है कि मेरे पास 20 नेस्टेड लूप्स के साथ एक मामला था, लिखने के लिए बिल्कुल तुच्छ, और कोई इंडेंटेशन नहीं था ताकि आप देख सकें कि लूप लगभग समान थे।
gnasher729

1
@RobbieDee: मेरा कहना यह है कि कई लूप्स द्वारा हल की गई आपकी समस्या का उदाहरण यह है कि आपका एल्गोरिथ्म एक गतिशील प्रोग्रामिंग समाधान के रूप में कुशल नहीं है, जिसे इंडेंटेशन के कई स्तरों की आवश्यकता नहीं है। इस प्रकार, जैसा कि लिनस ने कहा, एक बेहतर समाधान का उपयोग करके आपके इंडेंटेशन के स्तर को हटाया जा सकता है। आपने मेरी दूसरी बात को भी गलत समझा क्योंकि मैं आपकी कही गई बातों से सहमत हूं। कभी-कभी , यह सबसे अच्छा समाधान है। कभी-कभी अक्सर नहीं होता है, और संभावना नहीं है।
विंसेंट सवार्ड

1
लिनुस ने बहुत स्पष्ट रूप से कहा कि यदि कुछ कोड को समस्या -31 को ढुलमुल बनाने की आवश्यकता होती है, तो आप वैसे भी खराब हो जाएंगे - यह तेज या सरल नहीं होगा, और कर्नेल संचालन तेज और सरल होना चाहिए। कर्नेल में किसी भी O (n ^ 4) को शामिल करना प्रदर्शन या सेवा की समस्याओं से इनकार करने का एक महत्वपूर्ण जोखिम है, इसलिए इस संदर्भ में अनुशंसा केवल यह चेतावनी देती है कि यह कोड का संकेत है जो मौलिक रूप से अनुचित हो सकता है और लिनक्स में चाहता है।
पीटरिस

0

क्या लिनुस मजाक कर रहा था?

नहीं, वे आधिकारिक दिशानिर्देश हैं।

क्या यह भाषा या अनुप्रयोग पर निर्भर करता है?

कोडिंग दिशा-निर्देश आमतौर पर भाषा और अनुप्रयोग पर निर्भर होते हैं, हालांकि गहरी नेस्टेड कोड हमेशा पाठक को कर देता है।

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

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

यह मनमाना है, और स्पष्ट रूप से उनके लिए पर्याप्त है।

क्या कुछ चीजें हैं जो बिल्कुल तीन या अधिक स्तर के लूपिंग की आवश्यकता होती हैं?

एल्गोरिथम-वार, संभवतः, हालांकि, पर्याप्त रूप से अभिव्यंजक भाषाओं में आप हमेशा कोड को छोटे विखंडू में बदल सकते हैं (चाहे फ़ंक्शन या क्लोजर के साथ)।

आप स्पष्ट रूप से छोटे घोंसले के शिकार और बहुत सारे छोटे कार्यों के साथ मोटे तौर पर कोड लिख सकते हैं, जो कभी भी एक दूसरे को अपना अनुबंध बताए बिना बुला सकते हैं ...

... हालाँकि, स्पष्ट अनुबंध वाले छोटे कार्य सामान्य रूप से स्पष्ट अनुबंध वाले बड़े कार्यों की तुलना में ऑडिट करने में बहुत आसान होते हैं।


2
हालांकि यह आधिकारिक दिशानिर्देश हो सकता है, यह कर्नेल कोड में उन स्थानों को खोजने के लिए तुच्छ है जहां दिशानिर्देश लागू नहीं किया गया है।
18

1
@ माइक: सभी दिशा-निर्देशों को स्वचालित रूप से लागू करने के लिए और अधिक कारण ...
Matthieu M.

1
@MatthieuM। क्या आप सुनिश्चित हैं कि आप दिशानिर्देशों और अनिवार्य आवश्यकताओं के बीच अंतर को समझते हैं? एक सामान्य "अंगूठे का नियम" (यदि आप चाहें तो एक दिशानिर्देश), दिशा-निर्देश सिफारिशों की तरह हैं और लागू नहीं किए गए हैं।
ब्रेंडन
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.