आम प्रोग्रामिंग खामियों से बचने के लिए

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



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

यहां कुछ सामान्य खामियां हैं जिनसे एक प्रोग्रामर को बचना चाहिए।

1. फ़ंक्शन में बहुत अधिक क्रियाएं

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

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

2. परियोजना ने कोड टिप्पणी की है

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

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

3. खराब चर नाम

एक बार मैंने एक लेख लिखा था जिसमें अच्छे चर नामों के चयन के लिए सरल नियम प्रस्तुत किए गए थे। गुणात्मक चर नाम अत्यंत महत्वपूर्ण हैं। तथ्य यह है कि प्रोग्रामर आमतौर पर अकेले परियोजनाओं पर काम नहीं करते हैं। उनके सहयोगियों को उस कोड को समझने की आवश्यकता है जो वे लिखते हैं। दोस्ताना चर नाम किसी और के कोड की धारणा को बेहतर बनाने में मदद करते हैं।

मैंने उपरोक्त सामग्री में जो कहा है उसे दोहराता हूं: "अच्छे चर नामों को चुनने में समय लगता है, लेकिन इससे अधिक समय लगता है।"

4. "मैजिक नंबर" और तार

यदि हम अस्पष्ट चर नामों की समस्या के बारे में अपनी चर्चा जारी रखते हैं, तो हम कार्यक्रम में कुछ निश्चित मूल्यों का उपयोग करने के विचार में आ सकते हैं, "मैजिक नंबर" या ऐसे तार जिनका कोई नाम नहीं है और जिन्हें किसी भी चर में नहीं लिखा गया है।

आप विकिपीडिया से सीख सकते हैं कि "मैजिक नंबरों" को खराब प्रोग्रामिंग प्रैक्टिस कहा जाता है जब स्रोत पाठ में एक संख्यात्मक मूल्य पाया जाता है और यह स्पष्ट नहीं है कि इसका क्या मतलब है।

निम्नलिखित कोड उदाहरण पर एक नज़र डालें:

for ($i = 1; $i <= 52; $i++) {     ... } 

यहाँ मान 52 "मैजिक नंबर" है। कोई नहीं जानता कि यह वास्तव में 52 नंबर क्यों है, और इसका क्या मतलब है। 52 क्यों? 64 क्यों नहीं? शायद यह एक वर्ष में हफ्तों की संख्या है?
यदि आप इसे इस तरह से लिखते हैं तो यह कोड बहुत स्पष्ट हो जाएगा:

 $cardDeckSize = 52; for ($i = 1; $i <= $cardDeckSize; $i++) {    ... } 

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

यही बात स्ट्रिंग्स के साथ काम करने पर लागू होती है:

 if (userPasswordIsValid($user, "6yP4cZ".$password)) {    ... } 

यह 6yP4cZ क्या है? एक यादृच्छिक चरित्र सेट की तरह दिखता है।

हम इसे फिर से लिखते हैं:

 $salt = "6yP4cZ"; if (userPasswordIsValid($user, $salt.$password)) {    ... } 

लेकिन अब सब कुछ बहुत स्पष्ट है।

5. गलत कोड स्वरूपण

बिना कोड प्रोग्रामर के लिए अनुपयोगी कोडिंग एक "बीमारी" है। कुछ अनुभव वाले कई डेवलपर्स से यह पूछे जाने पर कि क्या वे एक परीक्षक या डेटा वैज्ञानिक को जानते हैं जो कोड को अच्छी तरह से प्रारूपित नहीं करते हैं, उनकी पुष्टि की जाती है। इसका कारण अनुभव की कमी है। एकमात्र अपवाद वे प्रोग्रामर हैं जो पायथन जैसी भाषा का उपयोग करते हैं, जिसमें कोड का प्रारूपण कार्यक्रम के निष्पादन को प्रभावित करता है।

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

6. कोड में हार्ड-कोड किए गए मान

यदि मान प्रोग्राम में हार्ड-कोड किए गए हैं, तो इसका मतलब है कि डेटा सीधे स्रोत कोड या अन्य समान वस्तुओं में एम्बेडेड है। इस दृष्टिकोण के विपरीत बाहरी स्रोतों से डेटा प्राप्त कर रहे हैं या कार्यक्रम के निष्पादन के दौरान उन्हें उत्पन्न कर रहे हैं।

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

ज्यादातर, पासवर्ड और फ़ाइल पथ हार्डकोड होते हैं। वे कई कारणों से ऐसा करते हैं, कभी-कभी उन्हें उचित भी ठहराया जा सकता है।

उदाहरण के लिए, कई हार्ड-कोडित मूल्य कोड के कुछ उदाहरणों में बाहरी सेवाओं या एपीआई पर प्रमाणीकरण के लिए जिम्मेदार देखे जा सकते हैं। ऐसा न करना बेहतर है।

यदि किसी ने उन मूल्यों के लगातार उपयोग पर ध्यान दिया है जो हार्डकोड किए गए हैं, तो उन्हें अपने काम का गंभीर रूप से मूल्यांकन करना चाहिए। तथ्य यह है कि आमतौर पर ऐसे मूल्यों का उपयोग कुछ समस्याओं को हल करने का सबसे अच्छा तरीका नहीं है।

प्रिय पाठकों! आपने जो कोड का सामना किया है उसमें क्या खामियां हैं?