क्या प्रोग्राम में डेटा मूल्यों को हार्ड-कोडिंग करने के फायदे हैं?


13

मैं एक स्व-सिखाया गया, नौसिखिया-ईश कोडर हूं, इसलिए अगर मैं प्रोग्रामर लिंगो को नाखून नहीं देता, तो मैं माफी मांगता हूं।

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

ऐसा लगता है कि इसमें शामिल सभी लोग सोचते हैं कि उन्हें रिपोर्ट-जनरेशन प्रोग्राम में हार्ड-कोड डेटा वैल्यूज़ (स्कीमा नहीं, बल्कि डोमेन / वैल्यूज़) चाहिए।

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

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

चूंकि मैं एक डेवलपर नहीं हूं, मैं सोच रहा हूं कि मुझे क्या याद आ रहा है। इस तरह के उपकरण में हार्ड-कोडिंग मूल्यों के क्या फायदे हो सकते हैं? क्या यह आमतौर पर प्रोग्राम कैसे डिज़ाइन किए जाते हैं?



रिपोर्ट क्रॉस-टैब्स हैं, जिसका अर्थ पंक्तियों में मान स्तंभ के रूप में दिखाई देना चाहिए?
ट्यूलेंस कोर्डोवा

1
@ ब्रेंडन - यदि आप रिपोर्ट में हार्ड कोड मान रखते हैं, तो आपको सूची को TWO स्थानों (डेटा स्रोत और रिपोर्ट) में बदलने की आवश्यकता होगी, जबकि यदि रिपोर्ट गतिशील है, तो आपको इसे केवल एक स्थान (रिपोर्ट) में बदलना होगा ।
kwah

1
@ ब्रेंडन आप तीन स्थानों के साथ क्यों समाप्त होंगे? शायद मेरी समझ गलत है, लेकिन मैं एक डेटाबेस से डेटा लाने के लिए एक sql क्वेरी की परिकल्पना कर रहा हूं, एप्लिकेशन विभाग द्वारा दिए गए मानों को / जैसे समूह को एकत्रित / समूहित करेगा। यदि आप कई db प्रश्नों के ओवरहेड के लिए तैयार हैं, तो यदि आप वास्तव में चाहते हैं तो आप अलग-अलग विभाग / भूमिका शीर्षक का चयन कर सकते हैं। किसी भी बिंदु पर एक से अधिक स्थानों पर मौजूद डेटा नहीं है - रिपोर्ट डेटा द्वारा संचालित की जा रही है।
kwah

1
@ बेंडन मैं भी इसे एक जगह होने की आपकी परिभाषा से असहमत हूं - जिस तरह से आप इसका वर्णन करते हैं वह कई स्थानों पर है, पूरे स्रोत कोड में बिखरे हुए हैं।
kwah

जवाबों:


9

विकिपीडिया:

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

हार्ड-कोडिंग को एक एंटीपैटर्न माना जाता है।

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

कभी-कभी आप इसे टाल नहीं सकते हैं लेकिन यह अस्थायी होना चाहिए।

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

  • संदेशों के हार्डकोडिंग से एक कार्यक्रम का अंतर्राष्ट्रीयकरण करना कठिन हो जाता है।
  • हार्डकोडिंग पथ किसी अन्य स्थान के लिए अनुकूल बनाना कठिन बनाते हैं।

हार्डकोडिंग का एकमात्र लाभ कोड का तेजी से वितरण लगता है।


5
ठीक है, लेकिन "केवल लाभ" अक्सर बेहद महत्वपूर्ण है। प्रोग्रामिंग में डिजाइन निर्णय अक्सर भविष्य में प्रूफिंग और त्वरित डिलीवरी के बीच व्यापार बंद के बारे में होते हैं, और इस तरह, हार्ड कोडिंग पूरी तरह से स्वीकार्य विकल्प हो सकता है। कभी-कभी मुश्किल नहीं कोडिंग एक खराब डिजाइन विकल्प है।

-1 मुझे नहीं लगता कि यह एक उपयोगी उत्तर है। यह अनिवार्य रूप से कहता है कि 'सोर्स कोड में मूल्यों को एम्बेड करना अनुचित है' अनुचित है। मुझे लगता है कि ओपी इस बारे में मार्गदर्शन चाहता है कि स्रोत कोड में चीजें कब हो सकती हैं और इसलिए आपकी विकिपीडिया परिभाषा के बाहर है।
नाथन कूपर

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

24

वास्तव में? कोई संभव वैध उपयोग मामलों?

जबकि मैं मानता हूं कि हार्ड-कोडिंग आम तौर पर एक विरोधी-पैटर्न है या कम से कम एक बहुत खराब कोड गंध है , ऐसे बहुत सारे मामले हैं जहां यह समझ में आता है:

  • सादगी ( YAGNI ),
  • इनपुट वास्तव में स्थिर है और कभी नहीं बदलेगा (अर्थात यह एक प्राकृतिक या व्यावसायिक स्थिरांक या किसी का अनुमान लगाता है। जैसे 0, PI, ...,)
  • एम्बेडेड सॉफ़्टवेयर (मेमोरी और आवंटन की बाधाएँ दिमाग में आती हैं),
  • सुरक्षित सॉफ़्टवेयर (ये मान उपलब्ध नहीं हैं और / या आसानी से डिकोड या रिवर्स-इंजीनियर, जैसे क्रिप्टोग्राफिक टोकन और लवण,)
  • उत्पन्न कोड (आपका प्रीप्रोसेसर या जनरेटर कॉन्फ़िगर करने योग्य है, लेकिन हार्ड-कोडित मूल्यों के साथ कोड को बाहर निकालता है),
  • और शायद कुछ और।

फिर भी एक विरोधी पैटर्न ? तो ओवर इंजीनियरिंग है ! यह आपके सॉफ़्टवेयर की जीवन प्रत्याशा के बारे में है !!

ऐसा नहीं है कि मैं कह रहा हूं कि सभी महान कारण हैं, और आम तौर पर मैं हार्ड-कोडित मूल्यों पर गंजा होता हूं। लेकिन कुछ को वैध कारणों से आसानी से पास मिल सकता है।

और सादगी / YAGNI के बारे में पहले एक की देखरेख मत करो या तो यह सोचकर कि यह तुच्छ है: एक सरल स्क्रिप्ट के लिए एक पागल पार्सर और मूल्य चेकर को लागू करने का कोई कारण नहीं है जो संकीर्ण उपयोग के मामले के लिए एक काम बहुत अच्छी तरह से करता है।

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

एंटी-पैटर्न के साथ यही मतलब है: वे स्पेक्ट्रम के दोनों छोरों में मौजूद हैं, और उनकी उपस्थिति आपके कोड की समीक्षा करने वाले व्यक्ति की संवेदनशीलता पर निर्भर करती है।


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

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

वैसे भी, मैं सिर्फ उन मामलों को इंगित कर रहा हूं जहां यह मान्य होगा। मैं यह भी इंगित कर रहा हूं कि यह मेरे आखिरी वाक्य में विवादास्पद होगा। आप हर किसी को खुश नहीं कर सकते हैं और टीमों के पास अलग-अलग कौशल स्तर हैं।
हाइलम

1
@, अपने आप को बहुत छोटा मत बेचिए। आप निश्चित रूप से किसी चीज़ पर हैं। हार्ड कोडिंग के विपरीत, डिपार्टमेंट और जॉब टाइटल फ़ील्ड्स को देखते हुए डेटा को व्यवस्थित करने के लिए एक त्वरित एल्गोरिदम लिखने में आसान और कम समय लगता है Department = ['IT', 'Sales', 'Operations', 'HR', 'Finance']। एक नए विभाग या शीर्षक को पेश किए जाने की स्थिति में हार्ड कोडित सरणी को बनाए रखना बहुत अधिक कठिन होगा।
क्रिस जी

1
आपके पास और अधिक जटिल चीजें हो सकती हैं जो अभी भी हार्डकोड के लिए समझदार हैं। एक है कि मन में आता है कि मैं कुछ साल पहले लिखा था मूल्यों के एक सेट के सभी संभव क्रमपरिवर्तन था। मुझे एक यादृच्छिक वैध दिशा खोजने की जरूरत थी, एक यादृच्छिक क्रमपरिवर्तन को चुनना और फिर पहला वैध परिणाम लेना सबसे कुशल समाधान था और चूंकि यह एक ओ (एन ^ 3) लूप दक्षता में था।
लोरेन Pechtel

4

कई बार हार्ड-कोड मानों के लिए यह ठीक है। उदाहरण के लिए, कुछ संख्याएँ हैं जैसे 0, या एक या विभिन्न n ^ 2-1 बिटमास्क के लिए मान जो एल्गोरिथम के उद्देश्यों के लिए कुछ निश्चित मान होना चाहिए। ऐसे मूल्यों को विन्यास योग्य बनाने के लिए कोई मूल्य नहीं है और केवल मुद्दों की संभावना को खोलता है। दूसरे शब्दों में, यदि मान बदलने से केवल चीजें टूटेंगी, तो शायद इसे हार्डकोड किया जाना चाहिए।

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


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

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

-1

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

हार्ड-कोडिंग इन जोखिमों से काफी हद तक बचता है।

यह कहना मुश्किल नहीं है कि हार्ड-कोडिंग हमेशा या एक अच्छा विचार है। यह खाते में लेने के कारकों में से एक है।

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