प्रोग्रामिंग के बारे में हर प्रोग्रामर को क्या पता होना चाहिए?


52

कृपया, तकनीकी मुद्दों पर बने रहें, व्यवहार, सांस्कृतिक, कैरियर या राजनीतिक मुद्दों से बचें।


7
इसे भी देखें stackoverflow.com/questions/132798/…
pramodc84

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

जवाबों:


92
  1. बग आपके कोड में है, संकलक या रनटाइम लाइब्रेरी में नहीं।

  2. यदि आपको एक बग दिखाई देता है जो संभवतः नहीं हो सकता है, तो जांचें कि आपने अपना प्रोग्राम सही ढंग से बनाया और तैनात किया है। (खासकर यदि आप एक जटिल आईडीई का उपयोग कर रहे हैं या फ्रेमवर्क का निर्माण कर रहे हैं जो आपसे गंदे विवरण को छिपाने की कोशिश करता है ... या यदि आपके निर्माण में बहुत सारे मैनुअल चरण शामिल हैं।)

  3. समवर्ती / बहु-थ्रेडेड प्रोग्रामों को लिखना मुश्किल है और ठीक से परीक्षण करने के लिए कठिन है। यह उतना ही सबसे अच्छा है जितना आप पुस्तकालयों और रूपरेखाओं को समाप्‍त कर सकते हैं।

  4. प्रलेखन लिखना एक प्रोग्रामर के रूप में आपकी नौकरी का हिस्सा है। इसे करने के लिए "किसी और के लिए" मत छोड़ो।

संपादित करें

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

उन दिनों में जब मैंने C / C ++ डेवलपमेंट किया था, मुझे ऐसे मामले याद हैं, जहाँ आशावादी "बग्स" मेरी वजह से बने हैं / कुछ अन्य प्रोग्रामर ने ऐसी चीजें की हैं, जिनके बारे में भाषा का कहना है कि अपरिभाषित परिणाम हैं। यह जावा जैसी कथित सुरक्षित भाषाओं के लिए भी लागू होता है; उदाहरण के लिए, जावा मेमोरी मॉडल (JLS चैप्टर 17) पर एक लंबी कड़ी नज़र डालें।


17
मैं कहना चाहता हूं "बग शायद आपके कोड में है", क्योंकि मैं कुछ समय के लिए रन लाइब्रेरी में बग्स में आया हूं। मैं अभी तक एक संकलक बग में चलाने के लिए है। वैसे भी +1।
चिन्मय कांची

29
यदि आपको कंपाइलर में कभी भी एक बोना फाइड बग नहीं मिला है, तो आप अपने कोडिंग के साथ लगभग साहसी नहीं हैं। ;)
मेसन व्हीलर

8
@Chinmay, @ spudd86, @Mason - हाँ ... और मैंने अपनी 30+ वर्षों की प्रोग्रामिंग में कंपाइलर और लाइब्रेरी बग के अपने हिस्से को भी पाया है। लेकिन मेरे अनुभव में, 99 +% बग्स कम से कम (कम से कम भाग में) मेरे कोड की गलती हैं। मेरा उत्तर जानबूझकर इस बिंदु पर पहुंचने के लिए खत्म हो गया है कि आपको हमेशा अपने कोड पर संदेह करना चाहिए ।
स्टीफन सी

5
मुझे यह तर्कहीन भय नहीं है कि लोगों के पास बहु-थ्रेडेड प्रोग्रामिंग है। मुझे उन लोगों पर संदेह है, जो इस दृश्य को समाप्त कर देते हैं, बहुत अधिक बहु-थ्रेड कोड प्रोग्राम नहीं करते हैं। यह सिर्फ इतना मुश्किल नहीं है। हालांकि बाकी सब के लिए +1।
स्टीवन एवर्स

4
यदि आप संकलक पर काम कर रहे हैं, तो बग संभवतः आपके कोड और संकलक दोनों में है;)
लेगोयूलस

84
  • दूसरे लोगों का कोड कैसे पढ़ें।
  • यदि यह संस्करण नियंत्रण प्रणाली में चेक नहीं किया गया है तो कोड मौजूद नहीं है।

8
+10000 अगर मैं संस्करण नियंत्रण टिप्पणी के लिए कर सकता हूं। इतिहास और परिवर्तन लॉगिंग बिल्कुल अपरिहार्य हैं और यही कारण है कि आपको शुरुआत से ही संस्करण नियंत्रण में सब कुछ डाल देना चाहिए।
लेगोलास

2
... और रिपॉजिटरी को कम से कम एक अन्य स्थान पर सिंक्रनाइज़ किया गया है। डीवीसीएस के साथ महत्वपूर्ण है, लेकिन केंद्रीकृत वीसीएस के साथ भी।

उस मामले के लिए, कोड तब तक मौजूद नहीं है जब तक कि कोई कार्य आइटम मौजूद नहीं है जो डेवलपर को इसे लिखने के लिए अधिकृत करता है।
जेसी सी। स्लाइसर

2
मैं अन्य लोगों के कोड को पढ़ना सीखने के लिए एक प्लस करूंगा। यह अधिक कठिन है कि हम में से अधिकांश को एहसास है, लेकिन सफल प्रोग्रामिंग का एक अनिवार्य हिस्सा है।
बोगीमिन

अन्य लोगों के कोड को पढ़ना सीखने के लिए एक प्लस।
5ab पर इसकी जुबानी

76

फ्लोटिंग पॉइंट कंप्यूटेशन सटीक नहीं हैं ।



अगर किसी को नहीं पता कि मैं किस बारे में बात कर रहा हूं, तो @ एडम का लिंक पढ़ें। यह फ्लोटिंग पॉइंट कम्प्यूटेशन के नुकसान का एक उत्कृष्ट सारांश है।
चिन्मय कांची

1
और अगर वे नहीं जानते कि वे उन लोगों के समूह में से हो सकते हैं जो प्रतिदिन स्टैकओवरफ़्लो पर पूछते हैं।
ब्रायन आर। बॉडी

1
@ ब्रायन: तो सच है। काश, फ्लोटिंग पॉइंट अंकगणित द्वारा बताए गए प्रश्नों को पहचानने का एक तरीका होता। आप एक स्टैक ऐप बना सकते हैं जो हर दिन एक अलग फ्लोटिंग पॉइंट प्रश्न प्रदर्शित करता है!
एडम पेन्न्टर

63

सीखना बंद मत करो।


1
संबंधित: विश्वास करना बंद मत करो।
फिशटोस्टर

3
संबंधित: कल के बारे में सोचना बंद मत करो।
21

7
संबंधित: संगीत बंद न करें
adamk

1
संबंधित: Movin बंद मत करो '! यह तुम्हारा जीवन है, इसे चालू रखो ', इसे ठीक करो, तुम इसे सही करवाओगे!
ओसोडो

44

वह # 1 चीज़ जो आप अपने कोड की गुणवत्ता और रखरखाव को बढ़ाने के लिए कर सकते हैं वह है REDUCE DUPLICATION।


4
हाँ, हाँ! मैं कैसे भूल सकता हूँ? ;-)
मनेरियो सेप

यह इतना महत्वपूर्ण है कि मैंने इसके साथ फिर से उत्तर दिया

मैं बल्कि कहूंगा: REDDCE CONDITIONALS। प्रत्येक समय / यदि / के लिए एक संभावित बग है।
ज़र्बा

1
तुम्हें पता है, DRY के बारे में मजेदार बात यह है कि यह हर जगह दोहराया जाता है। :) +1
बिली ओनली

39

समस्या निवारण और डिबगिंग कौशल

वे शायद ही किसी विषय पर मेरे द्वारा लिए गए प्रोग्रामिंग पाठ्यक्रमों में से किसी पर भी समय बिताते हैं, और मेरे अनुभव में यह सबसे बड़ा निर्धारक है कि प्रोग्रामर कितना उत्पादक है। यह पसंद है या नहीं, आप नए विकास चरण की तुलना में अपने ऐप के रखरखाव चरण में बहुत अधिक समय बिताते हैं।

मैंने कई प्रोग्रामर्स के साथ काम किया है जो समस्या को खोजने के लिए बिना किसी रणनीति के बेतरतीब ढंग से चीजों को बदलकर डिबग करते हैं। मैंने दर्जनों बार यह बातचीत की है।

अन्य प्रोग्रामर: मुझे लगता है कि हमें यह देखने की कोशिश करनी चाहिए कि क्या वह इसे ठीक करता है।
Me: ठीक है, यह मानते हुए कि यह ठीक करता है। यह आपको क्या बताता है कि समस्या का स्रोत कहां है?
अन्य प्रोग्रामर: मुझे नहीं पता, लेकिन हमें कुछ प्रयास करना होगा


2
मेरे द्वारा यह पोस्ट की ही जाने वाली थी। एक प्रोग्रामर का बहुत सारा काम बग को ठीक करना है, और बहुत सारे लोग ऐसा करने में असमर्थ हैं (विशेषकर दूसरों के कोड में)।
Dov

+1 मैं जावास्क्रिप्ट / php से C # पर गया और कोड के माध्यम से कदम रखने से प्यार हो गया। मैं चाहता हूं कि गतिशील रूप से टाइप की गई भाषाएं इससे बेहतर काम कर सकती हैं।
इवान प्लाइस

एक और अजीब व्यवहार है प्रोग्रामर जोर देकर कहता है कि उसके कार्यक्रम का हर हिस्सा सही है जबकि यदि दोषपूर्ण है। "-आपको सॉर्ट करने के लिए सरणी को प्रिंट करने की ज़रूरत नहीं है कि क्या यह सॉर्ट किया गया है क्योंकि ऊपर की लाइन array.sort () है।" "-बताओ ... तुम्हें पता है, यह काम नहीं कर रहा है। कहीं न कहीं कुछ गड़बड़ होना चाहिए। तुम इस बिंदु पर अपने कोड का बचाव नहीं कर सकते!"
18

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

37
  1. चतुर मत बनो; स्पष्ट रहिये।
  2. पुन: उपयोग करने से पहले उपयोग करें।
  3. नाम मायने रखता है।
  4. एक फ़ंक्शन 1 काम करता है और इसे अच्छी तरह से करता है।
  5. छोटा बड़ा से अच्छा है।

2
क्या आप "पुन: उपयोग से पहले उपयोग करें" को स्पष्ट कर सकते हैं। मैंने पहले ऐसा नहीं सुना है।
Tjaart

34

मूल बातें। वर्तमान में प्रोग्रामर प्रौद्योगिकियां सीखते हैं, अवधारणाएं नहीं। यह गलत है।


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

4
+1, इतना सच। हां, यह कुछ हाथी दांत के टॉवर प्रकार हैं जो कहना चाहते हैं, लेकिन यह खाइयों में हम में से बाकी लोगों के लिए इसे कम सच नहीं बनाता है।
मेक

2
वर्तनी की तरह मूल बातें? उदाहरण के लिए Its wrongहोना चाहिए it's wrong
कोनराक

2
नहीं, जैसे मूल बातें टाइपो की परवाह नहीं करती हैं लेकिन प्रोग्रामिंग मुद्दों की परवाह करती हैं।
क्लोड

5
कुछ करने के लिए चरणों को सीखना आसान है और अक्सर यह पता लगाना मुश्किल है कि आपको इसका उपयोग कब करना चाहिए और अधिक महत्वपूर्ण बात यह है कि जब आप इसका उपयोग कर सकते हैं लेकिन ऐसा नहीं करना चाहिए। पाठ्यपुस्तक विशेष रूप से यह दिखाने में खराब हैं कि कैसे (और क्यों नहीं) कैसे।
एचएलजीईएम

27

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

और उसे पता होना चाहिए कि उन मान्यताओं के टूटने पर उसे तैयार करना चाहिए।


6
विशेष रूप से उन लोगों के साथ assert()- हर जगह। assert()आपकी मान्यताओं को दस्तावेज़ित करने में आपकी सहायता करेगा और गलत होने पर आपको बचाएगा।
डस्टिन

@ डस्टिन +1 ऐसा कोई तरीका नहीं है जिससे आप अपनी सभी मान्यताओं को याद रख सकें - उन्हें प्रोग्रामेटिक रूप से डॉक्यूमेंट करें और जब वे गलत धारणाएँ बन जाएँ, तो आपको ठीक-ठीक बताया जाएगा।
स्किलड्रिक

1
... जब तक NDEBUG के साथ संकलित नहीं किया जाता है।


17

अवधारणाओं को जानें । आप सिंटैक्स Google कर सकते हैं।


सिद्धांत में अच्छा है, सिवाय विशिष्ट सिंटैक्स खोजने के लिए Google भयानक है : "ऑब्जेक्ट संदर्भ" या "इस" जैसे शब्दों के लिए खोज करने से एक गज़िलियन परिणाम मिलता है, और "$" जैसे मुहावरों की खोज होती है? कोई परिणाम न दें।
l0b0


14

इकाई का परीक्षण। कोड का उपयोग कैसे किया जाए, इस पर अपनी मान्यताओं को संहिताबद्ध करने का यह एक शानदार तरीका है।



13

आपके विचार से यह कठिन है।

हालांकि यह (ईश) कुछ ऐसा है जो सामान्य रूप से उपयोग किए जाने पर काम करता है, गलत इनपुट, सभी किनारे और कोने के मामलों, संभावित विफलता मोड आदि के साथ मुकाबला करने में समय लगता है और संभवतः नौकरी का सबसे कठिन हिस्सा होगा।

तो फिर आप आवेदन भी अच्छा लग रहे बनाने के लिए मिल गया है।


3
मुझे लगता है कि यह पुरानी कहावत का स्रोत है '90% काम में 90% समय लगता है। अंतिम 10% समय का अन्य 90% लेता है '
GSto

मुझे लगता है कि बहुत सारे लोग लगातार जटिलता का अनुमान लगाते हैं। "X कितना कठिन हो सकता है?" - प्रसिद्ध अंतिम शब्द: /
रोमन स्टार्कोव

@GSto मैं समय का 180% काम नहीं करना चाहता, 100% मेरे द्वारा ठीक है!
adamk

13

डोमेन की जानकारी। कल्पना कभी 100% नहीं होती है; उस वास्तविक डोमेन को जानना जिसके साथ आप विकसित कर रहे हैं, हमेशा उत्पाद की गुणवत्ता बढ़ाएगा।


13

बिग ओ अंकन और इसके निहितार्थ।


कुछ उपयोगी संदर्भ


मुझे लगता है कि बिग ओ संकेतन मुख्य चीजों में से एक है, ज्यादातर कंप्यूटर वैज्ञानिकों के पास एक समस्या है (स्वयं शामिल)
रिचर्ड

11

संकेत, जाहिर है। :)


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

14
@ कांची कांची नं। पॉइंटर्स को हर किसी को समझना चाहिए।
वैकल्पिक

5
यह वास्तव में इस बात पर निर्भर करता है कि आपको सूचक से क्या मतलब है। यदि आप सी-स्टाइल पॉइंटर्स का मतलब है कि आप हेरफेर कर सकते हैं (जो कि मैंने मान लिया है), तो मैं तर्क दूंगा कि एक जावा / सी # / पायथन प्रोग्रामर को उनके बारे में कुछ भी जानने की आवश्यकता नहीं है। यदि आप जावा के "संदर्भ" के रूप में सूचक का मतलब है, यानी, एक सूचक जिसके साथ fiddled नहीं किया जा सकता है, तो हाँ, उनमें से कुछ ज्ञान आवश्यक है, अगर केवल आपको फिसलने से रोकने के लिए।
चिन्मय कांची

@mathepic यदि आप यह जानना चाहते हैं कि हर साल कितने सीएस छात्र स्नातक होते हैं, तो आपको अपने मूल को हिलाकर रख दिया जाएगा, जो बिंदुओं के बारे में पहली बात नहीं समझते हैं। अगर मैं हर गर्मियों में प्लेसमेंट लेने के लिए अपने रास्ते से बाहर नहीं गया होता, तो मुझे सी या पॉइंटर्स के बारे में जावा में भी नहीं पढ़ाया जाता ...
माइक बी।

5
@ चिनमय: एक पायथन / जावा / सी # प्रोग्रामर जो पॉइंटर्स की अवधारणा को नहीं समझता है वह खो गया है। L = [[]] * 2; L[0].append(42) विभिन्न भाषाएं विभिन्न नामों का उपयोग करती हैं, लेकिन अप्रत्यक्ष रूप से हर जगह आवश्यक है।

11

कोड पूरा 2 - कवर करने के लिए कवर


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

11

कोड की तुलना में डेटा अधिक महत्वपूर्ण है।

यदि आपका डेटा स्मार्ट है, तो कोड को डंबल किया जा सकता है।

गूंगा कोड को समझना आसान है। तो स्मार्ट डेटा है।

लगभग हर अल्गोरिमिक दु: ख जो मैं कभी भी गलत स्थान पर होने या उसके सही अर्थ के दुरुपयोग के कारण हुआ हूं। यदि आपके डेटा का अर्थ उस प्रकार के सिस्टम में है


2
जब तक आप "टाइप सिस्टम" नहीं कहे जाते, तब तक आप मेरे पास थे।

10

नौकरी के लिए कौन सी भाषा और वातावरण सबसे उपयुक्त है। और यह हमेशा आपका पसंदीदा नहीं है।


10

विभाजन और जीत। यह आमतौर पर शेड्यूलिंग से डिबगिंग तक किसी भी प्रकार की व्यावहारिक समस्या को हल करने का सबसे अच्छा तरीका है।


8

सच्चा कौशल एक सरल डिजाइन को अच्छी तरह से निष्पादित करने की क्षमता में परिलक्षित होता है, न कि एक जटिल डिजाइन काम करने की क्षमता में।

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

अच्छा कोड लिखना जो आप, या कोई और, एक महीने या एक सप्ताह में वापस आ सकते हैं और समझ सकते हैं कि उस कोड का उपयोग, संशोधन, वृद्धि या विस्तार कैसे किया जा सकता है। यह आपको समय और मानसिक प्रयास बचाता है। यह उन बाधाओं को दूर करके उत्पादकता के पहिये को कम कर देता है, जिन्हें आप पहले भी ठोकर खा चुके होते हैं (शायद आपकी ट्रेन की सोच बाधित होती है, या शायद दूसरे काम से घंटों या दिनों के प्रयास को दूर करना, आदि) इससे कठिन समस्याओं पर ध्यान केंद्रित करना आसान हो जाता है। , और कभी-कभी यह कठिन समस्याओं को दूर कर देता है।

एक शब्द में: लालित्य। हर वर्ग, हर विधि, हर स्थिति, हर ब्लॉक, हर चर नाम: लालित्य के लिए प्रयास करते हैं।


8

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


6

हर प्रोग्रामर कैसे डिबगर उपयोग करने के लिए पता है, और यह कैसे उपयोग करने के लिए पता होना चाहिए अच्छी तरह से





4

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


2
या अच्छी तरह से समझाना सीखें और यह बताएं कि आप मेहमान नहीं बन रहे हैं ...;)
बिली कोवर

4

कोडिंग शैली मायने रखती है:

  • लगातार इंडेंटेशन मामले,
  • सफ़ेद स्थान का लगातार उपयोग (जैसे संचालक के आसपास) मामले,
  • {} के मामलों के अनुरूप प्लेसमेंट,
  • अच्छी तरह से चुने गए पहचानकर्ता मामले,
  • आदि।

... और अच्छी डिजाइन मायने रखती है।

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

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