क्या हमारे अनुप्रयोगों में मूल्यों को फिर से परिभाषित करना एक अच्छा विचार है?


45

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


2
एक विन्यास पैरामीटर आपकी मदद करेगा
गोपी

53
आप कभी नहीं जान piसकते हैं कि कब मूल्य बदल सकता है ...
गाबे

12
यार, मुझे लगता है कि @gabe जैसे लोग इस "नियम" का कारण हैं। यदि आप अपने कोड में 20 स्थानों पर 3.14 दोहराते हैं और फिर पाते हैं कि आपको वास्तव में अधिक सटीकता की आवश्यकता है, तो आप खराब हैं। मुझे यह महसूस नहीं हुआ कि यह स्पष्ट नहीं था।
बिल के

17
वह थोड़ा असभ्य था, @ बाल। @ गैब स्पष्ट रूप से मजाक कर रहा था, लेकिन उससे अलग, यह सवाल हार्डकॉडिंग बनाम कॉन्फिगरेशन मापदंडों के बारे में था, न कि कई स्थानों पर एक निरंतर बनाम दोहराए गए जादू की संख्या का उपयोग करके।
डेविड कॉनराड

1
हां, हार्डकोडिंग कभी-कभी एक अच्छा विचार हो सकता है। "सॉफ्टकोडिंग" एंटी-पैटर्न पर विकिपीडिया लेख देखें।
user16764

जवाबों:


64

हां, लेकिन इसे स्पष्ट करें

करना:

मत करो:


44
कौन सा क्लीनर है, diameter = 2 * radiusया diameter = RADIUS_TO_DIAMETER_FACTOR * radius? वास्तव में कोने के मामले हैं जहां एक जादू नंबर बेहतर समाधान हो सकता है।
जूनस पुलका

5
मैं इस जवाब से पर्याप्त सहमत नहीं हो सकता। मैं एक उपन्यासकार होने की तरह प्रोग्रामिंग के बारे में सोचता हूं। आप अपनी कहानी कोड के माध्यम से बताएं और यदि लोग तर्क को समझ नहीं पाते हैं तो यह मेरे विचार से आपके कोड को बेकार बना देता है। यही कारण है कि अच्छी तरह से सोचा नामकरण सम्मेलनों अनिवार्य रूप से पठनीयता के लिए कर रहे हैं। इसके अलावा, जादू की संख्या का उपयोग करने का कोई अच्छा कारण नहीं है। जादू की संख्याओं का उपयोग करके आप समीकरण से "क्यों" हटाते हैं और इसे समझना अधिक कठिन बनाते हैं। उदाहरण के लिए: "व्यास = 2 * त्रिज्या" दोनों के लिए क्या है? यह "व्यास = RADIUS_TO_DIAMETER_FACTOR * त्रिज्या" बहुत अधिक समझ में आता है।
क्रिस

9
व्यास = 2 * त्रिज्या हाई स्कूल के गणित से सीधे है। "2" का नामकरण न करने का कारण यह है कि इसके लिए किसी भी चीज़ का मूल्य होना भौतिकी या गणित या दोनों के नियमों में बदलाव की आवश्यकता होगी। (दूसरी तरफ, पाई, या प्लैंक का नामकरण सरल पठनीयता के लिए एक अच्छा कदम है)।
जल्दी_अगले

8
@ जून: पिफ़्ट। निश्चित रूप से तुम्हारा मतलब है diameter = radius << 1? मुझे लगता है कि यह भी हो सकता है diameter = radius << RADIUS_TO_DIAMETER_BITS_TO_SHIFT
चींटी

4
कैसे 'कुछ कुछdiameter = radius.toDiameter()
कार्सन मायर्स

26

इस प्रश्नोत्तर के बारे में मुझे जो कुछ अजीब लगता है वह यह है कि किसी ने वास्तव में "हार्ड-कोड" को स्पष्ट रूप से परिभाषित करने का प्रयास नहीं किया है या इससे भी महत्वपूर्ण बात यह है कि विकल्प।

tl; डॉ: हाँ, यह है कभी कभी हार्ड कोड मूल्यों के लिए एक अच्छा विचार है, लेकिन वहाँ के रूप में कोई सरल नियम है जब ; यह पूरी तरह से संदर्भ पर निर्भर करता है।

सवाल इसे मूल्यों तक सीमित कर देता है , जिसका मतलब है कि मैं जादू की संख्याओं को लेता हूं , लेकिन वे एक अच्छा विचार है या नहीं इसका जवाब यह है कि वे वास्तव में किसके लिए उपयोग किए जाते हैं!

"हार्ड-कोडित" मूल्यों के कई उदाहरण हैं:

  • कॉन्फ़िगरेशन मान

    जब भी मैं जैसे बयान देखता हूं, मैं उखड़ जाता हूं command.Timeout = 600। क्यों 600? किसने तय किया? क्या यह समय से पहले खत्म हो गया था, और किसी ने अंतर्निहित प्रदर्शन के मुद्दे को ठीक करने के बजाय हैक के रूप में टाइमआउट उठाया था? या यह वास्तव में प्रसंस्करण समय के लिए कुछ ज्ञात और प्रलेखित अपेक्षा है?

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

  • गणित के सूत्र

    सूत्र आमतौर पर बहुत स्थिर होते हैं, जैसे कि अंदर निरंतर मूल्यों की प्रकृति वास्तव में महत्वपूर्ण नहीं है। एक पिरामिड का आयतन (1/3) b * h है। क्या हमें परवाह है कि 1 या 3 कहाँ से आया है? ज़रुरी नहीं। पिछले टिप्पणीकार ने ठीक ही बताया कि diameter = radius * 2शायद इससे बेहतर है diameter = radius * RADIUS_TO_DIAMETER_CONVERSION_FACTOR- लेकिन यह एक गलत द्वंद्व है।

    इस प्रकार के परिदृश्य के लिए आपको क्या करना चाहिए, एक फ़ंक्शन बना रहा है । मुझे यह जानने की आवश्यकता नहीं है कि आप कैसे सूत्र के साथ आए , लेकिन मुझे अभी भी यह जानने की आवश्यकता है कि इसके लिए क्या है । अगर, ऊपर लिखे किसी भी बकवास के बजाय, मैं लिखता हूं volume = GetVolumeOfPyramid(base, height)तो अचानक सब कुछ बहुत स्पष्ट हो जाता है, और फ़ंक्शन के अंदर मैजिक नंबर होना पूरी तरह से ठीक है ( return base * height / 3) क्योंकि यह स्पष्ट है कि वे सूत्र का सिर्फ एक हिस्सा हैं।

    यहाँ कुंजी बेशक छोटे और सरल कार्य है। यह 10 तर्कों और गणना की 30 पंक्तियों के साथ कार्यों के लिए काम नहीं करता है। उस स्थिति में फ़ंक्शन कंपोजिशन या स्थिरांक का उपयोग करें।

  • डोमेन / व्यावसायिक नियम

    यह हमेशा ग्रे क्षेत्र होता है क्योंकि यह इस बात पर निर्भर करता है कि वास्तव में मूल्य क्या है। अधिकांश समय, यह इन विशेष जादू की संख्याएं होती हैं जो स्थिरांक में बदलने के लिए उम्मीदवार हैं, क्योंकि इससे प्रोग्राम लॉजिक को जटिल किए बिना प्रोग्राम को समझना आसान हो जाता है। परीक्षण पर विचार if Age < 19बनाम if Age < LegalDrinkingAge; आप शायद यह पता लगा सकते हैं कि निरंतर के बिना क्या चल रहा है, लेकिन वर्णनात्मक शीर्षक के साथ यह आसान है।

    उदाहरण के लिए, ये कार्य अमूर्तता के लिए भी उम्मीदवार बन सकते हैंfunction isLegalDrinkingAge(age) { return age >= 19 } । केवल एक चीज यह है कि अक्सर आपका व्यावसायिक तर्क उससे कहीं अधिक जटिल होता है, और प्रत्येक 20-30 मापदंडों के साथ दर्जनों कार्यों को लिखना शुरू करने का कोई मतलब नहीं हो सकता है। यदि वस्तुओं और / या कार्यों के आधार पर स्पष्ट अमूर्तता नहीं है तो स्थिरांक का सहारा लेना ठीक है।

    कैविएट, यदि आप कर विभाग के लिए काम कर रहे हैं, तो यह वास्तव में, वास्तव में बोझिल और ईमानदारी से लिखने के लिए व्यर्थ हो जाता है AttachForm(FORM_CODE_FOR_SINGLE_TAXPAYER_FILING_JOINTLY_FOR_DEPRECIATION_ON_ARMPIT_HAIR)। आप ऐसा नहीं करने जा रहे हैं, आप AttachForm("B-46")इसलिए जा रहे हैं क्योंकि हर एक डेवलपर जिसने कभी काम किया है या कभी काम करेगा वहाँ पता चल रहा है कि "बी -46" एकल करदाता फाइलिंग ब्ला ब्ला ब्ला के लिए फॉर्म कोड है - फ़ॉर्म कोड स्वयं डोमेन का हिस्सा हैं, वे कभी नहीं बदलते हैं, इसलिए वे वास्तव में जादू नंबर नहीं हैं।

    इसलिए आपको व्यवसाय तर्क में संयम से उपयोग करना होगा; मूल रूप से आपको यह समझना होगा कि "जादू नंबर" वास्तव में एक जादू नंबर है या यदि यह डोमेन का एक प्रसिद्ध पहलू है। यदि यह डोमेन है, तो आप इसे नरम-कोड नहीं करते हैं, जब तक कि यह वास्तव में अच्छा मौका न हो, यह बदल जाएगा।

  • त्रुटि कोड और स्थिति ध्वज

    ये कभी भी हार्ड-कोड के लिए ठीक नहीं हैं , क्योंकि कोई भी गरीब कमीना जो कभी भी Previous action failed due to error code 46आपको बता सकता है। यदि आपकी भाषा इसका समर्थन करती है, तो आपको एक गणना प्रकार का उपयोग करना चाहिए। अन्यथा, आपके पास आमतौर पर एक संपूर्ण फ़ाइल / मॉड्यूल होगा जो किसी विशेष त्रुटि प्रकार के लिए मान्य मानों को निर्दिष्ट करने वाले स्थिरांक से भरा होता है।

    कभी भी मुझे return 42एक त्रुटि हैंडलर में देखने की अनुमति न दें ? कोई बहना नहीं।

मैंने शायद कई परिदृश्यों को छोड़ दिया, लेकिन मुझे लगता है कि उनमें से अधिकांश को शामिल किया गया है।

तो, हाँ, यह कभी-कभी कठोर कोड सामग्री के लिए स्वीकार्य अभ्यास है। बस इसके बारे में आलसी मत बनो; यह सादे पुराने मैला कोड के बजाय एक सचेत निर्णय होना चाहिए।


अच्छे टूटने के लिए धन्यवाद! - अधिकांश लोग सभी विकल्पों के माध्यम से नहीं सोचते हैं कि मैं "पर्यावरण कॉन्फ़िगरेशन" जोड़ूंगा - मुझे लगता है कि इनसे बचा जाना चाहिए (हार्ड-कोडित नहीं), क्योंकि अधिकांश डेटा को एक कॉन्फ़िगरेशन फ़ाइल या डेटाबेस में रखा जाना चाहिए। यह "डेटा और तर्क को अलग रखने" के प्रमुख का अनुसरण करता है जो कि एमवीसी या एमवीवीएम का एक मुख्य आधार है। string TestServerVar = "फू"; string ProdServerVal = "बार";
m1m1k

7

पहचानकर्ता को एक नंबर पर असाइन करने के विभिन्न कारण हैं।

  • यदि संख्या बदल सकती है, तो उसके पास एक पहचानकर्ता होना चाहिए। NUMBER_OF_PLANETS को 9 के हर उदाहरण के लिए खोजना आसान है और इस पर विचार करें कि क्या इसे 8 में बदल दिया जाना चाहिए (ध्यान दें कि उपयोगकर्ता द्वारा दिखाई देने वाले तार को बदलना पड़ सकता है यदि सॉफ़्टवेयर को कभी भी किसी अन्य भाषा में उपयोग किया जाना है, और वह है अग्रिम में भविष्यवाणी करने के लिए एक कठिन बात।)
  • यदि संख्या किसी भी तरह से लिखना कठिन है। पाई जैसे स्थिरांक के लिए, यह संभवतः कई स्थानों पर इसे फिर से लिखने की तुलना में एक अधिकतम-सटीक परिभाषा देने के लिए बेहतर है, संभवतः गलत तरीके से।
  • यदि संख्या विभिन्न स्थानों पर होती है। आपको आस-पास के कार्यों में 45 के दो उपयोगों को देखना चाहिए और यदि वे एक ही बात का मतलब है तो आश्चर्य होगा।
  • यदि अर्थ तुरंत पहचानने योग्य नहीं है। यह मान लेना सुरक्षित है कि हर कोई जानता है कि 3.14159265 ... क्या है। यह मान लेना सुरक्षित नहीं है कि हर कोई गुरुत्वाकर्षण स्थिरांक या pi / 2 को पहचान लेगा। ("यहां हर कोई" सॉफ़्टवेयर की प्रकृति पर निर्भर करता है। सिस्टम प्रोग्रामर से यूनिक्स अनुमति बिट्स या इस तरह के ऑक्टल प्रतिनिधित्व को जानने की उम्मीद की जा सकती है। नौसेना / समुद्री वास्तुकला सॉफ्टवेयर में, प्रस्तावित पतवार और गति की Froude संख्या की जांच करना। देखें कि क्या यह 1.1 या उससे अधिक है जो किसी को भी पूरी तरह से आत्म-व्याख्यात्मक हो सकता है, जिसे इस पर काम करना चाहिए।)
  • यदि संदर्भ पहचानने योग्य नहीं है। हर कोई जानता है कि एक घंटे में 60 मिनट होते हैं, लेकिन 60 से गुणा या विभाजित करना अस्पष्ट हो सकता है यदि कोई तत्काल संकेत नहीं है कि मात्रा एक समय मान या दर मूल्य है।

यह हमें हार्ड-कोडिंग शाब्दिकों के लिए मापदंड प्रदान करता है। उन्हें अपरिवर्तनीय होना चाहिए, टाइप करना मुश्किल नहीं, केवल एक जगह या संदर्भ में, और पहचानने योग्य अर्थ के साथ। उदाहरण के लिए ARRAY_BEGINNING के रूप में 0 को परिभाषित करने का कोई मतलब नहीं है, या ARRAY_INCREMENT के रूप में 1 है।


5

अन्य उत्तरों के अतिरिक्त। जब संभव हो तार के लिए स्थिरांक का उपयोग करें। बेशक, आप नहीं करना चाहते हैं

const string server_var="server_var";

लेकिन आपके पास होना चाहिए

const string MySelectQuery="select * from mytable;";

(यह मानते हुए कि आपके पास वास्तव में एक क्वेरी है जहां आप एक विशिष्ट तालिका से सभी परिणाम प्राप्त करना चाहते हैं, हमेशा)

इसके अलावा, 0 (आमतौर पर) के अलावा किसी भी संख्या के लिए स्थिरांक का उपयोग करें। यदि आपको 255 के अनुमति बिटमास्क की आवश्यकता है, तो उपयोग न करें

const int 8th_bit=255; //or some other obscure naming scheme that equates to 255.

इसके बजाय उपयोग करें

const int AllowGlobalRead=255;

बेशक, स्थिरांक के साथ, पता है कि कब एन्यूमरेटर्स का उपयोग करना है। उपरोक्त मामला शायद एक में अच्छी तरह से फिट होगा।


typedef enum {state_0 = 0, state_1 = 1, state_2 = 2, ...} ... हंसो मत, मैंने इसे पूरा होते देखा है। उस व्यक्ति को एक गीली मछली के साथ सिर के चारों ओर स्मैक!
जल्दी_अगले

@ निश्चित रूप से अच्छी तरह से आप कुछ और चाहते हैंtypedef enum {init_state=0, parse_state=1, evaluation_state=2, ... }
अर्लज़

6
THIS_NAMING_CONVENTION_IS_RECOMMENDED_FOR_CONSTANTS
स्टॉपर यूसर

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

आप किसी प्रकार की एन्क्रिप्शन या ऑबफ़्यूज़ेशन के साथ संसाधन-फ़ाइल में व्यवसाय-तर्क-संबंधी स्ट्रिंग्स (जैसे SQL क्वेरीज़) को चिपका सकते हैं। यह "जिज्ञासु" उपयोगकर्ताओं को आपके तर्क (या डेटाबेस स्कीमा) को रिवर्स-इंजीनियरिंग से रोक देगा।
टीएमएन

4

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

किसी भी उचित ढांचे में बहुत सी चीजें हार्डकोड की जाती हैं और वे काम करती हैं। अर्थात ऐसा कोई तकनीकी कारण नहीं है कि मैं C # एप्लिकेशन (स्टैटिक शून्य मेन) के प्रवेश बिंदु को बदलने में सक्षम न हो पाऊं, लेकिन हार्डकोडिंग जो किसी भी उपयोगकर्ता के लिए कोई समस्या पैदा नहीं करता है (कभी-कभार SO प्रश्न को छोड़कर )

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

इसलिए, IMHO, यह मूर्खतापूर्ण है कि वे चीजें जो कभी नहीं बदल रही हैं (pi, गुरुत्वाकर्षण स्थिरांक, एक गणितीय सूत्र में एक स्थिरांक - एक गोले का आयतन)।

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

तो, नीचे की रेखा, चाहे वह चीज़ हार्डकोड हो, दो चरों का एक कार्य है:

  • मूल्य बदल जाएगा
  • मूल्य में बदलाव प्रणाली को कैसे प्रभावित करेगा

4

क्या हमारे अनुप्रयोगों में मूल्यों को फिर से परिभाषित करना एक अच्छा विचार है?

मैं केवल हार्डकोड मानों को निर्दिष्ट करता हूं यदि मान विनिर्देश में निर्दिष्ट किए गए हैं (विनिर्देश के अंतिम रिलीज पर), उदाहरण के लिए HTTP ओके प्रतिक्रिया हमेशा रहेगी 200(जब तक कि यह आरएफसी में नहीं बदलता है), इसलिए, आप देखेंगे (मेरे कुछ कोड में) ) स्थिरांक जैसे:

public static final int HTTP_OK = 200;

अन्यथा, मैं गुण फ़ाइल में स्थिरांक संग्रहीत करता हूं।

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


3
  • यदि मान बदल सकता है, और वास्तव में बदल सकता है, तो जब भी संभव हो तब तक नरम-कोड करें जब तक कि प्रयास शामिल नहीं हो, अपेक्षित वापसी से अधिक नहीं है
  • कुछ मूल्यों को नरम-कोडित नहीं किया जा सकता है; उन (दुर्लभ) मामलों में जोनाथन के दिशानिर्देशों का पालन करें

2

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

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

सबसे बड़ा फायदा यह होगा कि आपको समान कॉन्स्टेंट्स कोड के समूहों में एकमात्र अंतर मिल सकते हैं - उन्हें सरणियों में अमूर्त करने से मुझे कुछ फाइलों को उनके आकार के 90% तक कम करने में मदद मिली है और इस बीच कुछ कॉपी और पेस्ट बग्स को ठीक किया है। ।

डेटा निकालने के लिए मुझे अभी तक एक भी फायदा नहीं हुआ है।


2

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

मैंने यह करना समाप्त कर दिया, भले ही तथ्य यह है कि, लाट / लैंग लाइनें चंद्रमा पर बहुत करीब से एक साथ हैं, कहते हैं। और मेरे कार्य में बृहस्पति पर बिंदुओं के बीच काफी कम दूरी होगी। मुझे लगा कि जिस वेबसाइट पर मैं एक अलौकिक स्थान का निर्माण कर रहा हूँ, उसका अंतर बहुत पतला है।


हां, शायद, लेकिन google.com/moon के
13

1

वैसे यह निर्भर करता है कि आपकी भाषा संकलित है या नहीं। यदि यह संकलित नहीं है, तो यह कोई बड़ी बात नहीं है, आप सिर्फ स्रोत कोड को संपादित करते हैं, भले ही यह गैर प्रोग्रामर के लिए थोड़ा नाजुक हो।

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

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

मेरे ओग्रे परियोजना के साथ उदाहरण के लिए, मैं हमेशा कॉन्फिग फाइल का उपयोग कर रहा हूं, एक वैरिएबल लोड करने के लिए जो मैंने एक कॉन्फिगर फाइल में लिखा है।


1

दो मौके जहां स्थिरांक हैं (कम से कम मेरी राय में) ठीक है:

  1. लगातार जो कुछ और से संबंधित नहीं है; आप उन स्थिरांक को बदल सकते हैं जब भी आप बिना कुछ और बदलने के लिए पसंद करते हैं। उदाहरण: ग्रिड कॉलम की डिफ़ॉल्ट चौड़ाई।

  2. बिल्कुल अपरिवर्तनीय, सटीक, स्पष्ट स्थिरांक, जैसे "प्रति सप्ताह दिनों की संख्या"। एक निरंतर के साथ days = weeks * 7प्रतिस्थापित 7करना DAYS_PER_WEEKशायद ही कोई मूल्य प्रदान करता है।


0

मैं जोनाथन से पूरी तरह सहमत हूं लेकिन सभी नियमों के अलावा अपवाद हैं ...

"मैजिक नंबर इन द स्पेक: कोड में मैजिक नंबर"

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

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

उस ने कहा, जब आप इसके बारे में सोचते हैं ... यह बहुत स्पष्ट है इसे स्पष्ट करने के बारे में ...


0

यदि आप पृथ्वी के गुरुत्वाकर्षण स्थिरांक के मान को हार्डकोर कर रहे हैं, तो किसी का ध्यान नहीं जा रहा है। यदि आप अपने प्रॉक्सी सर्वर के आईपी पते को हार्डकोड करते हैं, तो आप परेशानी में हैं।


1
आपको पृथ्वी के गुरुत्वाकर्षण स्थिरांक के लिए अधिक सटीकता की आवश्यकता हो सकती है, इसलिए इसे कई बार हार्डकोड करने से समस्याएं हो सकती हैं।
user281377

1
पीटर नोन? हर्मन के हरमिट्स से?
डेविड कॉनरैड

पृथ्वी पर गुरुत्वाकर्षण त्वरण बहुत ज्यादा है 9.81 m / s ^ 2 अधिकांश अक्षांशों और ऊंचाई के लिए (निश्चित रूप से, यदि आप भूमिगत तेल खोज रहे हैं, या उत्तरी ध्रुव पर ICBM की शूटिंग कर रहे हैं, तो गुरुत्वाकर्षण में भिन्नता जानना बहुत महत्वपूर्ण है बहुत अधिक दशमलव स्थान), अन्य ग्रहों पर गुरुत्वाकर्षण त्वरण के साथ एक अलग संख्या है, लेकिन जहां तक ​​मुझे पता है, ब्रह्मांड के चारों ओर गुरुत्वाकर्षण स्थिर है। बहुत सी भौतिकी है जिसे अगर जी परिवर्तनशील होता तो बदलना होगा।
तंगुरेना

0

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.