जिस स्थान पर मैं काम करता हूं, वहां चर की घोषणाओं के स्थान के लिए स्पष्ट दिशानिर्देश हैं। उसके अनुसार, उन्हें वैश्विक स्तर पर और / या कार्यों की शुरुआत में रखना आवश्यक है, न कि आंतरिक ब्लॉकों में (जैसे कि लूप के लिए)। चूंकि वे मेरे द्वारा अनुभव किए गए व्यक्तियों से अधिक निर्दिष्ट किए गए हैं, मुझे यकीन है कि इसके लिए एक अच्छा कारण होना चाहिए, लेकिन मैं यह पता नहीं लगा सकता कि क्या हो सकता है। यह जानना अच्छा होगा कि क्या किसी बड़े समय पर घोषित किए गए संकलन समय / रन के फायदे हैं।
जवाबों:
मैं दो मुख्य लाभ देखते हैं:
इसके नमक के लायक कोई भी कंपाइलर वैसे भी वैरिएबल के दायरे से दूर हो जाएगा, इसलिए यह शुद्ध रूप से एक चिंताजनक विषय है।
मेरे दो सेंट के लिए, मैं अभी भी कंपाइलर के लिए गुंजाइश के इरादे को परिवहन करने के लिए चर की अंतरतम घोषणा को प्राथमिकता दूंगा। यदि आप एक लूप के भीतर केवल वैरिएबल एक्सेस करने का इरादा रखते हैं, तो आप लूप में वैरिएबल की घोषणा करते समय संकलित समय पर किसी भी बाद के संदर्भ को पकड़ सकते हैं।
अब तक मुझे जो एकमात्र लाभ मिला है, वह कोड सादगी है। Youalways जानता है कि चर घोषणाओं को कहां देखना है और टीम में हर कोई समान कोडिंग शैली को अपनाता है। इन चीजों से कोड रखरखाव आसान हो जाता है लेकिन मुझे यकीन नहीं है कि वे बेहतर कोड लिखना आसान बना देते हैं। मेरा यह मतलब नहीं है कि आप केवल इतना ही बुरा कोड लिखते हैं कि कभी-कभी कोड को उतना अच्छा लिखना मुश्किल होता है। फिर भी यदि विकास दल बड़ा है या उसके सदस्य कोड मानकों का उपयोग कर बार-बार बदलते हैं तो यह सहायक है।
यह स्थिरता को संरक्षित करने के निर्णय की तरह लगता है। यह पड़ोसी स्कोप में विभिन्न चर के लिए समान नामों के उपयोग को भी रोकता है और पठनीयता को बढ़ाता है। जैसा कि गस बताते हैं, आपको यह भी पता होगा कि चर कहां देखना है। मुझे लगता है कि सबसे संकीर्ण गुंजाइश सिद्धांत बेहतर है, क्योंकि यह शीर्ष पर चर अव्यवस्था को रोकता है। बाहरी घोषणा बहुत हद तक एक वर्ग के पहले आईएमओ के निजी सदस्यों की घोषणा की तरह है।
हर भाषा शैली और व्यवहार की प्राथमिकता में भिन्न हो सकती है। इसके बाद जेएसएफ-एवी-नियमों का पालन किया जाता है , जो स्ट्राउस्ट्रपअप कोडिंग मानकों के रूप में इंगित करता है।
ए वी नियम 136
Declarations should be at the smallest feasible scope
इसके लिए तर्क का वर्णन किया गया है
This rule attempts to minimize the number of live variables that must be simultaneously considered. Furthermore, variable declarations should be postponed until enough information is available for full initialization
यदि आप C ++ में हैं, तो जब आप उन्हें पसंद करते हैं, तो चर घोषित करना।
यकीन नहीं तो आप इसे बेस्ट-प्रैक्टिस कह सकते हैं। जब मैं एक नई सी परियोजना के लिए दिशानिर्देश स्थापित करता हूं, तो मैं हमेशा बताता हूं कि जहां वे उपयोग किए जाते हैं, उनके करीब चर घोषित करना बेहतर होता है। दो कारणों से, कोड को बाद में फिर से भरना आसान हो जाता है (यानी जब कोई तरीका निकाला जाता है)। यह कंपाइलर को बेहतर अनुकूलन करने में भी मदद करता है।
मैं इस राय के साथ अकेला नहीं हूं। यहाँ एक प्रश्न है जो समान समस्या से निपटता है: /software/56585/where-do-you-declare-variables-the-top-of-a-method-or-when-you-need -थीम यहाँ उत्तर उन्हें घोषित करने के लिए है जहाँ आप उनका उपयोग करते हैं। रॉबर्ट सी। मार्टिन की पुस्तक 'क्लीन कोड' में भी इसी प्रथा का वर्णन किया गया है।
हालाँकि, यदि आप एक पुराने C- मानक (C-89) का उपयोग करते हैं, तो आपको फ़ंक्शन के शीर्ष पर स्थानीय चर को परिभाषित करना होगा। तो शायद दिशानिर्देश उस समय से एक अवशेष है जब सी -89 का उपयोग किया गया था? यह पूछने के लिए बेहतर है कि उस व्यक्ति ने दिशानिर्देश लिखे कि नियम अभी भी क्यों है।
यदि घोषणा एक क्लॉज के भीतर है कि केवल शायद ही कभी (यदि कभी भी) व्यायाम हो जाता है, लेकिन स्मृति की बहुत आवश्यकता होती है, तो आपकी स्मृति पदचिह्न छोटी होती है (अधिकांश समय) यदि आप फ़ंक्शन की शुरुआत में सब कुछ आवंटित करते हैं।
यदि यह एक लूप के भीतर है, तो आपको मेमोरी को बार-बार रिक्लाइन करना होगा, यह प्रदर्शन के संदर्भ में महंगा हो सकता है।
दोनों तरीकों से काम करने के कारण हैं।
1989 का पुराना सी-मानक केवल एक ब्लॉक की शुरुआत में परिवर्तनीय घोषणाओं की अनुमति देता है।
केवल C99 घोषणाओं को कहीं भी अनुमति दी गई है। हो सकता है कि आपके स्थान ने अभी तक C99 पर स्विच नहीं किया हो।
उन लोगों की तरह लगता है जिन्होंने यह निर्णय लिया है, ऐसे समय में उपयोग किया जाता है जब शीर्ष पर घोषणाएं करना आदर्श था और जहां इसे इस्तेमाल किया जा रहा है, उसके करीब घोषित करने के लिए प्राथमिकता पर स्विच नहीं करना चुना।
मुझे यकीन नहीं है कि इस निरंतरता का स्तर कितना उपयोगी है। कुछ IDE शायद दूसरों की तुलना में चीजों को खोजना आसान बनाते हैं। वैश्विक चर के लिए यह समझ में आता है, लेकिन यदि आपका कार्य इतना लंबा है, तो परिवर्तनशील घोषणाओं को खोजना मुश्किल है, तो आपको बड़ी समस्या है।