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

From Vigyanwiki
(Created page with "{{more footnotes|date=April 2021}} {{short description|Standards and guidelines for writing code}} {{Software development process}} कोडिंग सम्मेलन...")
 
No edit summary
 
(13 intermediate revisions by 4 users not shown)
Line 1: Line 1:
{{more footnotes|date=April 2021}}
{{short description|Standards and guidelines for writing code}}
{{short description|Standards and guidelines for writing code}}
{{Software development process}}
कोडिंग कन्वेंशन एक विशेष [[प्रोग्रामिंग भाषा]] के लिए एक दिशा-निर्देशिका होते हैं जो उस भाषा में लिखे गए एक प्रोग्राम के प्रत्येक पहलू के लिए [[प्रोग्रामिंग शैली]], अभ्यास और विधियों कीअनुशंसा करते हैं। इन परम्पराओ में सामान्यतः फ़ाइल संगठन, इंडेंटेशन, टिप्पणियां, घोषणाएं, कथन, [[व्हाइटस्पेस (कंप्यूटर विज्ञान)|व्हाइटस्पेस]], [[व्हाइटस्पेस (कंप्यूटर विज्ञान)|(कंप्यूटर विज्ञान)]] नामकरण परंपराएं, प्रोग्रामिंग प्रथाएं, प्रोग्रामिंग सिद्धांत, अंगूठे के प्रोग्रामिंग नियम, वास्तु सर्वोत्तम अभ्यास आदि सम्मिलित हैं। ये [[सॉफ्टवेयर गुणवत्ता मॉडल|सॉफ्टवेयर गुणवत्ता]] प्रारूप के लिए दिशानिर्देश हैं।
कोडिंग सम्मेलन एक विशिष्ट [[प्रोग्रामिंग भाषा]] के लिए दिशानिर्देशों का एक सेट है जो उस भाषा में लिखे गए प्रोग्राम के प्रत्येक पहलू के लिए [[प्रोग्रामिंग शैली]], प्रथाओं और विधियों की अनुशंसा करता है। इन सम्मेलनों में आमतौर पर फ़ाइल संगठन, इंडेंट शैली, [[टिप्पणी (कंप्यूटर प्रोग्रामिंग)]], [[घोषणा (कंप्यूटर विज्ञान)]], कथन (प्रोग्रामिंग), [[व्हाइटस्पेस (कंप्यूटर विज्ञान)]], पहचानकर्ता नामकरण सम्मेलन, सर्वोत्तम कोडिंग प्रथाएं शामिल हैं: श्रेणी: प्रोग्रामिंग सिद्धांत, श्रेणी: अंगूठे के प्रोग्रामिंग नियम, वास्तु सर्वोत्तम अभ्यास आदि। ये [[सॉफ्टवेयर गुणवत्ता मॉडल]] के लिए दिशानिर्देश हैं। [[प्रोग्रामर]] को अपने स्रोत कोड की [[पठनीयता]] में सुधार करने और सॉफ़्टवेयर रखरखाव को आसान बनाने में सहायता के लिए इन दिशानिर्देशों का पालन करने की अत्यधिक अनुशंसा की जाती है। कोडिंग कन्वेंशन केवल एक सॉफ्टवेयर प्रोजेक्ट के मानव अनुरक्षकों और सहकर्मी समीक्षकों पर लागू होते हैं। कन्वेंशन को नियमों के एक प्रलेखित सेट में औपचारिक रूप दिया जा सकता है, जिसका पालन एक पूरी टीम या कंपनी करती है,<ref>{{Cite web|url=https://editorconfig.org/|title=EditorConfig डेवलपर्स को विभिन्न संपादकों और आईडीई के बीच लगातार कोडिंग शैलियों को परिभाषित करने और बनाए रखने में सहायता करता है।|last=|first=|date=|website=EditorConfig|access-date=}}</ref> या किसी व्यक्ति की आदतन कोडिंग प्रथाओं के रूप में अनौपचारिक हो सकता है। कोडिंग सम्मेलनों को [[ संकलक ]]्स द्वारा लागू नहीं किया जाता है।


== सॉफ्टवेयर रखरखाव ==
सॉफ़्टवेयर [[प्रोग्रामर]] को इन दिशा-निर्देशों का पालन करने की सबसे ज्यादा अनुशंसा की जाती है जिससे उनके स्रोत कोड की [[पठनीयता]] में सुधार हो और सॉफ़्टवेयर की रखरखाव आसान हो। कोडिंग परंपरा मात्र एक सॉफ्टवेयर प्रोजेक्ट के मानव अनुरक्षकों और सहकर्मी समीक्षकों पर लागू होते हैं। परम्पराओ को नियमों के एक प्रलेखित समुच्चय में औपचारिक रूप दिया जा सकता है, जिसका पालन एक पूरी टीम या कंपनी करती है,या किसी व्यक्ति की अभ्यस्त कोडिंग प्रथाओं के रूप में अनौपचारिक हो सकती है। कोडिंग कन्वेंशन संकलक द्वारा प्रवर्तित नहीं किए जाते हैं।
कोडिंग परंपराओं का पालन करने के लिए सॉफ्टवेयर रखरखाव की लागत को कम करना अक्सर उद्धृत कारण है। जावा प्रोग्रामिंग भाषा के लिए कोड सम्मेलनों के परिचय में, सन माइक्रोसिस्टम्स निम्नलिखित तर्क प्रदान करता है:<ref>
 
{{cite web
== सॉफ्टवेयर अनुरक्षण ==
  | title = Code Conventions for the Java Programming Language : Why Have Code Conventions
कोडिंग कन्वेंशन का पालन करने का सबसे अधिक उद्धरण दिया जाने वाला कारण सॉफ़्टवेयर अनुरक्षण के खर्च को कम करना है। जावा प्रोग्रामिंग भाषा के लिए कोडिंग कन्वेंशन के परिचय में, सन माइक्रोसिस्टम्स ने निम्नलिखित तर्क प्रदान किए हैं। कई कारणों से कोडिंग कन्वेंशन प्रोग्रामरों के लिए महत्वपूर्ण होते हैं::
  | publisher = Sun Microsystems, Inc.
*किसी सॉफ़्टवेयर के जीवनकाल में 40% से 80% खर्च संरक्षण पर जाते हैं:<ref>Robert L. Glass: Facts and Fallacies of Software Engineering; Addison Wesley, 2003.</ref>
  | date = 1999-04-20
* मूल लेखक द्वारा प्रायः ही कोई सॉफ्टवेयर अपने पूरे जीवन के लिए बनाए रखा जाता है।
  | url = http://www.oracle.com/technetwork/java/index-135089.html
* कोड नियम सॉफ़्टवेयर की पठनीयता में सुधार करते हैं, जिससे इंजीनियर नए कोड को अधिक तेज़ी से और अच्छी तरह से समझ पाते हैं।
}}
*यदि आप अपने स्रोत कोड को उत्पाद के रूप में शिप करते हैं, तो आपको यह सुनिश्चित करने की आवश्यकता है कि यह आपके द्वारा बनाए गए किसी भी अन्य उत्पाद की तरह अच्छी तरह से पैक और साफ है।
</ref>
<ब्लॉककोट>
कई कारणों से प्रोग्रामर्स के लिए कोड कन्वेंशन महत्वपूर्ण हैं:
*40%-80% सॉफ्टवेयर के एक टुकड़े की जीवन भर की लागत रखरखाव के लिए जाती है।<ref>Robert L. Glass: Facts and Fallacies of Software Engineering; Addison Wesley, 2003.</ref>
* मूल लेखक द्वारा शायद ही कोई सॉफ्टवेयर अपने पूरे जीवन के लिए बनाए रखा जाता है।
* कोड कन्वेंशन सॉफ़्टवेयर की पठनीयता में सुधार करते हैं, जिससे इंजीनियर नए कोड को अधिक तेज़ी से और अच्छी तरह से समझ पाते हैं।
*यदि आप अपने स्रोत कोड को एक उत्पाद के रूप में शिप करते हैं, तो आपको यह सुनिश्चित करने की आवश्यकता है कि यह आपके द्वारा बनाए गए किसी भी अन्य उत्पाद की तरह अच्छी तरह से पैक और साफ है।
</ब्लॉककोट>


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


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


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


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


जटिलता सुरक्षा के खिलाफ जाने वाला एक कारक है।<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>


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


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


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


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


== भाषा कारक ==
== भाषा कारक ==
सभी सॉफ्टवेयर व्यवसायियों को बड़ी संख्या में कभी-कभी जटिल निर्देशों को व्यवस्थित करने और प्रबंधित करने की समस्या से जूझना चाहिए। सबसे छोटी सॉफ्टवेयर परियोजनाओं को छोड़कर सभी के लिए, स्रोत कोड (निर्देश) को अलग-अलग [[कम्प्यूटर फाइल]] में और अक्सर कई [[फ़ाइल निर्देशिका]]ओं में विभाजित किया जाता है। प्रोग्रामर के लिए एक ही फाइल में बारीकी से संबंधित कार्यों (व्यवहार) को इकट्ठा करना और संबंधित फाइलों को निर्देशिकाओं में इकट्ठा करना स्वाभाविक था। जैसा कि सॉफ्टवेयर विकास विशुद्ध रूप से [[प्रक्रियात्मक प्रोग्रामिंग]] (जैसे कि [[फोरट्रान]] में पाया गया) से अधिक [[ ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग ]] की ओर स्थानांतरित हो गया है। एक फ़ाइल ('एक वर्ग प्रति फ़ाइल' सम्मेलन)।<ref>
सभी सॉफ़्टवेयर प्रयोगकर्ताओं को कभी-कभी जटिल निर्देशों के एक बड़े संख्या को संगठित और प्रबंधित करने की समस्या का सामना करना होता है। छोटे सॉफ़्टवेयर परियोजनाओं को छोड़कर, स्रोत कोड अलग-अलग फ़ाइलों में विभाजित किया जाता है और प्रायः कई निर्देशिकाओं में बांटा जाता है। प्रोग्रामरों के लिए सम्बंधित फलन को एक ही फ़ाइल में इकट्ठा करना और संबंधित फ़ाइलों को निर्देशिकाओं में संग्रहीत करना प्राकृतिक था। जैसा कि सॉफ्टवेयर विकास विशुद्ध रूप से प्रक्रियात्मक प्रोग्रामिंग से अधिक वस्तु-उन्मुख निर्माणों (जैसे कि C ++ में पाया जाता है) की ओर स्थानांतरित हो गया, यह एक एकल फ़ाइल में एकल वर्ग के लिए कोड लिखने का अभ्यास बन गया, जैसे 'एक वर्ग प्रति फ़ाइल' नियम
{{cite web
 
  | last = Hoff
एक भाषा में नियम किसी दूसरी भाषा में एक आवश्यकता हो सकता है। भाषा के नियम व्यक्तिगत स्रोत फ़ाइलों को भी प्रभावित करते हैं। प्रत्येक संकलक जो स्रोत कोड को प्रसंस्करण करने के लिए उपयोग किया जाता है, विशिष्ट होता है। स्रोत पर एक संकलक लागू होने वाले नियम अंतर्निहित मानक बनाता है।
  | first = Todd
  | title = C++ Coding Standard : Naming Class Files
  | date = 2007-01-09
  | url = http://www.possibility.com/Cpp/CppCodingStandard.html#cflayout }}
</ref><ref>[http://wiki.fifengine.de/index.php?title=Coding_standards FIFE coding standards]</ref>
जावा एक कदम आगे चला गया है - जावा कंपाइलर एक त्रुटि देता है यदि उसे प्रति फ़ाइल एक से अधिक सार्वजनिक वर्ग मिलते हैं।


एक भाषा में एक सम्मेलन दूसरे में एक आवश्यकता हो सकती है। भाषा सम्मेलन व्यक्तिगत स्रोत फ़ाइलों को भी प्रभावित करते हैं। स्रोत कोड को संसाधित करने के लिए प्रयुक्त प्रत्येक संकलक (या दुभाषिया) अद्वितीय है। स्रोत पर एक कंपाइलर लागू होने वाले नियम अंतर्निहित मानक बनाता है। उदाहरण के लिए, पर्ल की तुलना में पायथन कोड बहुत अधिक लगातार इंडेंट है, क्योंकि व्हॉट्सएप (इंडेंटेशन) वास्तव में दुभाषिया के लिए महत्वपूर्ण है। पायथन ब्रेस सिंटैक्स पर्ल का उपयोग कार्यों को सीमित करने के लिए नहीं करता है। इंडेंटेशन में परिवर्तन डिलीमीटर के रूप में कार्य करता है।<ref>
उदाहरण के लिए, पायथन कोड पर्ल के सापेक्ष में अधिक संवेदनशील ढंग से इंडेंट किया जाता है क्योंकि व्हाइटस्पेस वास्तव में दुभाषिय के लिए महत्वपूर्ण होता है। पायथन ब्रेस सिंटैक्स पर्ल का उपयोग कार्यों को सीमित करने के लिए नहीं करता है। इंडेंटेशन में परिवर्तन डिलीमीटर के रूप में कार्य करता है।<ref>
{{cite web
{{cite web
  |last        = van Rossum
  |last        = van Rossum
Line 99: Line 67:
   | date = 2000-05-01
   | date = 2000-05-01
   | url = http://www.linuxjournal.com/article/3882 }}
   | url = http://www.linuxjournal.com/article/3882 }}
</ref> [[टीसीएल]], जो कार्यों को सीमित करने के लिए पर्ल या सी/सी ++ के समान ब्रेस सिंटैक्स का उपयोग करता है, निम्नलिखित की अनुमति नहीं देता है, जो सी प्रोग्रामर के लिए काफी उचित लगता है:
</ref> [[टीसीएल]], जो कार्यों को सीमित करने के लिए पर्ल या सी/सी ++ के समान ब्रेस सिंटैक्स का उपयोग करता है, निम्नलिखित की अनुमति नहीं देता है, जो सी प्रोग्रामर के लिए अधिक उचित लगता है:
<syntaxhighlight lang="tcl">
<syntaxhighlight lang="tcl">
  set i = 0
  set i = 0
Line 107: Line 75:
     incr i
     incr i
  }
  }
</syntaxhighlight> कारण यह है कि टीसीएल में, घुंघराले ब्रेसिज़ का उपयोग केवल सी या जावा के कार्यों को सीमित करने के लिए नहीं किया जाता है। अधिक
</syntaxhighlight> कारण यह है कि टीसीएल में, कर्ली ब्रेसिज़ का उपयोग मात्र सी या जावा के कार्यों को सीमित करने के लिए नहीं किया जाता है। सामान्यतः कर्ली ब्रेसिज़ का उपयोग शब्दों को समूहबद्ध करने के लिए एक ही तर्क में किया जाता है ऊपर दिए गए उदाहरण में, व्हाइल के दूसरे तत्व, अर्थात् उसकी क्रिया, अनुपस्थित है क्योंकि टीसीएल भी न्यूलाइन के वर्ण का उपयोग करता है ।
आम तौर पर, कर्ली ब्रेसिज़ का उपयोग शब्दों को समूहबद्ध करने के लिए एक ही तर्क में किया जाता है।<ref>
== सरल नियम ==
{{cite web
बड़ी संख्या में कोडिंग कन्वेंशन हैं;  कई उदाहरणों और चर्चाओं के लिए कोडिंग स्टाइल देखें। सामान्य कोडिंग परिपाटियों में निम्नलिखित क्षेत्र सम्मिलित हो सकते हैं
  | last = Tcl Developer Xchange
  | title = Summary of Tcl language syntax
  | publisher = ActiveState
  | url = http://www.tcl.tk/man/tcl8.4/TclCmd/Tcl.htm }}
</ref><ref>
{{cite web
  | last = Staplin
  | first = George Peter
  | title = Why can I not start a new line before a brace group
  | publisher = 'the Tcler's Wiki'
  | date = 2006-07-16
  | url = http://wiki.tcl.tk/8344 }}
</ref>
टीसीएल में, 'जबकि' शब्द दो तर्क, एक शर्त और एक क्रिया लेता है। ऊपर दिए गए उदाहरण में, 'जबकि' अपना दूसरा तर्क, इसकी क्रिया याद कर रहा है (क्योंकि टीसीएल कमांड के अंत को सीमित करने के लिए न्यूलाइन वर्ण का भी उपयोग करता है)


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


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


== यह भी देखें ==<!-- Please A-Z -->
== यह भी देखें ==<!-- Please A-Z -->
*प्रोग्रामिंग भाषाओं की तुलना (सिंटैक्स)
*प्रोग्रामिंग भाषाओं की तुलना (सिंटैक्स)
* [[हंगेरियन नोटेशन]]
* हंगेरियन नोटेशन
* इंडेंट स्टाइल
* इंडेंट स्टाइल
* स्थिर कोड विश्लेषण के लिए उपकरणों की सूची
* स्थिर कोड विश्लेषण के लिए उपकरणों की सूची
*[[सॉफ्टवेयर विकास दर्शन की सूची]]
*सॉफ्टवेयर विकास दर्शन की सूची
*[[मोटर उद्योग सॉफ्टवेयर विश्वसनीयता संघ]]
*मोटर उद्योग सॉफ्टवेयर विश्वसनीयता संघ
* प्रोग्रामिंग शैली
* प्रोग्रामिंग शैली
* [[सॉफ्टवेयर मेट्रिक्स]]
* सॉफ्टवेयर मेट्रिक्स
* [[सॉफ्टवेयर की गुणवत्ता]]
* सॉफ्टवेयर की गुणवत्ता
*10 की शक्ति: सुरक्षा-महत्वपूर्ण कोड विकसित करने के नियम
*10 की शक्ति: सुरक्षा-महत्वपूर्ण कोड विकसित करने के नियम


Line 153: Line 105:




== कोडिंग मानकों की सूची ==
== कोडिंग मानकों की सूची ==<!-- Please A-Z -->
{{wikibooks|Ada Style Guide}}<!-- Please A-Z -->{{wikibooks|Computer Programming/Coding Style}}
 
=== भाषाओं के लिए कोडिंग परंपराएं ===
=== भाषाओं के लिए कोडिंग परंपराएं ===
*एक्शनस्क्रिप्ट: [https://web.archive.org/web/20120306040014/http://opensource.adobe.com/wiki/display/flexsdk/Coding+Conventions फ्लेक्स एसडीके कोडिंग कन्वेंशन और सर्वोत्तम अभ्यास]
*एक्शनस्क्रिप्ट: [https://web.archive.org/web/20120306040014/http://opensource.adobe.com/wiki/display/flexsdk/Coding+Conventions फ्लेक्स एसडीके कोडिंग कन्वेंशन और सर्वोत्तम अभ्यास]
Line 226: Line 176:
*[http://rfc.zeromq.org/spec:21 ZeroMQ C लैंग्वेज स्टाइल फॉर स्केलेबिलिटी (क्लास)]
*[http://rfc.zeromq.org/spec:21 ZeroMQ C लैंग्वेज स्टाइल फॉर स्केलेबिलिटी (क्लास)]


श्रेणी:स्रोत कोड
[[Category:Articles with Curlie links]]
 
 
[[Category: Machine Translated Page]]
[[Category:Created On 13/05/2023]]
[[Category:Created On 13/05/2023]]
[[Category:Lua-based templates]]
[[Category:Machine Translated Page]]
[[Category:Pages with script errors]]
[[Category:Templates Vigyan Ready]]
[[Category:Templates that add a tracking category]]
[[Category:Templates that generate short descriptions]]
[[Category:Templates using TemplateData]]
[[Category:Webarchive template wayback links]]

Latest revision as of 16:04, 25 May 2023

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

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

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

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

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

गुणवत्ता

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

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

कोडिंग मानक

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

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

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

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

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

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

पुनर्रचना

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

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

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

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

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

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

भाषा कारक

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

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

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

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

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

सरल नियम

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

  • टिप्पणी (कंप्यूटर प्रोग्रामिंग) नियम
  • इंडेंट स्टाइल नियम
  • वर्ण प्रति पंक्ति नियम
  • नामकरण परिपाटी (प्रोग्रामिंग) परिपाटी
  • सर्वश्रेष्ठ कोडिंग प्रथाएं
  • प्रोग्रामिंग सिद्धांत
  • प्रोग्रामिंग शैली नियम

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

यह भी देखें

  • प्रोग्रामिंग भाषाओं की तुलना (सिंटैक्स)
  • हंगेरियन नोटेशन
  • इंडेंट स्टाइल
  • स्थिर कोड विश्लेषण के लिए उपकरणों की सूची
  • सॉफ्टवेयर विकास दर्शन की सूची
  • मोटर उद्योग सॉफ्टवेयर विश्वसनीयता संघ
  • प्रोग्रामिंग शैली
  • सॉफ्टवेयर मेट्रिक्स
  • सॉफ्टवेयर की गुणवत्ता
  • 10 की शक्ति: सुरक्षा-महत्वपूर्ण कोड विकसित करने के नियम

संदर्भ

  1. Robert L. Glass: Facts and Fallacies of Software Engineering; Addison Wesley, 2003.
  2. 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.
  3. Raymond, Eric (2000-05-01). "Why Python?". Linux Journal.


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

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

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

  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.