हार्ड कोडिंग के प्रति आपका दृष्टिकोण क्या है?

Question

मेरा यह है:

हार्ड कोडिंग रास्ता है! मेरी सारी समस्याएं दूर हो गईं। बस इसे एक-एक करके कोड करें। और समस्याएं वापस आती हैं आपके दिन को मार दें।

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

Answer 1

हार्डकोडिंग कुछ ऐसा है जो जितना संभव हो से बचा जाना चाहिए।

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

लेकिन मुझे कुछ मामलों में पता है कि हमें विशेष रूप से कोड डीबग करने में इसकी आवश्यकता है। जिस तरह से मैं सुझाव देता हूं: सबसे पहले हार्ड कोड के साथ कोड विकसित करें, इसे स्थिर बनाएं और हार्डकोड को खत्म करें ...

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

Answer 2

मैं आमतौर पर कठोर कोड की बजाय कॉन्फ़िगरेशन फ़ाइल में मानों को डालता हूं और डालता हूं। यदि कोई मान हार्ड-कोड किया जाना चाहिए, तो मैं हार्ड-कोडेड मान के साथ स्थिर बना देता हूं और कोड संदर्भ में हर जगह एक ही निरंतर संदर्भ देता है। यदि मूल्य को बदलने की जरूरत है तो इसे एक ही स्थान पर किया जा सकता है।

आवेदन-व्यापी स्थिरांक के लिए, मैं आम तौर पर एक वर्ग बनाता हूं और उसमें स्थिरांक बनाता हूं।

Answer 3

हार्ड कोडिंग जाने का रास्ता है!

लेकिन एंथनी ने उल्लेख किया है, इसलिए मैंने कॉन्फ़िगर करने योग्य मान अपनी कक्षा में रखे हैं। इस तरह वे संकलन समय पर कॉन्फ़िगर करने योग्य हैं, लेकिन अतिरिक्त जटिलताओं के बिना जो बाहरी xml/txt फ़ाइल कॉन्फ़िगरेशन के साथ आते हैं।

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

यदि आपको विभिन्न ग्राहकों के लिए अलग-अलग कॉन्फ़िगरेशन की आवश्यकता है, तो कोई समस्या नहीं है, हार्ड कोडित मानों को अपनी स्वयं की असेंबली/डीएलएल में रखें और प्रति ग्राहक विभिन्न कॉन्फ़िगरेशन असेंबली तैनात करें।

Ayende कहते हैं, hard coding everything परिवर्तन को सक्षम करने की कुंजी है।

Answer 4

किसी ऐसे व्यक्ति के रूप में जिसने मेरे शुरुआती दिनों में हार्ड कोडिंग के साथ कुछ अनुभव किया है (किसी को भी दोस्त न बताएं), मैं आश्वस्त रूप से आपको बता सकता हूं कि यह आपको वापस लेने के लिए वापस आ जाएगा। इस एप्लिकेशन को मैंने बनाया है (जिसे मैं अभी बात नहीं करता) जो पूरी तरह से री-लिखित कारण था क्योंकि इसमें बहुत सी हार्ड-कोडित सामग्री थी। वह 1 99 8 में वापस था।

तब तक ऐसा न करें जब तक कि आप भविष्य में उस ग्राहक का समर्थन नहीं करना चाहते हैं। जिस समय आप बचाते हैं, वह समय बाद में तय करने में व्यतीत होगा।

Answer 5

ऐसे कई कारक शामिल हैं जो किसी भी मामले को कवर करने के लिए मुश्किल से नहीं हैं।

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

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

हार्ड कोडिंग वैसे भी खराब है, लेकिन मैं सही तरीके से दस्तावेज करता हूं, यह अगले व्यक्ति का जीवन अधिक आसान बना सकता है, और संभवतः कम से कम आपको शाप नहीं देगा;)।

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

Answer 6

हार्डकोडिंग के साथ कुछ भी गलत नहीं है, बशर्ते सही कारणों से यह सही हो!

"इसे सही करना" का अर्थ है आपके सभी हार्ड कोडिंग को एक या दो मॉड्यूल में केंद्रित करना।

सी के लिए कोड में सभी मानों को परिभाषित करने के लिए जावा के लिए कोड.जावा वर्ग है जो सार्वजनिक स्थिरांक से भरा है।

हार्ड कोडिंग के लिए कई "सही कारण" हैं।

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

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

Answer 7

जो चाहते थे उसे पाने में कम समय लगता है।

यह लगभग कहने जैसा है, "मुझे बिना टिप्पणी के मेरे कोड लिखना पसंद है क्योंकि मुझे जो चाहिए वह पाने में कम समय लगता है।"

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

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

Answer 8

संकल्पनात्मक रूप से मुझे बहुत अधिक हार्ड कोडिंग पसंद नहीं है।

लेकिन प्रैक्सिस में मैं कुछ मूल्यों को कड़ी मेहनत करता हूं। हार्ड-कोड के मुख्य कारण हैं:

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

हैं कुछ "हार्ड-कोड के लिए सबसे अच्छा अभ्यास के" मुझे लगता है कि कभी नहीं से अधिक इंजीनियरिंग कर रहे हैं:

• हार्ड कोडित मूल्यों हमेशा स्थिरांक में एक केंद्रीय स्थानों पर घोषित किया जाना चाहिए।
• भले ही कोई मान हार्ड-कोड किया गया हो, फिर भी इसे घटकों के लिए तर्क के रूप में पारित किया जाना चाहिए, जिस पर ध्यान नहीं दिया जाना चाहिए कि मूल्य कहां आता है। यह आपके घटक को पुन: प्रयोज्य बनाता है।

इससे हार्ड-कोडित मानों को बाद में किसी अन्य स्थान पर ले जाना संभव हो जाता है।

Answer 9

आईटी में सिल्वर बुलेट मौजूद नहीं हैं।

• स्मार्ट होने पर ऐसा करें।
• अगर यह गूंगा है तो ऐसा मत करो।

अगर कोई आपको गूंगा चीज़ करने के लिए कहता है, तो ईमेल थ्रेड को सहेजें और अपना जेओओ बचाएं।

Answer 10

अगर मैं एक char * जरूरत है 12 अक्षर को इंगित करने के लिए, मैं सुरक्षित रूप से लिख सकते हैं malloc(12) क्योंकि sizeof(char) हमेशा 1. होगा यदि मैं एक int * 12 पूर्णांकों को इंगित करने की जरूरत है, मैं malloc(12 * sizeof(int)) लिखें।

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

Answer 11

मैं डिफ़ॉल्ट मान कोडिंग कठिन लगता है सब कुछ है कि विन्यास होने की आवश्यकता हो सकती है के लिए जाने का रास्ता है:

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

इस तरह हमारे पास दो विकल्प बाद में हैं।यदि कोई ग्राहक कुछ अलग करना चाहता है, तो हम इसे कॉन्फ़िगरेशन फ़ाइल में बदल सकते हैं। और हम इसे उपयोगकर्ता कॉन्फ़िगर करने योग्य बनाने के लिए हमारे सेटिंग्स संवाद को भी कॉन्फ़िगर कर सकते हैं।

तो प्रभावी रूप से हमारे पास हार्ड कोड हैं, जिन्हें कॉन्फ़िगर द्वारा ओवरराइड किया जा सकता है, जिसे उपयोगकर्ता वरीयताओं द्वारा ओवरराइड किया जा सकता है।

समस्या सिर्फ सभी वरीयताओं कुंजी दस्तावेज़ के लिए ...

Answer 12

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

Answer 13

आम तौर पर इसे लिखने से कोड को बनाए रखने में अधिक समय और पैसा खर्च किया जाता है। कोड पर खर्च किए गए कुल का 80% आमतौर पर रखरखाव अवधि के दौरान खर्च किया जाता है। इसलिए जो भी रखरखाव कठिन बनाता है, वह अंततः पहली बार ऐसा करने से अधिक खर्च करेगा। हार्ड-कोडिंग निश्चित रूप से एक चीज है जो रखरखाव को कठिन बनाती है, और इसके परिणामस्वरूप एक बुरा विचार है।

• यह तेजी से
• यह सरल

इसका मतलब यह है कम CPU लोड, यानी कम बिजली की खपत, कम या है:

Answer 14

एम्बेडेड और महत्वपूर्ण सॉफ्टवेयर में, hardcoding दो मुख्य फायदे हैं कोई गतिशील स्मृति आवंटन, कम एल्गोरिदमिक जटिलता, यानी आसान डिबगिंग, ...

आमतौर पर, हार्ड कोडेड डेटा को अधिक रखरखाव के लिए एकल हेडर फ़ाइल में रखा जाता है Nability।

इसके अलावा, डेटाबेस से इस हेडर फ़ाइल की स्वचालित पीढ़ी द्वारा लचीलापन प्रदान किया जाता है।

Answer 15

मैं हमेशा एक निरंतर बना देता हूं, लेकिन जितना संभव हो सके/समझदार हो जाता है कि इसका "केवल" उपयोग होना चाहिए।

यदि मुझे इकाई में कहीं और इसकी आवश्यकता है, तो यह इकाई के शीर्ष पर ले जाया जाता है।

यदि इसके बाद किसी अन्य इकाई में आवश्यकता होती है, तो निरंतर एक सेटिंग इकाई में स्थानांतरित हो जाता है।

कोई चाहता है यह अस्थिर यह (यदि नहीं पहले से ही) सेटिंग्स इकाई में ले जाया गया है, और एक कॉन्फ़िग फ़ाइल आदि

से सेट हो जाता है दिन नाम आप बात देना इसके प्रलेखन है के अंत में, कम से कम इसका मतलब है कि आप 73 को किसी भी व्यक्ति के साथ मिश्रित नहीं करते हैं 73. यदि आप देखते हैं कि मेरा क्या मतलब है।

Answer 16

सी/सी ++ में हार्ड कोड किए गए तारों के संबंध में; मैं आमतौर पर उन्हें हार्ड कोडिंग से बचने का सबसे आसान तरीका बताता हूं (हालांकि एक अर्थ में जो अभी भी हार्ड कोडित है)। इसका कारण यह है कि एक परिभाषित पहचानकर्ता जो गलत वर्तनी है उसे संकलक द्वारा पकड़ा जाएगा, जबकि उद्धरण चिह्नों के बीच कुछ भी नहीं होगा।

Answer 17

कॉन्फ़िगरेशन के लिए मेरा दृष्टिकोण? यह अक्सर खराब और बहुत आकस्मिक रूप से किया जाता है - टीसीओ बढ़ाना क्योंकि उपयोगकर्ता कॉन्फ़िगर करने योग्य मानों के 100s को ग्रोक करने का प्रयास करते हैं। आवश्यक साबित होने पर केवल कॉन्फ़िगरेशन (सॉफ्ट कोडिंग) जोड़ें।

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

हालांकि, विरोधी पैटर्न के इस प्रकार बहुत आम है:।

File.Open(configuration["widgetsFileStorage"] + "/" + widgetImage) 

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

LinkWriter.href=configuration["supportUrl"] 

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

File.Open(new WidgetFileLocater().GetUncPath(widgetImage)) 

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

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

चेतावनी: मेरा दृष्टिकोण एक पुनरावृत्ति रिलीज चक्र मानता है। यदि आपके पास माइक्रोसॉफ्ट की तरह 2-10 साल का रिलीज चक्र है, तो आप कई और मूल्यों को कॉन्फ़िगर करने के पक्ष में पूर्वाग्रह करना चाहते हैं।