कोडिंग कन्वेंशन: Difference between revisions
No edit summary |
|||
| (10 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
{{short description|Standards and guidelines for writing code}} | {{short description|Standards and guidelines for writing code}} | ||
कोडिंग कन्वेंशन एक विशेष [[प्रोग्रामिंग भाषा]] के लिए एक दिशा-निर्देशिका होते हैं जो उस भाषा में लिखे गए एक प्रोग्राम के प्रत्येक पहलू के लिए [[प्रोग्रामिंग शैली]], अभ्यास और विधियों कीअनुशंसा करते हैं। इन परम्पराओ में सामान्यतः फ़ाइल संगठन, इंडेंटेशन, टिप्पणियां, घोषणाएं, कथन, [[व्हाइटस्पेस (कंप्यूटर विज्ञान)|व्हाइटस्पेस]], [[व्हाइटस्पेस (कंप्यूटर विज्ञान)|(कंप्यूटर विज्ञान)]] नामकरण परंपराएं, प्रोग्रामिंग प्रथाएं, प्रोग्रामिंग सिद्धांत, अंगूठे के प्रोग्रामिंग नियम, वास्तु सर्वोत्तम अभ्यास आदि सम्मिलित हैं। ये [[सॉफ्टवेयर गुणवत्ता मॉडल|सॉफ्टवेयर गुणवत्ता]] प्रारूप के लिए दिशानिर्देश हैं। | |||
कोडिंग | |||
सॉफ़्टवेयर [[प्रोग्रामर]] को इन दिशा-निर्देशों का पालन करने की सबसे ज्यादा अनुशंसा की जाती है जिससे उनके स्रोत कोड की [[पठनीयता]] में सुधार हो और सॉफ़्टवेयर की रखरखाव आसान हो। कोडिंग परंपरा मात्र एक सॉफ्टवेयर प्रोजेक्ट के मानव अनुरक्षकों और सहकर्मी समीक्षकों पर लागू होते हैं। परम्पराओ को नियमों के एक प्रलेखित समुच्चय में औपचारिक रूप दिया जा सकता है, जिसका पालन एक पूरी टीम या कंपनी करती है,या किसी व्यक्ति की अभ्यस्त कोडिंग प्रथाओं के रूप में अनौपचारिक हो सकती है। कोडिंग | सॉफ़्टवेयर [[प्रोग्रामर]] को इन दिशा-निर्देशों का पालन करने की सबसे ज्यादा अनुशंसा की जाती है जिससे उनके स्रोत कोड की [[पठनीयता]] में सुधार हो और सॉफ़्टवेयर की रखरखाव आसान हो। कोडिंग परंपरा मात्र एक सॉफ्टवेयर प्रोजेक्ट के मानव अनुरक्षकों और सहकर्मी समीक्षकों पर लागू होते हैं। परम्पराओ को नियमों के एक प्रलेखित समुच्चय में औपचारिक रूप दिया जा सकता है, जिसका पालन एक पूरी टीम या कंपनी करती है,या किसी व्यक्ति की अभ्यस्त कोडिंग प्रथाओं के रूप में अनौपचारिक हो सकती है। कोडिंग कन्वेंशन संकलक द्वारा प्रवर्तित नहीं किए जाते हैं। | ||
== सॉफ्टवेयर अनुरक्षण == | == सॉफ्टवेयर अनुरक्षण == | ||
कोडिंग | कोडिंग कन्वेंशन का पालन करने का सबसे अधिक उद्धरण दिया जाने वाला कारण सॉफ़्टवेयर अनुरक्षण के खर्च को कम करना है। जावा प्रोग्रामिंग भाषा के लिए कोडिंग कन्वेंशन के परिचय में, सन माइक्रोसिस्टम्स ने निम्नलिखित तर्क प्रदान किए हैं। कई कारणों से कोडिंग कन्वेंशन प्रोग्रामरों के लिए महत्वपूर्ण होते हैं:: | ||
*किसी सॉफ़्टवेयर के जीवनकाल में 40% से 80% खर्च संरक्षण पर जाते हैं:<ref>Robert L. Glass: Facts and Fallacies of Software Engineering; Addison Wesley, 2003.</ref> | *किसी सॉफ़्टवेयर के जीवनकाल में 40% से 80% खर्च संरक्षण पर जाते हैं:<ref>Robert L. Glass: Facts and Fallacies of Software Engineering; Addison Wesley, 2003.</ref> | ||
* मूल लेखक द्वारा प्रायः ही कोई सॉफ्टवेयर अपने पूरे जीवन के लिए बनाए रखा जाता है। | * मूल लेखक द्वारा प्रायः ही कोई सॉफ्टवेयर अपने पूरे जीवन के लिए बनाए रखा जाता है। | ||
| Line 12: | Line 11: | ||
*यदि आप अपने स्रोत कोड को उत्पाद के रूप में शिप करते हैं, तो आपको यह सुनिश्चित करने की आवश्यकता है कि यह आपके द्वारा बनाए गए किसी भी अन्य उत्पाद की तरह अच्छी तरह से पैक और साफ है। | *यदि आप अपने स्रोत कोड को उत्पाद के रूप में शिप करते हैं, तो आपको यह सुनिश्चित करने की आवश्यकता है कि यह आपके द्वारा बनाए गए किसी भी अन्य उत्पाद की तरह अच्छी तरह से पैक और साफ है। | ||
=== गुणवत्ता === | ==== गुणवत्ता ==== | ||
सॉफ़्टवेयर पीयर समीक्षा में अक्सर स्रोत कोड पढ़ना सम्मिलित होता है। इस प्रकार की सहकर्मी समीक्षा मुख्य रूप से दोष का पता लगाने वाली गतिविधि है। परिभाषा के अनुसार, कोड के एक टुकड़े के मात्र मूल लेखक ने समीक्षा के लिए कोड प्रस्तुत करने से पहले स्रोत फ़ाइल को पढ़ा है। गत मानकों का उपयोग करके लिखे गए कोड को समझने और स्वीकार करने के लिए अन्य समीक्षकों के लिए आसान होता है, जिससे दोष पकड़ प्रक्रिया की प्रभावशीलता में सुधार होता है। | सॉफ़्टवेयर पीयर समीक्षा में अक्सर स्रोत कोड पढ़ना सम्मिलित होता है। इस प्रकार की सहकर्मी समीक्षा मुख्य रूप से दोष का पता लगाने वाली गतिविधि है। परिभाषा के अनुसार, कोड के एक टुकड़े के मात्र मूल लेखक ने समीक्षा के लिए कोड प्रस्तुत करने से पहले स्रोत फ़ाइल को पढ़ा है। गत मानकों का उपयोग करके लिखे गए कोड को समझने और स्वीकार करने के लिए अन्य समीक्षकों के लिए आसान होता है, जिससे दोष पकड़ प्रक्रिया की प्रभावशीलता में सुधार होता है। | ||
मूल लेखक के लिए भी, संगत ढंग से कोडिंग किया गया सॉफ़्टवेयर रखरखाव को सरल बनाता है। इस बात की कोई गारंटी नहीं है कि किसी व्यक्ति को सटीक तर्क याद होगा कि कोड का एक विशेष टुकड़ा मूल रूप से कोड लिखे जाने के लंबे समय बाद एक निश्चित विधि से क्यों लिखा गया था। कोडिंग | मूल लेखक के लिए भी, संगत ढंग से कोडिंग किया गया सॉफ़्टवेयर रखरखाव को सरल बनाता है। इस बात की कोई गारंटी नहीं है कि किसी व्यक्ति को सटीक तर्क याद होगा कि कोड का एक विशेष टुकड़ा मूल रूप से कोड लिखे जाने के लंबे समय बाद एक निश्चित विधि से क्यों लिखा गया था। कोडिंग कन्वेंशन मदद कर सकते हैं। व्हॉट्सएप (कंप्यूटर साइंस) के लगातार उपयोग से पठनीयता में सुधार होता है इसके साथ ही, यह समय कम करता है जो सॉफ़्टवेयर को समझने में लगता है। | ||
==== कोडिंग मानक ==== | ==== कोडिंग मानक ==== | ||
जब कोडिंग | जब कोडिंग कन्वेंशन विशेष रूप से उच्च-गुणवत्ता कोड उत्पन्न करने के लिए तैयार किए जाते हैं और फिर उन्हें सामरिक रूप से अपनाया जाता है, तो वे कोडिंग मानक बन जाते हैं। विशेष शैलियाँ, चाहे वे सामान्य रूप से अपनायी जाती हों या न हों, स्वचालित रूप से अच्छी गुणवत्ता कोड उत्पन्न नहीं करती हैं। | ||
==== जटिलता में कमी ==== | ==== जटिलता में कमी ==== | ||
| Line 24: | Line 23: | ||
जटिलता सुरक्षा के विरुद्ध जाने वाला एक कारक है। | जटिलता सुरक्षा के विरुद्ध जाने वाला एक कारक है। | ||
जटिलता का प्रबंधन निम्नलिखित मूल सिद्धांतों को सम्मिलित करता है: परियोजना विकास के समय लिखे गए कोड की मात्रा को कम से कम करता है। यह अनावश्यक | जटिलता का प्रबंधन निम्नलिखित मूल सिद्धांतों को सम्मिलित करता है: परियोजना विकास के समय लिखे गए कोड की मात्रा को कम से कम करता है। यह अनावश्यक कार्य रोकता है जिससे अपरियोजित और नीचे चलने वाला अनावश्यक खर्च रोका जा सकता है। यह इसलिए होता है क्योंकि यदि कोड कम होता है तो यह अवलोकन नहीं करने के लिए ही कार्य कम होता है, बल्कि उसे बनाने और संरक्षण करने के लिए भी कम कार्य होता है। | ||
जटिलता का प्रबंधन प्रोयोजना की डिजाइन चरण और विकास चरण (सरल कोड होने के द्वारा) दोनों स्तरों पर किया जाता है। यदि कोडिंग को सरल और मूलभूत रखा जाता है, तो जटिलता को कम किया जा सकता है। प्रायः इसका अर्थ होता है कोडिंग को "भौतिक" रखना - एक ऐसे नियमों से कोडिंग करना जो बहुत सीधा हो और अत्यधिक संवेदनशील न हो। इससे परिणामस्वरूप उत्पन्न होने वाला कोड सरल होता है जिसे पढ़ना और समझना आसान होता है। जटिलता से बचने के लिए साधारण कार्यों के लिए जटिल उपकरणों का उपयोग न करके भी संभव होता है। | जटिलता का प्रबंधन प्रोयोजना की डिजाइन चरण और विकास चरण (सरल कोड होने के द्वारा) दोनों स्तरों पर किया जाता है। यदि कोडिंग को सरल और मूलभूत रखा जाता है, तो जटिलता को कम किया जा सकता है। प्रायः इसका अर्थ होता है कोडिंग को "भौतिक" रखना - एक ऐसे नियमों से कोडिंग करना जो बहुत सीधा हो और अत्यधिक संवेदनशील न हो। इससे परिणामस्वरूप उत्पन्न होने वाला कोड सरल होता है जिसे पढ़ना और समझना आसान होता है। जटिलता से बचने के लिए साधारण कार्यों के लिए जटिल उपकरणों का उपयोग न करके भी संभव होता है। | ||
| Line 30: | Line 29: | ||
जितना अधिक जटिल कोड होगा, उत्पाद में बग होने की संभावना भी उत्पन्न होती है, बग्स को खोजना भी उत्पाद में और कठिन होता है, और छिपे हुए बग्स होने की संभावना भी बढ़ जाती है। | जितना अधिक जटिल कोड होगा, उत्पाद में बग होने की संभावना भी उत्पन्न होती है, बग्स को खोजना भी उत्पाद में और कठिन होता है, और छिपे हुए बग्स होने की संभावना भी बढ़ जाती है। | ||
=== | ==== पुनर्रचना ==== | ||
पुनर्रचना सॉफ़्टवेयर में एक रखरखाव गतिविधि को संदर्भित करता है जहां स्रोत कोड में सुधार किया जाता है ताकि पठनीयता में सुधार हो या इसकी संरचना में सुधार किया जा सके। प्रारंभिक प्रदर्शन के उपरांत टीम के घोषित कोडिंग मानकों के अनुरूप इसे लाने के लिए सॉफ्टवेयर को प्रायः पुनर्रचना किया जाता है। किसी भी परिवर्तन को पुनर्रचना के रूप में माना जा सकता है जो सॉफ़्टवेयर के व्यवहार को बदलता नहीं है। सरल रूप से किए जाने वाले पुनर्रचना गतिविधियों में चर के नाम बदलना, विधियों का नाम बदलना, विधियों या पूरी कक्षाओं को स्थानांतरित करना और बड़ी विधियों को छोटे अलग-अलग विधियों में विभाजित करना सम्मिलित होता है। | पुनर्रचना सॉफ़्टवेयर में एक रखरखाव गतिविधि को संदर्भित करता है जहां स्रोत कोड में सुधार किया जाता है ताकि पठनीयता में सुधार हो या इसकी संरचना में सुधार किया जा सके। प्रारंभिक प्रदर्शन के उपरांत टीम के घोषित कोडिंग मानकों के अनुरूप इसे लाने के लिए सॉफ्टवेयर को प्रायः पुनर्रचना किया जाता है। किसी भी परिवर्तन को पुनर्रचना के रूप में माना जा सकता है जो सॉफ़्टवेयर के व्यवहार को बदलता नहीं है। सरल रूप से किए जाने वाले पुनर्रचना गतिविधियों में चर के नाम बदलना, विधियों का नाम बदलना, विधियों या पूरी कक्षाओं को स्थानांतरित करना और बड़ी विधियों को छोटे अलग-अलग विधियों में विभाजित करना सम्मिलित होता है। | ||
एजाइल सॉफ़्टवेयर विकास मेथडोलॉजी में नियमित पुनर्रचना की योजना बनाई जाती है, जिससे यह टीम [[सॉफ्टवेयर विकास प्रक्रिया]] का एक अभिन्न अंग बन जाती है। | एजाइल सॉफ़्टवेयर विकास मेथडोलॉजी में नियमित पुनर्रचना की योजना बनाई जाती है, जिससे यह टीम [[सॉफ्टवेयर विकास प्रक्रिया]] का एक अभिन्न अंग बन जाती है। | ||
== कार्य स्वचालन == | == कार्य स्वचालन == | ||
कोडिंग कन्वेंशन प्रोग्रामर को सरल स्क्रिप्ट या प्रोग्राम रखने की अनुमति देते हैं जिनका | कोडिंग कन्वेंशन प्रोग्रामर को सरल स्क्रिप्ट या प्रोग्राम रखने की अनुमति देते हैं जिनका कार्य स्रोत कोड को एक निष्पादन योग्य में संकलित करने के अतिरिक्त किसी अन्य उद्देश्य के लिए संसाधित करना है। वर्तमान परियोजना की प्रगति को ट्रैक सॉफ्टवेयर अभियांत्रिकी में अनुमान करने या भविष्य की परियोजना की आंशिक अनुमान तय करने के लिए सॉफ़्टवेयर का आकार गिना जाना सामान्य अभ्यास है। | ||
सतत कोडिंग मानक संगणनाओं को अधिक सतत बना सकते हैं। स्रोत कोड टिप्पणियों में विशेष टैग्स का उपयोग सामान्यतः सामग्री प्रसंस्करण के लिए किया जाता है, जैसे जावाडोक और डाइऑक्सीजन जैसे दो प्रमुख उदाहरण हैं। उपकरण टैग के एक समुच्चय के उपयोग को निर्दिष्ट करते हैं, परंतु एक परियोजना के अंदर उनका उपयोग परिपाटी द्वारा निर्धारित किया जाता है। | |||
कोडिंग कन्वेंशन नए सॉफ़्टवेयर को लिखना आसान बनाता है जिसका | कोडिंग कन्वेंशन नए सॉफ़्टवेयर को लिखना आसान बनाता है जिसका कार्य उपस्थित सॉफ़्टवेयर को प्रोसेस करना है। 1950 के दशक से स्थिर कोड विश्लेषण का उपयोग लगातार बढ़ा है। इस विकास उपकरणों के वर्ग के कुछ विकास का कारण अभ्यासकर्ताओं की बढ़ी हुई परिपक्वता और कुशलता से होता है,परंतु इसके साथ ही भाषाओं की प्रकृति से भी होता है। | ||
== भाषा कारक == | == भाषा कारक == | ||
सभी | सभी सॉफ़्टवेयर प्रयोगकर्ताओं को कभी-कभी जटिल निर्देशों के एक बड़े संख्या को संगठित और प्रबंधित करने की समस्या का सामना करना होता है। छोटे सॉफ़्टवेयर परियोजनाओं को छोड़कर, स्रोत कोड अलग-अलग फ़ाइलों में विभाजित किया जाता है और प्रायः कई निर्देशिकाओं में बांटा जाता है। प्रोग्रामरों के लिए सम्बंधित फलन को एक ही फ़ाइल में इकट्ठा करना और संबंधित फ़ाइलों को निर्देशिकाओं में संग्रहीत करना प्राकृतिक था। जैसा कि सॉफ्टवेयर विकास विशुद्ध रूप से प्रक्रियात्मक प्रोग्रामिंग से अधिक वस्तु-उन्मुख निर्माणों (जैसे कि C ++ में पाया जाता है) की ओर स्थानांतरित हो गया, यह एक एकल फ़ाइल में एकल वर्ग के लिए कोड लिखने का अभ्यास बन गया, जैसे 'एक वर्ग प्रति फ़ाइल' नियम | ||
एक भाषा में नियम किसी दूसरी भाषा में एक आवश्यकता हो सकता है। भाषा के नियम व्यक्तिगत स्रोत फ़ाइलों को भी प्रभावित करते हैं। प्रत्येक संकलक जो स्रोत कोड को प्रसंस्करण करने के लिए उपयोग किया जाता है, विशिष्ट होता है। स्रोत पर एक संकलक लागू होने वाले नियम अंतर्निहित मानक बनाता है। | |||
उदाहरण के लिए, पायथन कोड पर्ल के सापेक्ष में अधिक संवेदनशील ढंग से इंडेंट किया जाता है क्योंकि व्हाइटस्पेस वास्तव में दुभाषिय के लिए महत्वपूर्ण होता है। पायथन ब्रेस सिंटैक्स पर्ल का उपयोग कार्यों को सीमित करने के लिए नहीं करता है। इंडेंटेशन में परिवर्तन डिलीमीटर के रूप में कार्य करता है।<ref> | |||
{{cite web | {{cite web | ||
|last = van Rossum | |last = van Rossum | ||
| Line 74: | 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 82: | Line 75: | ||
incr i | incr i | ||
} | } | ||
</syntaxhighlight> कारण यह है कि टीसीएल में, | </syntaxhighlight> कारण यह है कि टीसीएल में, कर्ली ब्रेसिज़ का उपयोग मात्र सी या जावा के कार्यों को सीमित करने के लिए नहीं किया जाता है। सामान्यतः कर्ली ब्रेसिज़ का उपयोग शब्दों को समूहबद्ध करने के लिए एक ही तर्क में किया जाता है ऊपर दिए गए उदाहरण में, व्हाइल के दूसरे तत्व, अर्थात् उसकी क्रिया, अनुपस्थित है क्योंकि टीसीएल भी न्यूलाइन के वर्ण का उपयोग करता है । | ||
== सरल नियम == | |||
बड़ी संख्या में कोडिंग कन्वेंशन हैं; कई उदाहरणों और चर्चाओं के लिए कोडिंग स्टाइल देखें। सामान्य कोडिंग परिपाटियों में निम्नलिखित क्षेत्र सम्मिलित हो सकते हैं | |||
* टिप्पणी (कंप्यूटर प्रोग्रामिंग) नियम | |||
* इंडेंट स्टाइल नियम | |||
* टिप्पणी (कंप्यूटर प्रोग्रामिंग) | * वर्ण प्रति पंक्ति नियम | ||
* इंडेंट स्टाइल | * नामकरण परिपाटी (प्रोग्रामिंग) परिपाटी | ||
* | |||
* | |||
* सर्वश्रेष्ठ कोडिंग प्रथाएं | * सर्वश्रेष्ठ कोडिंग प्रथाएं | ||
* | * प्रोग्रामिंग सिद्धांत | ||
* प्रोग्रामिंग शैली | * प्रोग्रामिंग शैली नियम | ||
कोडिंग मानकों में | कोडिंग मानकों में सीईआरटी सी कोडिंग मानक, मिश्रा सी, उच्च अखंडता सी ++ सम्मिलित हैं, नीचे दी गई सूची देखें। | ||
== यह भी देखें ==<!-- Please A-Z --> | == यह भी देखें ==<!-- Please A-Z --> | ||
*प्रोग्रामिंग भाषाओं की तुलना (सिंटैक्स) | *प्रोग्रामिंग भाषाओं की तुलना (सिंटैक्स) | ||
* | * हंगेरियन नोटेशन | ||
* इंडेंट स्टाइल | * इंडेंट स्टाइल | ||
* स्थिर कोड विश्लेषण के लिए उपकरणों की सूची | * स्थिर कोड विश्लेषण के लिए उपकरणों की सूची | ||
* | *सॉफ्टवेयर विकास दर्शन की सूची | ||
* | *मोटर उद्योग सॉफ्टवेयर विश्वसनीयता संघ | ||
* प्रोग्रामिंग शैली | * प्रोग्रामिंग शैली | ||
* | * सॉफ्टवेयर मेट्रिक्स | ||
* | * सॉफ्टवेयर की गुणवत्ता | ||
*10 की शक्ति: सुरक्षा-महत्वपूर्ण कोड विकसित करने के नियम | *10 की शक्ति: सुरक्षा-महत्वपूर्ण कोड विकसित करने के नियम | ||
| Line 128: | Line 105: | ||
== कोडिंग मानकों की सूची == | == कोडिंग मानकों की सूची ==<!-- Please A-Z --> | ||
=== भाषाओं के लिए कोडिंग परंपराएं === | === भाषाओं के लिए कोडिंग परंपराएं === | ||
*एक्शनस्क्रिप्ट: [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 201: | Line 176: | ||
*[http://rfc.zeromq.org/spec:21 ZeroMQ C लैंग्वेज स्टाइल फॉर स्केलेबिलिटी (क्लास)] | *[http://rfc.zeromq.org/spec:21 ZeroMQ C लैंग्वेज स्टाइल फॉर स्केलेबिलिटी (क्लास)] | ||
[[Category:Articles with Curlie links]] | |||
[[Category: | |||
[[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 की शक्ति: सुरक्षा-महत्वपूर्ण कोड विकसित करने के नियम
संदर्भ
- ↑ Robert L. Glass: Facts and Fallacies of Software Engineering; Addison Wesley, 2003.
- ↑ 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.
- ↑ Raymond, Eric (2000-05-01). "Why Python?". Linux Journal.
कोडिंग मानकों की सूची
भाषाओं के लिए कोडिंग परंपराएं
- एक्शनस्क्रिप्ट: फ्लेक्स एसडीके कोडिंग कन्वेंशन और सर्वोत्तम अभ्यास
- Ada: Ada 95 क्वालिटी और स्टाइल गाइड: प्रोफेशनल प्रोग्रामर्स के लिए दिशानिर्देश
- एडीए: हाई इंटीग्रिटी सिस्टम में एडीए प्रोग्रामिंग लैंग्वेज के इस्तेमाल के लिए गाइड (आईएसओ/आईईसी टीआर 15942:2000)
- एडीए: नासा फ्लाइट सॉफ्टवेयर ब्रांच-एडा कोडिंग स्टैंडर्ड
- एडीए: ईएसए एडीए कोडिंग स्टैंडर्ड - बीएसएससी(98)3 अंक 1 अक्टूबर 1998
- एडा: यूरोपियन स्पेस एजेंसी की सॉफ्टवेयर इंजीनियरिंग और मानकीकरण
- C: CERT C कोडिंग मानक CERT C कोडिंग मानक (SEI)
- C: Embedded C Coding Standard (बार ग्रुप)
- C: फ़र्मवेयर डेवलपमेंट स्टैंडर्ड (जैक गांस्ले)
- सी: मिश्रा सी
- सी: टीआईओबीई सी मानक[1]
- C++: C++ कोर दिशानिर्देश (बज़्ने स्ट्रॉस्ट्रुप, हर्ब सटर)
- C++: क्वांटम लीप्स C/C++ कोडिंग स्टैंडर्ड
- C++: b:C++ प्रोग्रामिंग/प्रोग्रामिंग लैंग्वेज/C++/कोड/स्टाइल कन्वेंशन|C++ प्रोग्रामिंग/प्रोग्रामिंग लैंग्वेज/C++/कोड/स्टाइल कन्वेंशन
- C++: GeoSoft's C++ प्रोग्रामिंग स्टाइल गाइडलाइंस
- C++: Google की C++ स्टाइल गाइड
- सी++: उच्च अखंडता सी++
- सी++: मिश्रा C++
- C++: Philips Healthcare C++ कोडिंग मानक[2]
- C/C++: devolo/software-quality C/C++ कोडिंग दिशानिर्देश देवोलो से
- C#: C# कोडिंग कन्वेंशन (C# प्रोग्रामिंग गाइड)
- सी#: क्लास लाइब्रेरी विकसित करने के लिए डिज़ाइन दिशानिर्देश
- सी#: ब्रैड अब्राम्स
- C#: Philips Healthcare या Philips Healthcare C# कोडिंग मानक[3]
- डी: डी स्टाइल
- डार्ट: डार्ट स्टाइल गाइड
- Erlang: Erlang प्रोग्रामिंग नियम और परंपराएं
- फ्लेक्स: फ्लेक्स एसडीके के लिए कोड कन्वेंशन
- जावा: जावा के लिए एंबीसॉफ्ट के कोडिंग मानक
- जावा: जावा प्रोग्रामिंग लैंग्वेज के लिए कोड कन्वेंशन (सक्रिय रूप से अनुरक्षित नहीं। नवीनतम संस्करण: 1999-APR-20।)
- जावा: जियोसॉफ्ट के जावा प्रोग्रामिंग स्टाइल दिशानिर्देश
- जावा: Java Coding Standards at Curlie
- जावा: टीआईओबीई जावा मानक[4]
- जावा: SoftwareMonkey's कोडिंग कन्वेंशन जावा और अन्य ब्रेस-सिंटेक्स भाषाओं के लिए
- जावास्क्रिप्ट: जावास्क्रिप्ट प्रोग्रामिंग लैंग्वेज के लिए कोड कन्वेंशन
- लिस्प: Riastrad's Lisp स्टाइल रूल्स
- MATLAB: MATLAB के लिए न्यूरोबैट कोडिंग कन्वेंशन Archived 2014-10-14 at the Wayback Machine
- ऑब्जेक्ट पास्कल: ऑब्जेक्ट पास्कल स्टाइल गाइड
- पर्ल: पर्ल स्टाइल गाइड
- PHP::PEAR: PHP::PEAR कोडिंग मानक
- PHP::FIG: PHP फ्रेमवर्क इंटरॉप ग्रुप
- पीएल/आई: पीएल/आई स्टाइल गाइड
- Python: Python कोड के लिए स्टाइल गाइड
- आर: साफ-सुथरा स्टाइल गाइड
- रूबी: अनौपचारिक रूबी उपयोग गाइड
- रूबी: GitHub रूबी स्टाइल गाइड
- शैल: Google की शैल स्टाइल गाइड
परियोजनाओं के लिए कोडिंग सम्मेलन
- अपाचे डेवलपर्स की सी लैंग्वेज स्टाइल गाइड
- Drupal PHP कोडिंग मानक
- जीएनयू कोडिंग मानक
- "GNAT Coding Style: A Guide for GNAT Developers". GCC online documentation. Free Software Foundation. Retrieved 2009-01-19. (PDF)
- Linux Kernel Coding Style (या Linux Kernel source tree में Documentation/CodingStyle)
- Mozilla Coding Style Guide
- मोनो: मोनो के लिए प्रोग्रामिंग शैली
- OpenBSD कर्नेल सोर्स फ़ाइल स्टाइल गाइड (KNF)
- रोड इंट्रानेट के C++ दिशानिर्देश
- Google द्वारा उत्पन्न ओपन-सोर्स प्रोजेक्ट के लिए स्टाइल गाइड
- The NetBSD सोर्स कोड स्टाइल गाइड (पहले इसे BSD कर्नेल नॉर्मल फॉर्म के नाम से जाना जाता था)
- Zend फ्रेमवर्क कोडिंग मानक
- ZeroMQ C लैंग्वेज स्टाइल फॉर स्केलेबिलिटी (क्लास)
- ↑ "टीआईओबीई - सी कोडिंग मानक". tics.tiobe.com. Retrieved 2021-03-11.
- ↑ "सी ++ कोडिंग मानक". tics.tiobe.com. Retrieved 2021-03-11.
- ↑ "सी # कोडिंग मानक". tics.tiobe.com. Retrieved 2021-03-11.
- ↑ "TIOBE - जावा कोडिंग स्टैंडर्ड". tics.tiobe.com. Retrieved 2021-03-11.
