क्या कोड पीढ़ी कोड गुणवत्ता बढ़ाती है?


12

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

हम अपने डेटाबेस स्कीमा में इकाई संबंधों का वर्णन करने के लिए XML फ़ाइलों का उपयोग करते हैं, इसलिए वे हमारे ORM ढांचे और HTML रूपों को बनाने में मदद करते हैं जिनका उपयोग संस्थाओं को जोड़ने, हटाने और संशोधित करने के लिए किया जा सकता है।

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

चूंकि मुझे कोड गुणवत्ता की परिभाषा के लिए कहा गया था , इसलिए मुझे यह स्पष्ट करना चाहिए कि मेरा क्या मतलब है सॉफ्टवेयर गुणवत्ता

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


3
कोड गुणवत्ता की आपकी परिभाषा क्या है?
NoChance

@EmmadKareem मैंने मूल प्रश्न पर इसकी एक छोटी परिभाषा जोड़ी है।
platzhirsch

1
मुझे लगता है कि स्वचालित कोड पीढ़ी आपके कोड में स्थिरता और एकरूपता बढ़ाने में मदद करेगी। कुछ मामलों में जो गुणवत्ता में वृद्धि करता है, लेकिन मुझे नहीं लगता कि यह एक कैच-ऑल है।
joshin4colours

जवाबों:


38

कोड जनरेटर जनरेटर लिखने वाले व्यक्ति की तुलना में बेहतर कोड उत्पन्न नहीं कर सकते हैं।

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

मैंने एक बार कोड जनरेटर के लिए एक तर्क सुना था कि एक एकल प्रोग्रामर प्रति दिन कोड की इतनी-और लाइनें उत्पन्न कर सकता है और कोड जनरेटर के साथ, वे हजारों लाइनों का उत्पादन कर सकते हैं! जाहिर है कि यही कारण नहीं है कि हम जनरेटर का उपयोग कर रहे हैं।


6
+ italicized अनुभाग एक हजार बार। कोड जनरेटर को आपके संकलक या C ++ टेम्पलेट तंत्र की तरह कार्य करना चाहिए: आपको कभी भी अपने आउटपुट को मैन्युअल रूप से संपादित नहीं करना चाहिए। यदि आपको बग पर संदेह है तो केवल एक बार आपको आउटपुट पढ़ना चाहिए।
आनोन

1
यह शर्म की बात है कि मैं अधिक वोट नहीं कर सकता ...
फैब्रिकियो अरुजो

@anon: होमनों को आमतौर पर कोड जनरेटर या कंपाइलर के आउटपुट को संपादित नहीं करना चाहिए, लेकिन कभी-कभी एक बिल्ड प्रक्रिया के लिए यह पूरी तरह से उचित हो सकता है जो प्रोग्राम के माध्यम से मशीन-जनरेट किए गए कोड के एक टुकड़े को चलाने के लिए मजबूर करता है जो इसके लिए कुछ संशोधन लागू करता है। ऐसे अवसर भी होते हैं जब एक मानव प्रक्रिया का निर्माण आवश्यक हो सकता है एक निर्माण प्रक्रिया के आउटपुट को संपादित करना यदि बाइट्स की न्यूनतम संख्या को बदलते समय फ़ील्ड कोड को पैच करना आवश्यक है, लेकिन जब कोड को इस तरह से हाथ से घुमाया जाना चाहिए निर्माण प्रक्रिया से सभी फाइलों को भी संग्रहीत करें (न कि केवल स्रोत!) और ...
सुपरकैट

... हाथ से संपादित वस्तु कोड के शब्दार्थ से मेल करने के लिए स्रोत कोड भी अपडेट करें।
सुपरकैट

20

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


3
सहमत, कुछ ओआरएम से निकलने वाला कचरा (किसी के दृष्टिकोण से कचरा जो अच्छी तरह से प्रदर्शन करने वाले डेटाबेस कोड लिखना जानता है) एक अच्छा उदाहरण है। यह अक्सर किसी ऐसे व्यक्ति के लिए पर्याप्त काम करता है जो यह नहीं जानता कि वे क्या सोचते हैं कि यह काम करता है। और नए प्रोग्रामर्स को जनरेटर के बाहर किए जाने वाले कठिन सामान को करने के लिए कौशल नहीं मिलता है क्योंकि वे बुनियादी अवधारणाओं को नहीं समझते हैं।
HLGEM

1
ऊह, +1 या -1 .... एक हाथ पर कोड पीढ़ी उबाऊ दोहरावदार कोड को दूर करने के लिए बहुत उपयोगी है, जहां आपके पास एक परिभाषा है जिसे बस कोड में विस्तारित किया गया है, लेकिन फिर आप सही हैं कि यह सभी तरह से अति प्रयोग हो जाता है 'समय की बचत' जटिलता जो अपने आप में एक विरोधी प्रतिमान को समाप्त करती है।
gbjbaanb

13

मुझे लगता है कि स्वचालित कोड पीढ़ी और कोड गुणवत्ता कुछ हद तक रूढ़िवादी हैं और जरूरी नहीं कि सहसंबंधी हो।

कोड पीढ़ी केवल एक विशिष्ट तकनीकी कार्य को हल करने का एक तरीका है। क्या यह बढ़ी हुई कोड गुणवत्ता में परिणत होता है, इस बात पर निर्भर करता है कि आप क्या कर रहे हैं।

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

मैं आपको एक और उदाहरण दे सकता हूं जब स्वचालित कोड पीढ़ी कोड गुणवत्ता कम कर देती है। यह अलग है ASP.NET WebForms। यह HTML मार्कअप में UI नियंत्रणों के पदानुक्रम का अनुवाद करके स्वचालित कोड पीढ़ी करता है, जो कि सब कुछ लेकिन स्थिर, अनुमानित और प्रबंधनीय है।

निष्कर्ष निकालने के लिए, स्वचालित कोड पीढ़ी ठीक से उपयोग किए जाने पर कोड की गुणवत्ता बढ़ाने में मदद कर सकती है।


11

कोड पीढ़ी कोड गुणवत्ता को प्रभावित नहीं करती है , प्रति से, इतना कोड स्थिरता

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

कोड पीढ़ी का उपयोग कोड को तेजी से बनाने के लिए भी किया जा सकता है । हालांकि, तेज़ का मतलब बेहतर नहीं है ... इसका मतलब यह हो सकता है कि आप अपने खराब गुणवत्ता कोड को प्राप्त कर सकते हैं।


6

कोड पीढ़ी अच्छा है अगर:

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

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

आवश्यकताओं में विशिष्ट परिवर्तन के लिए, गुणवत्ता का एक सरल उपाय है कि आपको कितना मैन्युअल संपादन करना होगा। कम, बेहतर।


और उत्पन्न कोड पारदर्शी रूप से मूल में वापस आ जाता है, इसलिए आपको उत्पन्न कोड पर डीबग नहीं करना पड़ता है।

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

मैं असहमत हूं कि कोड जनरेटर लचीला होना चाहिए। इसे लक्षित करने की आवश्यकता है - एक काम अच्छी तरह से करें, बहुत सारी चीजें नहीं। इसे एक छोटा, अच्छी तरह से परिभाषित इनपुट लेना चाहिए और आपके लिए कोड का एक हिस्सा लिखना चाहिए। जब यह शुरू होता है हो सकता है कार्यक्रम, विफलता के लिए अपने नेतृत्व किया।
gbjbaanb

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

4

DRY के कारण बढ़ी हुई कोड गुणवत्ता (अपने आप को दोहराएं नहीं)।

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


जब तक आपको जनरेट किए गए कोड को संपादित नहीं करना होगा - जो कि DRY नहीं हैं .... मुझे हाल ही में ऐसा करना पड़ा - यह बिल्कुल भी सुखद नहीं है । अगर मुझे मैन्युअल रूप से एक ऑटोजेनरेटेड कोड आधार को फिर से संपादित करना पड़ा, तो मैं तीन बार शुल्क लूंगा !!!
फैब्रिकियो अरुजो

1
आपको उस कोड को कभी भी संपादित नहीं करना चाहिए; उस कोड को संपादित करें जो पीढ़ी ने स्वयं किया था और यदि आवश्यक हो तो अतिरिक्त नियमों के साथ इसे संवर्धित किया। उत्पन्न कोड का संपादन अंतिम उपाय होना चाहिए।
२०:३५ पर earlamameless

1
मुझे लगता है कि पसंद है .. मैं नहीं था।
फैब्रिकियो अरुजो

2

मुझे लगता है कि आप का मतलब है कि मालिकाना कोड जनरेटर विशिष्ट इन-हाउस उपयोग के लिए नियंत्रित किया जाता है, क्योंकि मशीन कोड की कुछ भी कमी एक कोड जनरेटर है। लेकिन यहाँ तुम जाओ:

यहाँ छवि विवरण दर्ज करें

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

नए शेड्स के साथ आने के लिए यह बहुत अधिक उत्पादक है क्योंकि आपको ग्राफ बदलने के साथ-साथ अंतिम परिणाम कैसा दिखता है, इसकी एक वास्तविक दृश्य प्रतिक्रिया मिलती है। मैं निश्चित रूप से जीएलएसएल / एचएलएसएल कोड के बजाय इस तरह से नोडल ग्राफ़ के साथ प्रस्तुत हजारों शेड्स को बनाए रखना पसंद करूंगा, और ब्लूप्रिंट का उपयोग करने की तुलना में मैं वास्तव में जीएलएसएल / एचएलएसएल लिखने से अधिक परिचित हूं। मुझे लगता है कि वास्तव में एक प्रमुख बग की तरह व्यवहार करना असंभव है, इसके अलावा शायद कुछ मामूली दृश्य गड़बड़ आप शायद तुरंत पकड़ लेंगे क्योंकि "दृश्य भाषा" अक्सर एक शुद्ध कार्यात्मक शैली के साथ समझदार बाधाओं को लगाती है जो आपको अनुमति नहीं देती है, कहते हैं, कम से कम AFAIK (मैं वास्तव में ब्लूप्रिंट के साथ एक विशेषज्ञ नहीं हूँ) एक shader दुर्घटना।

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

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

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


1

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

कोड जनरेटर ठीक हैं, लेकिन उनके साथ सावधान रहें!


1

मैं एक दुकान में काम करता था जो कोड पीढ़ी पर बहुत निर्भर करता था। मेरे दिमाग में इस परियोजना के लिए कोड बहुत समान था। और उस संबंध में, गुणवत्ता ठीक थी।

हालांकि, जब आपको कस्टम कोड लिखने की अनुमति नहीं होती है क्योंकि सब कुछ जनरेटर से गुजरना पड़ता है तो मुझे लगता है कि आप प्रोग्रामर होने के किनारे से कुछ खो देते हैं।

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

बस मेरे 2 सेंट।


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

@ मर्कज: कभी-कभी असेंबली एकरूपता के लिए संकलित भाषा से बेहतर हो सकती है। उदाहरण के लिए, कुछ एम्बेडेड सिस्टम में यह बराबर के कोड को सक्षम करने के लिए उपयोगी है x=someValue ^ 0xFF ^ 0xFF ^ 0xFF ^ 0xFF;और इसे चार XOR- शाब्दिक निर्देशों के साथ कोडित किया जाना चाहिए। यदि कोड संग्रहण माध्यम केवल रिक्त (0xFF) बाइट्स लिख सकता है, तो उपरोक्त निर्माण मूल्य में चार मनमाने परिवर्तन की अनुमति देगा। यहां तक ​​कि अगर कोई अभिव्यक्ति को फिर से लिखता है x=someValue; x = x ^ 0xFF ^ 0xFF ^ 0xFF ^ 0xFF;और संकलक ने सभी एक्सर्स का रनटाइम पर मूल्यांकन किया, तो यह अभी भी "पूरक सभी बिट्स" का उपयोग कर सकता है ...
सुपरकैट

... निर्देश के बजाय एक xor- तत्काल।
सुपरकैट

1

मार्टिन के जवाब के अलावा, मैं जोड़ूंगा कि जब आप रिकॉर्ड-दर-रिकॉर्ड आधार पर काम करते हैं तो एसक्यूएल कोड जेनरेशन बहुत अच्छा होता है (टैब 1 से चयन करें * जहां tab1.pkcolumn =: पैरामीटर, अपडेट tab1 सेट [कॉलम की कोई भी संख्या]: tab1.pkcolumn =: पैरामीटर, आदि)। और आपका ORM उस परिदृश्य में चमक जाएगा, क्योंकि SQL की आवश्यकता है कि वास्तव में दोहराव है।

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

एक मेटाक्वेरी भाषा जो किसी अन्य भाषा (SQL) का अनुवाद करती है जो डेटा एकत्र करने को प्रभावी ढंग से निष्पादित करने के लिए एक क्वेरी योजना में अनुवाद करती है। और उत्पन्न परिणाम ऑब्जेक्ट होना चाहिए, इसलिए ORM को प्रभावित वस्तुओं को तुरंत रोकना चाहिए - इसलिए यह मेटाक्वेरी द्वारा नहीं लाई गई वस्तुओं की विशेषताओं को भरने के लिए प्रश्नों की एक और बारिश को ट्रिगर कर सकता है ...


0

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

यदि हम स्वीकार कर सकते हैं कि उत्पन्न कोड लगभग उसी तरह की संख्या है जैसा कि हाथ से लिखा गया है, और अगर हम कह सकते हैं कि यह बग मुक्त है, तो संभवतः जिन पंक्तियों में कीड़े हो सकते हैं उनकी संख्या कम हो गई है। Ergo, कोड की गुणवत्ता में वृद्धि हुई है।


परिशिष्ट: बेशक, अन्य कारक, जैसे निष्पादन समय, एक भूमिका निभा सकते हैं।

व्यक्तिगत रूप से, मैंने कुछ कोड जनरेटर लिखे हैं, लेकिन कभी भी प्रारंभिक दृष्टिकोण के रूप में नहीं।

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

उस सीमा तक, मेरा उत्पन्न कोड मौजूदा हाथ से लिखे गए कोड के समान लगभग है (सिवाय इसके कि यह बेहतर नेत्रहीन रूप से रखी गई और अधिक समान है, जो मुझे एड्स की देयता लगता है, अगर इसे कभी भी देखना है)।

Btw, मैं उद्घाटन / समापन टिप्पणियों को सम्मिलित करने की वकालत करता हूं जो इंगित करता है कि कोड उत्पन्न हुआ था, जिसमें उपकरण और उसके अनुरक्षक का विवरण शामिल था।

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