योग्यरित्या कार्यरत कार्यक्रम

1. प्रोग्रामरचे काम

बर्‍याचदा नवशिक्या प्रोग्रामर प्रोग्रामरच्या कामाचा अनुभवी प्रोग्रामर कसा विचार करतात त्यापेक्षा पूर्णपणे वेगळा विचार करतात.

नवशिक्या अनेकदा "कार्यक्रम चालतो, तुम्हाला आणखी काय हवे आहे?" अनुभवी प्रोग्रामरला माहित आहे की "योग्यरित्या कार्य करते" ही प्रोग्रामसाठी फक्त एक आवश्यकता आहे आणि ती सर्वात महत्वाची गोष्ट देखील नाही !

कोड वाचनीयता

सर्वात महत्वाची गोष्ट म्हणजे प्रोग्राम कोड इतर प्रोग्रामरना समजण्यासारखा आहे . हे योग्यरित्या कार्यरत प्रोग्रामपेक्षा अधिक महत्वाचे आहे. जास्त.

जर तुमच्याकडे एखादा प्रोग्राम योग्यरित्या कार्य करत नसेल तर तुम्ही त्याचे निराकरण करू शकता. परंतु जर तुमच्याकडे एखादा प्रोग्राम असेल ज्याचा कोड समजण्यासारखा नाही, तर तुम्ही त्यासह काहीही करू शकत नाही.

फक्त कोणताही संकलित केलेला प्रोग्राम घ्या, जसे की नोटपॅड, आणि त्याचा पार्श्वभूमी रंग लाल रंगात बदला. तुमच्याकडे एक कार्यरत प्रोग्राम आहे, परंतु तुमच्याकडे समजण्याजोगा स्त्रोत कोड नाही: अशा प्रोग्राममध्ये बदल करणे अशक्य आहे.

पाठ्यपुस्तकातील उदाहरण म्हणजे जेव्हा मायक्रोसॉफ्ट डेव्हलपर्सने Windows मधून पिनबॉल गेम काढून टाकला कारण ते 64-बिट आर्किटेक्चरमध्ये पोर्ट करू शकले नाहीत. आणि त्यांच्याकडे त्याचा स्त्रोत कोड देखील होता. कोड कसा कार्य करतो हे त्यांना समजू शकले नाही .

प्रत्येक वापर प्रकरणासाठी लेखांकन

प्रोग्रामसाठी दुसरी सर्वात महत्वाची आवश्यकता म्हणजे प्रत्येक परिस्थितीचा हिशेब ठेवणे. बर्‍याचदा गोष्टी दिसतात त्यापेक्षा किंचित जास्त क्लिष्ट असतात.

नवशिक्या प्रोग्रामर एसएमएस संदेश पाठवताना कसे पाहतो:

व्यावसायिक प्रोग्रामर हे कसे पाहतो:

"योग्यरितीने कार्य करते" परिस्थिती सहसा फक्त एक अनेक शक्य असते. आणि म्हणूनच अनेक नवशिक्या CodeGym च्या टास्क व्हॅलिडेटरबद्दल तक्रार करतात: 10 पैकी फक्त एकच परिस्थिती काम करते आणि नवशिक्या प्रोग्रामरला वाटते की ते पुरेसे आहे.

2. असामान्य परिस्थिती

कोणत्याही कार्यक्रमाच्या अंमलबजावणीमध्ये असामान्य परिस्थिती उद्भवू शकते.

उदाहरणार्थ, तुम्ही फाइल सेव्ह करण्याचे ठरवले आहे परंतु डिस्कमध्ये जागा नाही. किंवा प्रोग्राम मेमरीमध्ये डेटा लिहिण्याचा प्रयत्न करीत आहे, परंतु उपलब्ध मेमरी कमी आहे. किंवा तुम्ही इंटरनेटवरून चित्र डाउनलोड करता, परंतु डाउनलोड प्रक्रियेदरम्यान कनेक्शन गमावले जाते.

प्रत्येक असामान्य परिस्थितीसाठी, प्रोग्रामरने (प्रोग्रामच्या लेखकाने) अ) त्याचा अंदाज लावला पाहिजे , ब) प्रोग्रामने ते नेमके कसे हाताळावे हे ठरवावे , आणि क) इच्छित एकाच्या शक्य तितक्या जवळ असलेले समाधान लिहावे.

म्हणूनच प्रोग्राम्समध्ये बर्‍याच काळासाठी अगदी साधे वर्तन होते: जर प्रोग्राममध्ये एखादी त्रुटी आली तर प्रोग्राम संपुष्टात आला. आणि तो एक चांगला दृष्टीकोन होता.

समजा तुम्हाला डिस्कवर एक डॉक्युमेंट सेव्ह करायचा आहे, सेव्ह प्रक्रियेदरम्यान तुम्हाला डिस्कवर पुरेशी जागा नसल्याचे समजते. तुम्हाला कोणते वर्तन सर्वात जास्त आवडेल:

• कार्यक्रम संपतो
• प्रोग्राम चालू राहतो, परंतु फाइल जतन करत नाही.

एक नवशिक्या प्रोग्रामर विचार करू शकतो की दुसरा पर्याय अधिक चांगला आहे, कारण प्रोग्राम अद्याप चालू आहे. पण प्रत्यक्षात तसे नाही.

कल्पना करा की तुम्ही वर्डमध्ये 3 तासांसाठी एक दस्तऐवज टाईप केला आहे, परंतु तुमच्या लेखन प्रक्रियेच्या दोन मिनिटांत हे स्पष्ट झाले की प्रोग्राम डिस्कवर डॉक्युमेंट सेव्ह करू शकणार नाही. कामाचे दोन मिनिटे किंवा तीन तास गमावणे चांगले आहे का?

कार्यक्रम आवश्यक ते करू शकत नसल्यास, सर्वकाही ठीक आहे असे ढोंग करण्यापेक्षा ते बंद करणे चांगले आहे. जेव्हा प्रोग्राम स्वतःहून निराकरण करू शकत नाही अशा अपयशाचा सामना करतो तेव्हा करू शकतो ती सर्वोत्तम गोष्ट म्हणजे त्वरित वापरकर्त्याला समस्येची तक्रार करणे.

3. अपवादांबद्दल पार्श्वभूमी

केवळ कार्यक्रम असे नसतात जे असामान्य परिस्थितींचा सामना करतात. ते प्रोग्राम्समध्ये देखील आढळतात - पद्धतींमध्ये. उदाहरणार्थ:

• पद्धत डिस्कवर फाइल लिहू इच्छित आहे, परंतु तेथे जागा नाही.
• पद्धत व्हेरिएबलवर फंक्शन कॉल करू इच्छिते, परंतु व्हेरिएबल शून्य बरोबर आहे.
• ० ने भागाकार पद्धतीत होतो.

या प्रकरणात, कॉलिंग पद्धतीमध्ये कोणत्या प्रकारची समस्या आली हे माहित असल्यास, कॉलिंग पद्धत शक्यतो परिस्थिती दुरुस्त करू शकते (पर्यायी परिस्थिती कार्यान्वित करा).

जर आम्ही एखादी फाइल डिस्कवर सेव्ह करण्याचा प्रयत्न करत असलो आणि अशी फाइल आधीच अस्तित्वात असेल, तर आम्ही वापरकर्त्याला फाईल ओव्हरराईट करण्याची पुष्टी करण्यास सांगू शकतो. डिस्क स्पेस उपलब्ध नसल्यास, आम्ही वापरकर्त्याला संदेश प्रदर्शित करू शकतो आणि वापरकर्त्याला वेगळी डिस्क निवडण्यास सांगू शकतो. परंतु जर प्रोग्रामची मेमरी संपली तर ते क्रॅश होईल.

एकेकाळी, प्रोग्रामरने या प्रश्नावर विचार केला आणि खालील उपाय शोधून काढले: सर्व पद्धती/फंक्शन्सने त्यांच्या अंमलबजावणीचा परिणाम दर्शविणारा त्रुटी कोड परत करणे आवश्यक आहे. फंक्शन उत्तम प्रकारे काम करत असल्यास, ते 0 परत करते . नसल्यास, त्याने त्रुटी कोड परत केला (शून्य नाही).

त्रुटींकडे या दृष्टिकोनामुळे, जवळजवळ प्रत्येक फंक्शन कॉलनंतर, प्रोग्रामरना फंक्शन त्रुटीसह पूर्ण झाले की नाही हे पाहण्यासाठी एक तपासणी जोडावी लागली. कोड आकारात फुगा आणि यासारखा दिसला:

File file = new File("ca:\\note.txt");
file.writeLine("Text");
file.close();

File file = new File("ca:\\note.txt");
int status = file.writeLine("Text");
if (status == 1)
{
   ...
}
else if (status == 2)
{
   ...
}
status = file.close();
if (status == 3)
{
   ...
}

इतकेच काय, अनेकदा एखादे फंक्शन आढळून आले की एरर आली आहे, त्याचे काय करावे हे कळत नाही: कॉलरला एरर परत करावी लागली आणि कॉलरच्या कॉलरने ती त्याच्या कॉलरला परत केली, आणि असेच.

मोठ्या प्रोग्राममध्ये, डझनभर फंक्शन कॉलची साखळी सामान्य आहे: काहीवेळा आपण शेकडो फंक्शन्सची कॉल डेप्थ देखील शोधू शकता. आणि आता तुम्हाला एरर कोड अगदी तळापासून अगदी वरपर्यंत पास करावा लागेल. आणि जर कुठेतरी मार्गात काही फंक्शन एक्झिट कोड हाताळत नसेल तर त्रुटी नष्ट होईल.

या दृष्टिकोनाचा आणखी एक तोटा असा आहे की जर फंक्शन्सने एरर कोड परत केला तर ते यापुढे त्यांच्या स्वतःच्या कामाचे परिणाम परत करू शकत नाहीत. गणनेचा निकाल संदर्भ पॅरामीटर्सद्वारे पास करणे आवश्यक होते. यामुळे कोड आणखी किचकट झाला आणि त्रुटींची संख्या आणखी वाढली.