कोडिंग कन्वेंशन: Difference between revisions

From Vigyanwiki
No edit summary
Line 22: Line 22:
==== जटिलता में कमी ====
==== जटिलता में कमी ====


जटिलता सुरक्षा के खिलाफ जाने वाला एक कारक है।<ref>
जटिलता सुरक्षा के विरुद्ध जाने वाला एक कारक है।
Tom Gillis.
 
[https://www.networkworld.com/article/3103474/security/complexity-is-the-enemy-of-security.html "Complexity is the enemy of security"].
जटिलता का प्रबंधन निम्नलिखित मूल सिद्धांतों को सम्मिलित करता है: परियोजना विकास के समय लिखे गए कोड की मात्रा को कम से कम करता है। यह अनावश्यक काम रोकता है जिससे अपरियोजित और नीचे चलने वाला अनावश्यक खर्च रोका जा सकता है। यह इसलिए होता है क्योंकि यदि कोड कम होता है तो यह अवलोकन नहीं करने के लिए ही कार्य कम होता है, बल्कि उसे बनाने और संरक्षण करने के लिए भी कम कार्य होता है।
</ref>
जटिलता के प्रबंधन में निम्नलिखित मूल सिद्धांत शामिल हैं: परियोजना के विकास के दौरान लिखे गए कोड की मात्रा को कम करें। यह अनावश्यक कार्य को रोकता है जो अनावश्यक लागत को रोकता है, अपफ्रंट और डाउनस्ट्रीम दोनों। यह केवल इसलिए है क्योंकि यदि कोड कम है, तो न केवल एप्लिकेशन बनाना, बल्कि इसे बनाए रखना भी कम काम है।


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


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


=== [[ पुनर्रचना ]] ===
=== [[ पुनर्रचना ]] ===
रिफैक्टरिंग एक सॉफ्टवेयर रखरखाव गतिविधि को संदर्भित करता है जहां स्रोत कोड को पठनीयता में सुधार करने या इसकी संरचना में सुधार करने के लिए संशोधित किया जाता है। प्रारंभिक रिलीज के बाद टीम के घोषित कोडिंग मानकों के अनुरूप इसे लाने के लिए सॉफ्टवेयर को अक्सर रिफैक्टर किया जाता है। कोई भी बदलाव जो सॉफ्टवेयर के व्यवहार में बदलाव नहीं करता है, उसे रिफैक्टरिंग माना जा सकता है। सामान्य रीफैक्टरिंग गतिविधियाँ चर नाम, नाम बदलने के तरीके, चलती विधियाँ या पूरी कक्षाएं और [[ निकालने की विधि ]] (या [[ समारोह (प्रोग्रामिंग) ]]) को छोटे में बदल रही हैं।
पुनर्रचना सॉफ़्टवेयर में एक रखरखाव गतिविधि को संदर्भित करता है जहां स्रोत कोड में सुधार किया जाता है ताकि पठनीयता में सुधार हो या इसकी संरचना में सुधार किया जा सके। प्रारंभिक प्रदर्शन के उपरांत टीम के घोषित कोडिंग मानकों के अनुरूप इसे लाने के लिए सॉफ्टवेयर को प्रायः पुनर्रचना किया जाता है। किसी भी परिवर्तन को पुनर्रचना के रूप में माना जा सकता है जो सॉफ़्टवेयर के व्यवहार को बदलता नहीं है। सरल रूप से किए जाने वाले पुनर्रचना गतिविधियों में चर के नाम बदलना, विधियों का नाम बदलना, विधियों या पूरी कक्षाओं को स्थानांतरित करना और बड़ी विधियों को छोटे अलग-अलग विधियों में विभाजित करना सम्मिलित होता है।
 
फुर्तीली सॉफ्टवेयर विकास योजना नियमित (या यहां तक ​​कि निरंतर) रिफैक्टरिंग के लिए इसे टीम [[सॉफ्टवेयर विकास प्रक्रिया]] का एक अभिन्न अंग बनाती है।<ref>
{{cite web
|last        = Jeffries
|first      = Ron
|title      = What is Extreme Programming? : Design Improvement
|publisher  = XP Magazine
|date        = 2001-11-08
|url        = http://www.xprogramming.com/xpmag/whatisxp.htm#design
|url-status    = dead
|archiveurl  = https://web.archive.org/web/20061215120657/http://www.xprogramming.com/xpmag/whatisxp.htm#design
|archivedate = 2006-12-15
}}
</ref>
 


एजाइल सॉफ़्टवेयर विकास मेथडोलॉजी में नियमित पुनर्रचना की योजना बनाई जाती है, जिससे यह टीम [[सॉफ्टवेयर विकास प्रक्रिया]] का एक अभिन्न अंग बन जाती है।
== कार्य स्वचालन ==
== कार्य स्वचालन ==
कोडिंग कन्वेंशन प्रोग्रामर को सरल स्क्रिप्ट या प्रोग्राम रखने की अनुमति देते हैं जिनका काम स्रोत कोड को एक निष्पादन योग्य में संकलित करने के अलावा किसी अन्य उद्देश्य के लिए संसाधित करना है। वर्तमान परियोजना प्रगति को ट्रैक [[सॉफ्टवेयर इंजीनियरिंग में अनुमान]] में भविष्य के अनुमान के लिए आधार रेखा स्थापित करने के लिए सॉफ़्टवेयर आकार ([[कोड की स्रोत पंक्तियाँ]]) की गणना करना आम बात है।
कोडिंग कन्वेंशन प्रोग्रामर को सरल स्क्रिप्ट या प्रोग्राम रखने की अनुमति देते हैं जिनका काम स्रोत कोड को एक निष्पादन योग्य में संकलित करने के अलावा किसी अन्य उद्देश्य के लिए संसाधित करना है। वर्तमान परियोजना प्रगति को ट्रैक [[सॉफ्टवेयर इंजीनियरिंग में अनुमान]] में भविष्य के अनुमान के लिए आधार रेखा स्थापित करने के लिए सॉफ़्टवेयर आकार ([[कोड की स्रोत पंक्तियाँ]]) की गणना करना आम बात है।
Line 117: Line 101:


== आम परंपराएं ==
== आम परंपराएं ==
बड़ी संख्या में कोडिंग परंपराएँ हैं; देखें बी: कई उदाहरणों और चर्चा के लिए कंप्यूटर प्रोग्रामिंग/कोडिंग शैली। सामान्य कोडिंग परिपाटियों में निम्नलिखित क्षेत्र शामिल हो सकते हैं:<!-- Please A-Z -->
बड़ी संख्या में कोडिंग परंपराएँ हैं; देखें बी: कई उदाहरणों और चर्चा के लिए कंप्यूटर प्रोग्रामिंग/कोडिंग शैली। सामान्य कोडिंग परिपाटियों में निम्नलिखित क्षेत्र सम्मिलित      हो सकते हैं:<!-- Please A-Z -->
* टिप्पणी (कंप्यूटर प्रोग्रामिंग) सम्मेलन
* टिप्पणी (कंप्यूटर प्रोग्रामिंग) सम्मेलन
* इंडेंट स्टाइल कन्वेंशन
* इंडेंट स्टाइल कन्वेंशन
Line 126: Line 110:
* प्रोग्रामिंग शैली सम्मेलन
* प्रोग्रामिंग शैली सम्मेलन


कोडिंग मानकों में [[सीईआरटी सी कोडिंग मानक]], [[मिश्रा सी]], [[उच्च अखंडता सी ++]] शामिल हैं, नीचे दी गई सूची देखें।
कोडिंग मानकों में [[सीईआरटी सी कोडिंग मानक]], [[मिश्रा सी]], [[उच्च अखंडता सी ++]] सम्मिलित      हैं, नीचे दी गई सूची देखें।


== यह भी देखें ==<!-- Please A-Z -->
== यह भी देखें ==<!-- Please A-Z -->

Revision as of 23:02, 18 May 2023

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

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

सॉफ्टवेयर अनुरक्षण

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

  • किसी सॉफ़्टवेयर के जीवनकाल में 40% से 80% खर्च संरक्षण पर जाते हैं:[1]
  • मूल लेखक द्वारा प्रायः ही कोई सॉफ्टवेयर अपने पूरे जीवन के लिए बनाए रखा जाता है।
  • कोड नियम सॉफ़्टवेयर की पठनीयता में सुधार करते हैं, जिससे इंजीनियर नए कोड को अधिक तेज़ी से और अच्छी तरह से समझ पाते हैं।
  • यदि आप अपने स्रोत कोड को उत्पाद के रूप में शिप करते हैं, तो आपको यह सुनिश्चित करने की आवश्यकता है कि यह आपके द्वारा बनाए गए किसी भी अन्य उत्पाद की तरह अच्छी तरह से पैक और साफ है।

गुणवत्ता

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

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

कोडिंग मानक

जब कोडिंग नियम विशेष रूप से उच्च-गुणवत्ता कोड उत्पन्न करने के लिए तैयार किए जाते हैं और फिर उन्हें सामरिक रूप से अपनाया जाता है, तो वे कोडिंग मानक बन जाते हैं। विशेष शैलियाँ, चाहे वे सामान्य रूप से अपनायी जाती हों या न हों, स्वचालित रूप से अच्छी गुणवत्ता कोड उत्पन्न नहीं करती हैं।

जटिलता में कमी

जटिलता सुरक्षा के विरुद्ध जाने वाला एक कारक है।

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

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

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

पुनर्रचना

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

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

कार्य स्वचालन

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

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

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

भाषा कारक

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

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

 set i = 0
 while {$i < 10} 
 {
    puts "$i squared = [expr $i*$i]"
    incr i
 }

कारण यह है कि टीसीएल में, घुंघराले ब्रेसिज़ का उपयोग केवल सी या जावा के कार्यों को सीमित करने के लिए नहीं किया जाता है। अधिक

आम तौर पर, कर्ली ब्रेसिज़ का उपयोग शब्दों को समूहबद्ध करने के लिए एक ही तर्क में किया जाता है।[6][7] टीसीएल में, 'जबकि' शब्द दो तर्क, एक शर्त और एक क्रिया लेता है। ऊपर दिए गए उदाहरण में, 'जबकि' अपना दूसरा तर्क, इसकी क्रिया याद कर रहा है (क्योंकि टीसीएल कमांड के अंत को सीमित करने के लिए न्यूलाइन वर्ण का भी उपयोग करता है)।

आम परंपराएं

बड़ी संख्या में कोडिंग परंपराएँ हैं; देखें बी: कई उदाहरणों और चर्चा के लिए कंप्यूटर प्रोग्रामिंग/कोडिंग शैली। सामान्य कोडिंग परिपाटियों में निम्नलिखित क्षेत्र सम्मिलित हो सकते हैं:

कोडिंग मानकों में सीईआरटी सी कोडिंग मानक, मिश्रा सी, उच्च अखंडता सी ++ सम्मिलित हैं, नीचे दी गई सूची देखें।

यह भी देखें

संदर्भ

  1. Robert L. Glass: Facts and Fallacies of Software Engineering; Addison Wesley, 2003.
  2. Hoff, Todd (2007-01-09). "C++ Coding Standard : Naming Class Files".
  3. FIFE coding standards
  4. van Rossum, Guido (2006-09-19). Fred L. Drake, Jr (ed.). "Python Tutorial : First Steps Towards Programming". Python Software Foundation. Archived from the original on 2008-09-28. Retrieved 2014-08-17.
  5. Raymond, Eric (2000-05-01). "Why Python?". Linux Journal.
  6. Tcl Developer Xchange. "Summary of Tcl language syntax". ActiveState.
  7. Staplin, George Peter (2006-07-16). "Why can I not start a new line before a brace group". 'the Tcler's Wiki'.


कोडिंग मानकों की सूची

भाषाओं के लिए कोडिंग परंपराएं

परियोजनाओं के लिए कोडिंग सम्मेलन

श्रेणी:स्रोत कोड

  1. "टीआईओबीई - सी कोडिंग मानक". tics.tiobe.com. Retrieved 2021-03-11.
  2. "सी ++ कोडिंग मानक". tics.tiobe.com. Retrieved 2021-03-11.
  3. "सी # कोडिंग मानक". tics.tiobe.com. Retrieved 2021-03-11.
  4. "TIOBE - जावा कोडिंग स्टैंडर्ड". tics.tiobe.com. Retrieved 2021-03-11.