169

मैं वास्तव में बड़े प्रोजेक्ट नहीं लिखता। मैं एक विशाल डेटाबेस को बनाए नहीं रख रहा हूं या कोड की लाखों लाइनों से निपट रहा हूं।

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

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

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

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

क्या इकाई परीक्षण कोड के छोटे टुकड़ों को लिखने के लिए आवश्यक है? OOP के बारे में कैसे? बड़े प्रोजेक्ट पर काम करने के विपरीत "वैज्ञानिक प्रोग्रामिंग" करते समय अच्छे, साफ कोड लिखने के लिए किस तरह के दृष्टिकोण अच्छे हैं?

मैं ये सवाल पूछता हूं क्योंकि अक्सर, प्रोग्रामिंग ही सुपर कॉम्प्लेक्स नहीं होती है। यह गणित या विज्ञान के बारे में अधिक है जिसे मैं प्रोग्रामिंग के साथ परीक्षण या शोध कर रहा हूं। जैसे, क्या एक वर्ग आवश्यक है जब दो चर और एक फ़ंक्शन शायद इसका ख्याल रख सकते हैं? (विचार करें कि ये भी आम तौर पर ऐसी परिस्थितियाँ होती हैं जहाँ कार्यक्रम की गति को तेज़ अंत में पसंद किया जाता है - जब आप किसी अनुकार के 25,000,000+ समय के चरण को चला रहे हों, तो आप चाहते हैं कि यह हो।)

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

मुझे अधिक विशिष्ट विवरण प्रदान करने में खुशी होगी, लेकिन अधिक सामान्य सलाह, अधिक उपयोगी, मुझे लगता है। मैं पायथन 3 में प्रोग्रामिंग कर रहा हूं।

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

कुछ अपवाद हैं। इसके अलावा, वहाँ सिर्फ सादे मानकों से परे वैज्ञानिक प्रोग्रामिंग के लिए शायद मानक हैं। मैं उन लोगों के बारे में भी पूछ रहा हूं। यह इस बारे में नहीं है कि अगर वैज्ञानिक कोड लिखते समय सामान्य कोडिंग मानकों की अनदेखी की जानी चाहिए, तो यह स्वच्छ वैज्ञानिक कोड लिखने के बारे में है!

अपडेट करें

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

मैंने भी पाइलिंट लगाया और अपने सभी कोड पर इसे चलाया। एक फ़ाइल को शुरू में नकारात्मक अंक मिला; मुझे भी यकीन नहीं है कि यह कैसे संभव था। मेरी मुख्य फ़ाइल ~ 1.83 / 10 के स्कोर पर शुरू हुई और अब ~ 9.1 / 10 पर है। सभी कोड अब मानकों के अनुरूप हैं। मैं अपनी आँखों के साथ चर नामों को अद्यतन करने के लिए भी दौड़ा, जो चले गए थे ... उह ... जाग, और खंड के खंड की तलाश में।

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

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

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

तो ... मुझे लगता है कि यह सब कहना है: धन्यवाद ।

— हीथ
स्रोत

3

क्या वैज्ञानिक कोडिंग की

— gnat

9

आपको उत्तर मिल सकता है कि क्या वैज्ञानिक शोध कोड के लिए इकाई परीक्षण लिखना सार्थक है? उपयोगी।

— मार्क बूथ

8

यदि आप सक्रिय रूप से अपने कोड में सुधार करना चाहते हैं, तो आप कोड समीक्षा पर कुछ पोस्ट करने पर विचार कर सकते हैं । वहां का समुदाय ख़ुशी से आपकी मदद करेगा।

— हॉफमेल

7

जब आप कहते हैं "संस्करण नियंत्रण का उपयोग करने से अलग, और प्रत्येक नए पुनरावृत्ति के लिए एक नई फ़ाइल बनाना और एक पाठ फ़ाइल में यह सब" कहीं "और" क्या आपका मतलब है "या" क्योंकि आप संस्करण नियंत्रण का उपयोग कर रहे हैं तो आपको रिकॉर्डिंग करनी चाहिए। 'कॉपी पेस्ट करने वाले संस्करण नहीं होंगे। मुद्दा यह है कि संस्करण नियंत्रण आपके लिए सभी पुराने संस्करण रखता है

— रिचर्ड टिंगल

2

@ मैथ्रेडलर मुझे नहीं लगता कि आप काफी समझते हैं। हाँ, केवल मैं शायद वास्तव में पढ़ने जा रहा हूं और कोड के साथ गड़बड़ कर रहा हूं (हालांकि आप कभी नहीं जानते हैं, और मेरे पास कोई ऐसा व्यक्ति है जिसके साथ मैं काम कर सकता हूं, हालांकि एक अलग भाषा में) ... लेकिन कोड अभी भी है बकवास। मुझे इसे बाद में पढ़ना होगा और यह पता लगाना होगा कि मैं क्या कर रहा हूँ। यह है एक समस्या है, और क्योंकि मैं अब प्रभाव अनुभव कर रहा हूँ मैं यह करने के लिए गवाही देने के कर सकते हैं और के रूप में मैं संस्करण नियंत्रण और अन्य तकनीकों यहाँ सुझाव को क्रियान्वित किया है चीजों को आसान हो गए हैं।

— हीथ

163

यह वैज्ञानिकों के लिए एक बहुत ही आम समस्या है। मैंने इसे बहुत देखा है, और यह हमेशा इस तथ्य से उपजा है कि प्रोग्रामिंग कुछ है जो आप अपने काम को करने के लिए एक उपकरण के रूप में उठाते हैं।

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

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

आपकी मुख्य समस्या पठनीयता की ओर जा रही है, इसलिए यहां सुधार के लिए कुछ सुझाव दिए गए हैं:

चर नाम:

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

अपने कोड को कार्यों में विभाजित करें:

अब जब आपने अपने सभी चरों का नाम बदल लिया, तो आपके समीकरण बहुत भयानक लग रहे हैं, और कई लाइनें लंबी हैं।

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

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

केक पर आइसिंग, अगर उन कार्यों को आपके अधिक कार्यक्रमों में आवश्यक है, तो आप बस उनके लिए एक पुस्तकालय बना सकते हैं, और आप उन्हें हमेशा उपलब्ध रहेंगे।

सार्वत्रिक चर:

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

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

संस्करण नियंत्रण

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

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

— BgrWorker
स्रोत

56

बहुत बढ़िया सलाह। हालाँकि मैं "इतना बुरा नहीं है" टिप्पणी के लिए upvote नहीं कर सकता। यह बहुत बुरा है। कम गुणवत्ता वाली वैज्ञानिक स्क्रिप्ट डेटा विश्लेषण में प्रतिलिपि प्रस्तुत करने और विश्लेषण में त्रुटि का लगातार स्रोत के लिए एक बड़ा मुद्दा है। अच्छा कोड लिखना न केवल इतना मूल्यवान है कि आप इसे बाद में समझ सकें बल्कि इसलिए भी कि आप पहली बार में त्रुटियों से बच सकें।

— जैक ऐडली

22

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

— cHao

11

@ cHao समस्या तब नहीं है जब उन चर को सूत्र में प्लग किया जाता है (इसलिए "फ़ंक्शन के अंदर उन्हें नाम बदलें" सलाह), लेकिन जब वे पढ़े जाते हैं और इसके बाहर हेरफेर करते हैं, और जब वे लाइन के नीचे अन्य चर के साथ विरोध शुरू करते हैं (उदाहरण के लिए, मैंने लोगों को तीन "x" चर की आवश्यकता के रूप में देखा है, जिनका नाम उन्हें X1, x2, x3 है

— BgrWorker

4

"मैं सामान्य ज्ञान के खिलाफ जाने वाला हूं ..." नहीं, आप नहीं हैं। आप प्रचलित हठधर्मिता के खिलाफ जा रहे हैं, जो कि सामान्य ज्ञान के खिलाफ है। ;) यह सब पूरी तरह से ध्वनि सलाह है।

— jpmc26

3

एक (पूर्व) वैज्ञानिक प्रोग्रामर के रूप में, मैं आमतौर पर तीन का नियम अपनाता हूं। अगर मैं तीन बार समान कोड लिखना समाप्त कर देता हूं, तो कार्यक्षमता को अलग कर दिया जाता है और एक अलग मॉड्यूल में प्रलेखन के साथ लिखा जाता है (अक्सर सिर्फ टिप्पणियां, लेकिन यह पर्याप्त है)। यह तदर्थ प्रोग्रामिंग की अराजकता को सीमित करता है, और मुझे एक पुस्तकालय बनाने की अनुमति देता है जिसका मैं भविष्य में विस्तार कर सकता हूं।

— rcollyer

141

यहाँ भौतिक विज्ञानी। वहाँ गया।

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

मेरा मानना है कि स्वच्छ कोड लिखने के लिए केवल एक नुस्खा है: इसे उस इंसान के लिए लिखें जो इसे पढ़ने जा रहा है, न कि उस दुभाषिया के लिए जो इसे चलाने जा रहा है। यदि आपका कोड गड़बड़ है, तो दुभाषिया परवाह नहीं करता है, लेकिन मानव पाठक परवाह करता है।

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

साफ कोड लिखना बिल्कुल वैसा ही है। अपने कोड को एक एल्गोरिथ्म के विस्तृत विवरण के रूप में सोचें जो केवल संयोगवश मशीन-पठनीय होता है। कल्पना कीजिए कि आप इसे एक लेख के रूप में प्रकाशित करने जा रहे हैं जिसे लोग पढ़ेंगे। यहां तक कि आप इसे एक सम्मेलन में दिखाने जा रहे हैं और दर्शकों को इसके माध्यम से लाइन से चलना है। अब अपनी प्रस्तुति का पूर्वाभ्यास करें । हाँ, लाइन से लाइन ! शर्मनाक, यह नहीं है? इसलिए अपनी स्लाइड्स को साफ़ करें (जब तक ... मेरा मतलब है, आपका कोड) और फिर से रिहर्सल करें। जब तक आप परिणाम से खुश न हों तब तक दोहराएं।

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

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

उपकरण के रूप में, मैंने कहा कि इससे पहले कि वे नहीं कर रहे हैं कि महत्वपूर्ण है। हालांकि, अगर मुझे एक चुनना था, तो मैं कहूंगा कि संस्करण नियंत्रण सबसे उपयोगी है।

— एडगर बोनट
स्रोत

32

«साफ कोड लिखना बिल्कुल वैसा ही है [जैसा कि एक स्पष्ट लेख लिखना]।» मैं पूरी तरह से समर्थन करता हूं, अच्छी तरह से!

— जुलांडसेंट

43

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

— UEFI

31

साफ कोड लिखने throwaway कोड लिखने की तुलना में बहुत अधिक समय ले करता है, अधिक महत्वपूर्ण यह है कि पढ़ने throwaway कोड स्वच्छ कोड को पढ़ने के तुलना में बहुत अधिक समय लगता है।

— user949300

3

@ यूईएफआई नहीं, यह कुछ सबसे पेशेवर प्रोग्रामर भी महसूस नहीं करते हैं। या परवाह नहीं है।

— jpmc26

2

100% सहमत हूँ। सांख्यिकीविद ने प्रोग्रामर को बदल दिया, इसलिए मैं काम पर 'वैज्ञानिक' प्रोग्रामिंग की एक उचित मात्रा में करता हूं। स्पष्ट टिप्पणी के साथ स्पष्ट कोड, एक जीवनरक्षक है जब आपको उस कोड 1, 4 या 12 महीने बाद वापस जाना होगा। कोड को पढ़ना आपको बताता है कि कोड क्या कर रहा है। टिप्पणियों को पढ़ना आपको बताता है कि कोड क्या करना चाहिए।

— रेल्सडॉग

82

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

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

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

संस्करण नियंत्रण और लेखन इकाई परीक्षणों के बीच जैसे ही आप जाते हैं, आप कोड स्वाभाविक रूप से बहुत क्लीनर बन जाएंगे। जब आप किसी पठार से टकराते हैं तो क्लीनर कोडिंग के लिए अन्य तकनीकों को सीखा जा सकता है।

— कार्ल बेवफेल्ड
स्रोत

78

मैं अपने अधिकांश कोड का धार्मिक रूप से परीक्षण करता हूं, लेकिन मैंने यूनिट परीक्षण अन्वेषणात्मक, वैज्ञानिक कोड को बेकार से कम पाया है । मौलिक रूप से कार्यप्रणाली यहां काम नहीं करती है। मैं अपने क्षेत्र में किसी भी कम्प्यूटेशनल वैज्ञानिक को नहीं जानता जो अपने विश्लेषण कोड को यूनिट-टेस्ट करता है। मुझे यकीन नहीं है कि इस बेमेल का कारण क्या है, लेकिन एक कारण यह है कि निश्चित रूप से, तुच्छ इकाइयों को छोड़कर, अच्छे परीक्षण मामलों को स्थापित करना कठिन या असंभव है।

— कोनराड रुडोल्फ

22

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

— एंट पी।

18

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

— दान ब्रायंट

12

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

— जेम्स_पिक

7

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

— jpmc26

29

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

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

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

क्या इकाई परीक्षण कोड के छोटे टुकड़ों को लिखने के लिए आवश्यक है? OOP के बारे में कैसे? बड़े प्रोजेक्ट पर काम करने के विपरीत "वैज्ञानिक प्रोग्रामिंग" करते समय अच्छे, साफ कोड लिखने के लिए किस तरह के दृष्टिकोण अच्छे हैं?

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

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

— पीटर टेलर
स्रोत

4

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

— सिली फ्रिक

तोड़फोड़, git, और Mercurial कोई फ़र्ज़ी नहीं हैं। मैं तोड़फोड़ पर एक स्थानीय भंडार के साथ Git (या Mercurial) का उपयोग करने की जोरदार वकालत करूंगा। एक एकल कोडर के साथ, तोड़फोड़ की खामियां एक मुद्दे से कम हैं, लेकिन यह सहयोगी विकास के लिए एक महान उपकरण नहीं है और यह संभवतः अनुसंधान में हो सकता है

— mcottle

2

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

— पीटर टेलर

21

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

यदि आप वैज्ञानिक गणना करने के लिए स्क्रिप्ट लिख रहे हैं, तो संभवतः आपके पास उन समीकरणों या एल्गोरिदम के साथ कागजात हैं जो आप उनमें लिखे गए हैं। यदि आप अपने द्वारा खोजे गए नए विचारों का उपयोग कर रहे हैं, तो आप उम्मीद करते हैं कि आप उन्हें अपने स्वयं के पत्रों में प्रकाशित करेंगे। इस मामले में, नियम यह है: आप चाहते हैं कि आपका कोड यथासंभव प्रकाशित समीकरणों को पढ़ें। यहां सॉफ्टवेयर इंजीनियरिंग पर एक उत्तर दिया गया है। इस दृष्टिकोण की वकालत करने वाले 200 से अधिक अपवोट्स के साथ और यह बताते हुए कि यह कैसा दिखता है: क्या लघु चर नामों का बहाना है?

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

ContactGeometry.cpp:

// t = (-b +/- sqrt(b^2-4ac)) / 2a
// Discriminant must be nonnegative for real surfaces
// but could be slightly negative due to numerical noise.
Real sqrtd = std::sqrt(std::max(B*B - 4*A*C, Real(0)));
Vec2 t = Vec2(sqrtd - B, -sqrtd - B) / (2*A);

ContactGeometry_Sphere.cpp:

// Solve the scalar Jacobi equation
//
//        j''(s) + K(s)*j(s) = 0 ,                                     (1)
//
// where K is the Gaussian curvature and (.)' := d(.)/ds denotes differentiation
// with respect to the arc length s. Then, j is the directional sensitivity and
// we obtain the corresponding variational vector field by multiplying b*j. For
// a sphere, K = R^(-2) and the solution of equation (1) becomes
//
//        j  = R * sin(1/R * s)                                        (2)
//          j' =     cos(1/R * s) ,                                      (3)
//
// where equation (2) is the standard solution of a non-damped oscillator. Its
// period is 2*pi*R and its amplitude is R.

// Forward directional sensitivity from P to Q
Vec2 jPQ(R*sin(k * s), cos(k * s));
geod.addDirectionalSensitivityPtoQ(jPQ);

// Backwards directional sensitivity from Q to P
Vec2 jQP(R*sin(k * (L-s)), cos(k * (L-s)));
geod.addDirectionalSensitivityQtoP(jQP);

— केविन
स्रोत

9

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

— डेविड हैमेन

@David Hammen: एक स्नातक छात्र के रूप में, मैं इसका सम्मान करता हूं। एक प्रोग्रामर के रूप में, मैं फिर आग्रह करता हूं कि आपके पास सादे अंग्रेजी (या आपके चयन की भाषा) में वर्णित प्रत्येक फ़ंक्शन के शीर्ष पर एक विशाल टिप्पणी ब्लॉक है, जो प्रत्येक चर के लिए खड़ा था, भले ही एक अस्थायी प्लेसहोल्डर हो। इस तरह से मुझे कम से कम वापस देखने के लिए एक संदर्भ है।

— टनसडग

1

@DavidHammen इसके अलावा, UTF-8 स्रोत फ़ाइलों में और चर नाम के लिए सरल नियम के लिए अजगर समर्थन आसान घोषित करने के लिए बनाता है λया φबदसूरत के बजाय lambda_या phy...

— मैथियास Ettinger

1

@tonysdg आपके पास पहले से ही एक संदर्भ है; इसे "हैमेन, एट अल। (2018)" (या जो भी) कहा जाता है। यह किसी भी टिप्पणी ब्लॉक की तुलना में कहीं अधिक विस्तार से चर का अर्थ समझाएगा। कागज में संकेतन के करीब चर नामों को रखने का कारण यह है कि कोड में क्या है, इसे जोड़ने के लिए यह आसान बनाना ठीक है।

— कोई नहीं

17

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

लेकिन कुछ ऐसा है जिसका मैंने उल्लेख नहीं किया है, जो मुझे लगता है कि महत्वपूर्ण है, यह है कि फंडिंग एजेंसियां तेजी से डेटा प्रकाशन के एक भाग के रूप में सॉफ्टवेयर प्रकाशन को देख रही हैं, और सॉफ्टवेयर प्रकाशन को खुले विज्ञान के लिए एक आवश्यकता बना रही हैं।

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

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

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

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

उन प्रथाओं की एक उच्च-स्तरीय रूपरेखा जो वे सुझाते हैं:

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

इनमें से प्रत्येक बिंदु पर कागज काफी विस्तार में जाता है।

— डेविड मोल्स
स्रोत

16

क्या यह वास्तव में कोड लिखने के लिए समझ में आता है जो OOP कहलाता है जब कुछ मानक सामान किया जा सकता था, लिखने के लिए बहुत तेज़ होता, और कार्यक्रम की कमी के कारण पठनीयता का समान स्तर होता?

व्यक्तिगत उत्तर:
मैं वैज्ञानिक उद्देश्यों के लिए बहुत सारी स्क्रिप्टिंग करता हूं। छोटी लिपियों के लिए, मैं बस सामान्य अच्छी प्रोग्रामिंग प्रथाओं का पालन करने की कोशिश करता हूं (जैसे कि संस्करण नियंत्रण का उपयोग करके, चर नामों के साथ आत्म-नियंत्रण का अभ्यास करना)। अगर मैं अभी जल्दी से खुलने या किसी डेटासेट की कल्पना करने के लिए कुछ लिख रहा हूं, तो मैं OOP से परेशान नहीं हूं।

सामान्य उत्तर:
"यह निर्भर करता है।" लेकिन अगर आप एक प्रोग्रामिंग अवधारणा या प्रतिमानों का उपयोग करने के लिए यह पता लगाने के लिए संघर्ष कर रहे हैं, तो यहां कुछ बातें सोचने के लिए हैं:

स्केलेबिलिटी: क्या स्क्रिप्ट अकेले खड़ी होने जा रही है, या अंततः एक बड़े कार्यक्रम में इसका उपयोग किया जाएगा? यदि ऐसा है, तो OOP का उपयोग करके बड़ी प्रोग्रामिंग है? क्या आपकी स्क्रिप्ट के कोड को आसानी से बड़े प्रोग्राम में एकीकृत किया जा सकता है?
मॉड्यूलरिटी: सामान्य तौर पर, आपका कोड मॉड्यूलर होना चाहिए। हालाँकि, OOP बहुत ही खास तरीके से कोड को विखंडू में तोड़ता है। क्या उस प्रकार की प्रतिरूपकता (यानी आपकी स्क्रिप्ट को कक्षाओं में तोड़ना) समझ में आता है कि आप क्या कर रहे हैं?

मैं जानना चाहता हूं कि "छोटे से शुरू" कैसे करें और इन छोटे, तेज परियोजनाओं पर सफाई से कार्यक्रम करें।

# 1: वहाँ क्या है के साथ परिचित हो जाओ:
भले ही आप "बस" स्क्रिप्टिंग कर रहे हैं (और आप वास्तव में सिर्फ विज्ञान घटक के बारे में परवाह करते हैं), आपको विभिन्न प्रोग्रामिंग अवधारणाओं और प्रतिमानों के बारे में जानने के लिए कुछ समय लेना चाहिए। इस तरह, आपके पास एक बेहतर विचार हो सकता है कि आपको क्या और कब और क्या उपयोग नहीं करना चाहिए। यह थोड़ा कठिन लग सकता है। और आप अभी भी सवाल कर सकते हैं, "मैं कहाँ शुरू करूँ / मैं क्या देखना शुरू करूँ?" मैं अगले दो बुलेट बिंदुओं में एक अच्छा प्रारंभिक बिंदु समझाने की कोशिश करता हूं।

# 2: आप जो जानते हैं, उसे ठीक करना शुरू करें:
व्यक्तिगत रूप से, मैं उन चीजों से शुरू करूंगा जो मुझे पता है कि वे गलत हैं। कुछ संस्करण नियंत्रण प्राप्त करें और उन चर नामों के साथ बेहतर होने के लिए खुद को अनुशासित करना शुरू करें (यह एक गंभीर संघर्ष है)। आप जो जानते हैं उसे ठीक करना स्पष्ट लग सकता है। हालांकि, मेरे अनुभव में, मैंने पाया है कि एक चीज़ को ठीक करने से मुझे कुछ और करना पड़ता है, और इसी तरह। इससे पहले कि मैं यह जानता हूं, मैंने 10 अलग-अलग चीजों का अनावरण किया है जो मैं गलत कर रहा था और यह पता लगाया कि उन्हें कैसे ठीक किया जाए या उन्हें कैसे साफ तरीके से लागू किया जाए।

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

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

मुझे आशा है कि वह मदद करेंगे!

साइड नोट: मुझे पता है कि आपने एक उदाहरण के रूप में OOP का उपयोग किया था। मैं नहीं चाहता था कि आप यह सोचें कि मैं ओओपी का उपयोग करके लेखन कोड को कैसे संभाल सकता हूं। उस उदाहरण के साथ निरंतर उत्तर लिखना आसान था।

— JustBlossom
स्रोत

मुझे लगता है कि # 3 सबसे महत्वपूर्ण मुद्दा है - एक अनुभवी प्रोग्रामर ओपी को उन अवधारणाओं को बता सकता है जिनकी उन्हें जरूरत है (# 1), स्क्रिप्ट को बेहतर तरीके से कैसे व्यवस्थित करें, और संस्करण नियंत्रण (# 2) का उपयोग कैसे करें।

— डॉक ब्राउन

16

मैं यूनिक्स सिद्धांत से चिपके रहने की सलाह दूंगा: इसे सिंपल, स्टुपिड रखें! (चुम्मा)

या, एक और तरीका रखो: एक समय में एक काम करो, और इसे अच्छी तरह से करो।

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

कोड लाइनों के संदर्भ में, मेरा अनुमान यह है कि 10 लाइनें एक अच्छा कार्य हैं, और 20 से परे कुछ भी सबसे अधिक संभावित बकवास है। अन्य लोगों के पास अन्य उत्तराधिकार हैं। महत्वपूर्ण हिस्सा यह है कि आप वास्तव में एक पल में समझ सकते हैं कि लंबाई को नीचे रखें।

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

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

किस्सा
मैंने एक बार कई महीनों तक रिफलेक्टिंग कोड का बिताया जिसमें प्रत्येक में लगभग 500 लाइनें थीं। मेरे द्वारा किए जाने के बाद, कुल कोड लगभग एक हजार लाइनें कम थीं; मैंने कोड की लाइनों के संदर्भ में नकारात्मक उत्पादन किया था। मुझे कंपनी ( http://www.geekherocomic.com/2008/10/09/programmers-salary-policy/india.html ) पर बकाया है । फिर भी, मुझे दृढ़ता से विश्वास है कि यह मेरे सबसे मूल्यवान कार्यों में से एक था जो मैंने कभी किया था ...

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

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

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

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

— cmaster
स्रोत

2

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

— जाकज

@ जकज आह, उस एक के बारे में पूरी तरह से भूल गया। मुझे याद दिलाने के लिये धन्यवाद। मैंने इसे शामिल करने के लिए अपना उत्तर अपडेट किया है :-)

— cmaster

1

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

— बिल के

11

मैं दूसरों से सहमत हूं कि संस्करण नियंत्रण आपकी कई समस्याओं को तुरंत हल कर देगा। विशेष रूप से:

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

मैं कहूंगा कि इसे उखाड़ फेंके नहीं: सिर्फ गिट का उपयोग करें। साधारण कमांड से चिपके रहें (जैसे सिर्फ एक masterशाखा), शायद एक GUI का उपयोग करें, और आपको ठीक होना चाहिए। एक बोनस के रूप में आप मुफ्त प्रकाशन और बैकअप के लिए गिटलैब, जीथब आदि का उपयोग कर सकते हैं;)

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

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

किसी कार्यक्रम के सामान्य निष्पादन के दौरान जाँच किए जाने के बाद से, इन कमियों में कोई कमी नहीं है। विशेष रूप से:

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

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

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

निक्स जैसे सिस्टम केवल हाल ही में (थोड़ा) लोकप्रिय हो रहे हैं, और कुछ उन्हें "फेंक दूर" कोड के लिए ओवरकिल पर विचार कर सकते हैं जैसे आप वर्णन करते हैं, लेकिन वैज्ञानिक कंप्यूटिंग के प्रतिलिपि प्रस्तुत करने के लिए उनका लाभ बहुत बड़ा है। प्रयोग चलाने के लिए शेल स्क्रिप्ट पर विचार करें, जैसे (उदाहरण run.sh):

#!/usr/bin/env bash
set -e
make all
./analyse < ./dataset > output.csv

हम इसे इस तरह (जैसे run.nix) के बजाय एक निक्स "व्युत्पत्ति" में फिर से लिख सकते हैं :

with import <nixpkgs> {};
runCommand "output.csv" {} ''
  cp -a ${./.} src
  cd src
  make all
  ./analyse < ./dataset > $out
''

बीच ''...''का सामान बैश कोड है, जो पहले हमारे पास था, सिवाय इसके कि ${...}इसका उपयोग अन्य स्ट्रिंग्स की सामग्री में "ब्याह" के लिए किया जा सकता है (इस मामले में ./., जिसमें निर्देशिका युक्त पथ का विस्तार होगा run.nix)। with import ...लाइन निक्स के आयात करता है मानक पुस्तकालय है, जो प्रदान करता है runCommandबैश कोड को चलाने के लिए। हम अपने प्रयोग को चला सकते हैं nix-build run.nix, जिससे एक रास्ता निकल जाएगा /nix/store/1wv437qdjg6j171gjanj5fvg5kxc828p-output.csv।

तो यह हमें क्या खरीदता है? निक्स स्वचालित रूप से एक "स्वच्छ" वातावरण स्थापित करेगा, जिसमें केवल उन चीजों तक पहुंच है जो हमने स्पष्ट रूप से मांगे हैं। विशेष रूप से इसमें $HOMEहमारे द्वारा इंस्टॉल किए गए किसी भी सिस्टम सॉफ़्टवेयर की तरह चर नहीं है । यह परिणाम हमारे वर्तमान मशीन के विवरण से स्वतंत्र बनाता है, जैसे कि ~/.configया हमारे द्वारा स्थापित कार्यक्रमों के संस्करणों की सामग्री ; उर्फ सामान जो अन्य लोगों को हमारे परिणामों की नकल करने से रोकता है! यही कारण है कि मैंने इसे जोड़ा हैcpकमांड, चूंकि परियोजना डिफ़ॉल्ट रूप से सुलभ नहीं होगी। यह कष्टप्रद लग सकता है कि सिस्टम का सॉफ्टवेयर एक Nix स्क्रिप्ट के लिए उपलब्ध नहीं है, लेकिन यह दूसरे तरीके से भी जाता है: हमें किसी स्क्रिप्ट में इसका उपयोग करने के लिए अपने सिस्टम (Nix के अलावा) पर कुछ भी स्थापित करने की आवश्यकता नहीं है; हम सिर्फ इसके लिए पूछते हैं और निक्स बंद हो जाएगा और लाने / संकलन / जो भी आवश्यक है (अधिकांश चीजें बायनेरिज़ के रूप में डाउनलोड की जाएंगी; मानक पुस्तकालय भी बहुत बड़ा है!)। उदाहरण के लिए, यदि हम उन भाषाओं के कुछ विशेष संस्करणों के लिए विशेष रूप से पायथन और हास्केल पैकेज का एक गुच्छा चाहते हैं, तो कुछ अन्य कबाड़ (क्योंकि क्यों नहीं?)।

with import <nixpkgs> {};
runCommand "output.csv"
  {
    buildInputs = [
      gcc49 libjson zlib
      haskell.packages.ghc802.pandoc
      (python34.withPackages (pyPkgs: [
        pyPkgs.beautifulsoup4 pyPkgs.numpy pyPkgs.scipy
        pyPkgs.tensorflowWithoutCuda
      ]))
    ];
  }
  ''
    cp -a ${./.} src
    cd src
    make all
    ./analyse < ./dataset > $out
  ''

वही nix-build run.nixइसे चलाएगा, जो हमने पहले मांगा था (और बाद में हम इसे चाहते हैं, यह सब कैशिंग)। आउटपुट (किसी भी फ़ाइल / निर्देशिका को कहा जाता है $out) निक्स द्वारा संग्रहीत किया जाएगा, जो कि वह पथ है जो इसे बाहर निकालता है। यह उन सभी इनपुटों के क्रिप्टोग्राफ़िक हैश द्वारा पहचाना जाता है जो हमने (स्क्रिप्ट सामग्री, अन्य पैकेज, नाम, संकलक झंडे, आदि) के लिए पूछा; उन अन्य पैकेजों की पहचान उनके इनपुट के हैश द्वारा की जाती है, और इस तरह से कि हमारे पास हर चीज के लिए प्रांत की एक पूरी श्रृंखला है, जीसीसी के संस्करण के ठीक पीछे जो कि जीसीसी के संस्करण को संकलित करता है, जो बाश संकलित करता है, और इसी तरह!

उम्मीद है कि मैंने दिखाया है कि यह हमें वैज्ञानिक कोड के लिए बहुत कुछ खरीदता है, और शुरू करने के लिए यथोचित आसान है। यह वैज्ञानिकों द्वारा बहुत गंभीरता से लेना शुरू कर रहा है, उदाहरण के लिए (शीर्ष Google हिट) https://dl.acm.org/citation.cfm?id=2830172 तो खेती करने के लिए एक मूल्यवान कौशल हो सकता है (बस प्रोग्रामिंग की तरह)

— Warbo
स्रोत

2

बहुत विस्तृत उपयोगी उत्तर - मुझे वास्तव में अन्य उत्तर पसंद हैं, लेकिन दावे बहुत उपयोगी पहले कदम की तरह लगते हैं।

— हीथ

9

पूर्ण-संस्करण संस्करण नियंत्रण + पैकेजिंग + यूनिट परीक्षणों के बिना मानसिकता के (जो कि अच्छी प्रोग्रामिंग प्रथाएं हैं जिन्हें आपको कुछ बिंदु पर प्राप्त करने का प्रयास करना चाहिए) पर जाने के बिना, एक मध्यवर्ती समाधान जो मुझे लगता है कि बृहस्पति नोटबुक का उपयोग करना है । यह वैज्ञानिक संगणना के साथ बेहतर एकीकृत होता है।

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

— मैथियास एटिंगर
स्रोत

1

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

— afaulconbridge

अधिक पढ़ने के इच्छुक व्यक्ति के लिए, इसे साक्षर प्रोग्रामिंग के रूप में भी जाना जाता है।

— जूल

6

शीर्ष उत्तर पहले से ही अच्छे हैं, लेकिन मैं आपके कुछ प्रश्नों को सीधे संबोधित करना चाहता था।

क्या इकाई परीक्षण कोड के छोटे टुकड़ों को लिखने के लिए आवश्यक है?

कोड का आकार सीधे यूनिट परीक्षणों की आवश्यकता से संबंधित नहीं है। यह अप्रत्यक्ष रूप से संबंधित है: इकाई परीक्षण जटिल कोडबेस में अधिक मूल्यवान हैं , और छोटे कोडबेस आमतौर पर बड़े के रूप में जटिल नहीं होते हैं।

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

मान लीजिए कि आपके पास एक एप्लिकेशन है जहां लाइब्रेरी ए संख्याओं के वर्ग का प्रदर्शन करता है, और लाइब्रेरी बी पायथागॉरियन प्रमेय लागू करता है। जाहिर है, बी ए पर निर्भर करता है। आपको पुस्तकालय ए में कुछ ठीक करने की आवश्यकता है, और मान लें कि आप बग को स्थापित करते हैं जो उन्हें स्क्वेर करने के बजाय क्यूब्स संख्या में आते हैं।

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

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

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

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

OOP के बारे में कैसे?

OOP विभिन्न संस्थाओं के बारे में सोचने का एक तरीका है, उदाहरण के लिए:

जब कोई Customerखरीदना चाहता है Product, तो वह Vendorएक प्राप्त करने के लिए बात करता है Order। Accountantइच्छा तो भुगतान Vendor।

इसकी तुलना एक कार्यात्मक प्रोग्रामर चीजों के बारे में कैसे करता है:

जब कोई ग्राहक चाहता है purchaseProduct(), talktoVendor()तो वह sendOrder()उसके पास जाएगा । फिर एक्सीडेंट होगा payVendor()।

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

अधिक बार नहीं, गणितीय और वैज्ञानिक गणना अलग-अलग ऑपरेशन हैं जो अंतर्निहित साझा तर्क / सूत्रों पर भरोसा नहीं करते हैं। उसके कारण, कार्यात्मक प्रोग्रामिंग का उपयोग अक्सर OOP की तुलना में अधिक होता है।

बड़े प्रोजेक्ट पर काम करने के विपरीत "वैज्ञानिक प्रोग्रामिंग" करते समय अच्छे, साफ कोड लिखने के लिए किस तरह के दृष्टिकोण अच्छे हैं?

आपके प्रश्न का तात्पर्य है कि "अच्छा, स्वच्छ कोड" की परिभाषा बदल जाती है चाहे आप वैज्ञानिक प्रोग्रामिंग कर रहे हों या बड़े काम कर रहे हों (मुझे लगता है कि आपका मतलब उद्यम) परियोजनाएं हैं।

अच्छे कोड की परिभाषा नहीं बदलती है। जटिलता से बचने की आवश्यकता (जो कि स्वच्छ कोड लिखकर की जा सकती है), हालांकि, परिवर्तन करती है।

वही तर्क यहाँ वापस आता है।

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

मैं ये सवाल पूछता हूं क्योंकि अक्सर, प्रोग्रामिंग ही सुपर कॉम्प्लेक्स नहीं होती है। यह गणित या विज्ञान के बारे में अधिक है जिसे मैं प्रोग्रामिंग के साथ परीक्षण या शोध कर रहा हूं।

मैं भेद तुम यहाँ कर रहे हैं मिलता है, लेकिन जब आप वापस देखो मौजूदा कोड में, आप दोनों गणित और प्रोग्रामिंग देख रहे हैं। यदि आप या तो वंचित हैं या जटिल हैं, तो आप इसे पढ़ने के लिए संघर्ष करेंगे।

जैसे, क्या एक वर्ग आवश्यक है जब दो चर और एक फ़ंक्शन शायद इसका ख्याल रख सकते हैं?

ओओपी सिद्धांत एक तरफ, मुख्य कारण मैं कुछ डेटा मानों को लिखने के लिए कक्षाएं लिखता हूं, क्योंकि यह विधि मापदंडों और वापसी मूल्यों की घोषणा को सरल करता है। उदाहरण के लिए, यदि मेरे पास बहुत सी विधियाँ हैं जो किसी स्थान (lat / lon pair) का उपयोग करती हैं, तो मैं जल्दी से टाइप करने के लिए थक जाऊँगा float latitude, float longitudeऔर लिखना पसंद करूँगा Location loc।

यह तब और जटिल हो जाता है जब आप समझते हैं कि विधियाँ आम तौर पर एक मान लौटाती हैं (जब तक कि भाषा की विशिष्ट विशेषताएँ अधिक मान लौटाने के लिए मौजूद नहीं होती हैं), और किसी स्थान जैसी चीजें आपको दो मान लौटना चाहती हैं (lat + lon)। यह आपको Locationअपने कोड को सरल बनाने के लिए एक वर्ग बनाने के लिए प्रोत्साहित करता है ।

जैसे, क्या एक वर्ग आवश्यक है जब दो चर और एक फ़ंक्शन शायद इसका ख्याल रख सकते हैं?

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

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

(विचार करें कि ये भी आम तौर पर ऐसी परिस्थितियाँ होती हैं जहाँ कार्यक्रम की गति को तेज़ अंत में पसंद किया जाता है - जब आप किसी अनुकार के 25,000,000+ समय के चरण को चला रहे हों, तो आप चाहते हैं कि यह हो।

एक वर्ग हमेशा अपने क्षेत्रों के योग जितना बड़ा होता है। Locationफिर से उदाहरण लेते हुए , जिसमें दो floatमूल्य शामिल हैं, यहां यह ध्यान रखना महत्वपूर्ण है कि एक एकल Locationवस्तु दो अलग-अलग floatमानों के रूप में अधिक मेमोरी लेगी ।

इस अर्थ में, यह कोई फर्क नहीं पड़ता कि आप OOP का उपयोग कर रहे हैं या नहीं। स्मृति पदचिह्न समान है।

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

इसे इस तरह से सोचें: चाहे मैं अपना केक नुस्खा अंग्रेजी में लिखूं या स्पैनिश इस तथ्य को नहीं बदलता कि केक को बेक होने में 30 मिनट लगेंगे (= रनटाइम प्रदर्शन)। केवल एक चीज जो नुस्खा की भाषा बदलती है, वह यह है कि रसोइये अवयवों को कैसे मिलाते हैं (= बाइटकोड को संकलित करते हैं)।

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

— Flater
स्रोत

6

स्वच्छ वैज्ञानिक संहिता के लाभ

... प्रोग्रामिंग पुस्तकों को देखते हुए, वे अक्सर बड़ी परियोजनाओं में संबोधित किए जाते हैं।

... क्या यह वास्तव में कोड लिखने के लिए समझ में आता है, जिसे ओओपी कहा जाता है जब कुछ मानक सामान किया जा सकता था, लिखने के लिए बहुत तेज़ होता, और कार्यक्रम की कमी के कारण पठनीयता का समान स्तर होता?

भविष्य के कोडर के दृष्टिकोण से अपने कोड पर विचार करने में मददगार हो सकता है।

उन्होंने यह फाइल क्यों खोली?
वे क्या दूंढ़ रहे हैं?

मेरे अनुभव से,

स्वच्छ कोड को आपके परिणामों को सत्यापित करना आसान बनाना चाहिए

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

क्लीन कोड भविष्य के कोडर के लिए उदाहरण कोड के रूप में काम कर सकता है

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

इसके अलावा, अपने एल्गोरिथ्म के लिए एक वास्तविक "एपीआई" बनाने से आप बेहतर तैयार हो सकते हैं यदि आप किसी अन्य का उपयोग करने के लिए अपनी स्क्रिप्ट को एक वास्तविक पुस्तकालय में बनाने का निर्णय लेते हैं।

अनुशंसाएँ

टिप्पणियों का उपयोग करते हुए "सूत्र" गणितीय सूत्र।

गणितीय फ़ार्मुलों को "उद्धृत" करने के लिए टिप्पणियां जोड़ें, खासकर यदि आपने अनुकूलन (ट्रिगर पहचान, टेलर श्रृंखला, आदि) का उपयोग किया।
यदि आपको पुस्तक से सूत्र मिला है John Smith Method from Some Book 1st Ed. Section 1.2.3 Pg 180, तो एक टिप्पणी यह कहते हुए जोड़ें , यदि आपको वेबसाइट पर या किसी पेपर में सूत्र मिला है, तो यह भी उद्धृत करें।
मैं "लिंक केवल" टिप्पणियों से बचने की सलाह दूंगा, यह सुनिश्चित करें कि आप नाम से विधि का उल्लेख कहीं से करें ताकि लोग इसे Google पर भेज सकें, मैंने कुछ "लिंक केवल" टिप्पणियों में चलाए हैं जो पुराने आंतरिक पृष्ठों पर पुनर्निर्देशित हैं और वे बहुत निराशा हो सकती हैं ।
आप अपनी टिप्पणी में सूत्र को टाइप करने का प्रयास कर सकते हैं यदि यूनिकोड / एएससीआईआई में पढ़ना अभी भी आसान है, लेकिन यह बहुत ही अजीब हो सकता है (कोड टिप्पणियाँ LaTeX नहीं हैं)।

टिप्पणियों का बुद्धिमानी से उपयोग करें

यदि आप अच्छे चर नामों / फ़ंक्शन नामों का उपयोग करके अपने कोड की पठनीयता में सुधार कर सकते हैं, तो पहले ऐसा करें। याद रखें कि जब तक आप उन्हें हटा नहीं देते, तब तक टिप्पणियां हमेशा के लिए चिपक जाएँगी, इसलिए ऐसी टिप्पणियां करने की कोशिश करें जो पुरानी नहीं होंगी।

वर्णनात्मक चर नामों का उपयोग करें

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

ज्ञात अच्छे और ज्ञात बुरे डेटा के खिलाफ अपना प्रोग्राम चलाने के लिए कोड लिखें।

क्या इकाई परीक्षण कोड के छोटे टुकड़ों को लिखने के लिए आवश्यक है?

मुझे लगता है कि इकाई परीक्षण सहायक हो सकता है, मुझे लगता है कि वैज्ञानिक कोड के लिए इकाई परीक्षण का सबसे अच्छा रूप परीक्षणों की एक श्रृंखला है जो ज्ञात खराब और अच्छे डेटा पर चलते हैं।

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

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

नए परीक्षण मामलों को जोड़ना आसान बनाएं, "सहायक" कार्यों को जोड़ने पर विचार करें, और अपने इनपुट डेटा को प्रभावी ढंग से संरचना करें। इसका मतलब संभवतः फ़ाइल डेटा को सहेजना है ताकि आप आसानी से परीक्षण फिर से चला सकें, हालांकि झूठी सकारात्मक या पक्षपाती / तुच्छ रूप से हल किए गए परीक्षण मामलों से बचने के लिए बहुत सावधान रहें।

क्रॉस सत्यापन जैसी किसी चीज़ का उपयोग करने पर विचार करें , अधिक जानकारी के लिए क्रॉस पर मान्य इस पोस्ट को देखें।

संस्करण नियंत्रण का उपयोग करें

मैं संस्करण नियंत्रण का उपयोग करने और किसी बाहरी साइट पर आपके भंडार की मेजबानी करने की सलाह दूंगा। ऐसी साइटें हैं जो मुफ्त में रिपॉजिटरी की मेजबानी करेंगी।

लाभ:

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

कोड / कॉपी पेस्ट करते समय सावधानी बरतें

मेरे कोड की शैली जटिल है और कुछ करने के लिए वैकल्पिक तरीकों पर ध्यान देने वाली अप्रचलित टिप्पणियों से भरी हुई है या कोड कॉपी की गई लाइनों के साथ है।

कोड को कॉपी / पेस्ट करना आपके समय को बचा सकता है, लेकिन यह आपके द्वारा की जाने वाली सबसे खतरनाक चीजों में से एक है, खासकर अगर यह कोड है जिसे आपने खुद नहीं लिखा है (जैसे, यदि यह किसी सहकर्मी से कोड है)।
जैसे ही आपको कोड काम करने और जांचने को मिलता है, मैं आपको इसके द्वारा किसी भी चर का नाम बदलने या कुछ भी समझने की सलाह देता हूं।

— jrh
स्रोत

1

यह भी देखें: आप परिणामों की भविष्यवाणी करने के लिए कोड के लिए यूनिट परीक्षण कैसे लिखते हैं?

— जूनियर

6

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

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

तब आपको क्या फायदा होगा?

संस्करण नियंत्रण अच्छा है क्योंकि यह आपको बहुत आसानी से अपने काम का बैकअप लेने की अनुमति देता है। 2018 के रूप में गिथब ऐसा करने के लिए एक बहुत ही लोकप्रिय स्थान है (और आप हमेशा इसे बाद में स्थानांतरित कर सकते हैं यदि आवश्यक हो - गिट बहुत लचीला है)। बैकअप के लिए एक सस्ता और सरल विकल्प आपके ऑपरेटिंग सिस्टम में स्वचालित बैकअप प्रक्रियाएं हैं (मैक के लिए टाइम मशीन, लिनक्स आदि के लिए rsync)। आपका कोड कई स्थानों पर होना चाहिए!
इकाई परीक्षण अच्छे हैं क्योंकि यदि आप उन्हें पहले लिखते हैं तो आप यह सोचने के लिए मजबूर हो जाते हैं कि कोड की वास्तव में जांच कैसे करें, जो आपको अपने कोड के लिए एक अधिक उपयोगी एपीआई डिजाइन करने में मदद करता है। यह तब सहायक होता है जब आप कभी भी बाद में पुन: उपयोग किए जाने के लिए लिखित कोड में आते हैं और एल्गोरिथ्म को बदलते समय आपकी मदद करते हैं क्योंकि आप जानते हैं कि यह इन मामलों पर काम करता है।
प्रलेखन। आपके द्वारा उपयोग की जाने वाली प्रोग्रामिंग भाषा में उचित दस्तावेज लिखना सीखें (उदाहरण के लिए जावा के लिए जावाडॉक)। आप भविष्य के लिए लिखें। इस प्रक्रिया में आप पाएंगे कि अच्छे परिवर्तनशील नाम दस्तावेजीकरण को आसान बनाते हैं। दोहराएं। कविताओं को कविताओं की तरह ही अपने प्रलेखन पर भी ध्यान दें।
अच्छे साधनों का उपयोग करें। एक आईडीई खोजें जो आपकी मदद करे और इसे अच्छी तरह से सीखे। एक बेहतर नाम के लिए वैरिएबल का नाम बदलना इस तरह से आसान है।
यदि आपके पास सहकर्मी हैं, तो सहकर्मी समीक्षा का उपयोग करने पर विचार करें। बाहरी व्यक्ति को देखना और अपने कोड को समझना, आपके द्वारा लिखे गए भविष्य का यहाँ-और-अब का संस्करण है। यदि आपका सहकर्मी आपके कोड को नहीं समझता है, तो आप शायद बाद में भी नहीं होंगे।

— थोरबजोरन रावन एंडरसन
स्रोत

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

— डेविड हैम्मन

5

पहले से ही यहां दी गई अच्छी सलाह के अलावा, आप अपनी प्रोग्रामिंग के उद्देश्य पर विचार करना चाह सकते हैं, और इसलिए आपके लिए क्या महत्वपूर्ण है।

"यह गणित या विज्ञान के बारे में अधिक है जिसे मैं प्रोग्रामिंग के साथ परीक्षण या शोध कर रहा हूं।"

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

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

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

— एडन
स्रोत

5

संस्करण नियंत्रण और इकाई परीक्षण के रूप में महान अपने समग्र कोड को व्यवस्थित और कार्यात्मक रखने के लिए हैं, न तो वास्तव में आप क्लीनर कोड लिखने में मदद करते हैं।

संस्करण नियंत्रण आपको यह देखने की अनुमति देगा कि कोड कब और कैसे गड़बड़ हो गया है।
यूनिट परीक्षण यह सुनिश्चित करेंगे कि कोड पूरी तरह से गड़बड़ होने के बावजूद, यह अभी भी काम करता है।

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

एक लिंटर आपके द्वारा लिखे गए कोड को देखता है, और इसकी तुलना सर्वोत्तम प्रथाओं के विन्यास सेट से करता है। यदि लिंटर में एक नियम है कि चर होना चाहिए camelCase, और आप एक में लिखते हैं snake_case, तो यह एक गलती के रूप में चिह्नित करेगा। अच्छे लिंटर्स के नियम हैं, "घोषित चर का उपयोग किया जाना चाहिए" से लेकर "कार्यों की चक्रीय जटिलता 3 से कम होनी चाहिए"।

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

— माइक गोस्मान
स्रोत

यह बहुत अधिक upvotes होना चाहिए। +1

— हीथ

2

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

— DrMcCleod

4

आपके द्वारा सूचीबद्ध सब कुछ रूपक टूलबॉक्स में एक उपकरण है। जीवन में किसी भी चीज की तरह, अलग-अलग उपकरण विभिन्न कार्यों के लिए उपयुक्त हैं।

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

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

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

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

— क्या नाम है
स्रोत

4

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

मैं कभी-कभी दो या तीन बार टिप्पणियों की कई पंक्तियों के रूप में मैं कोड के रूप में, खासकर जब अवधारणाओं या तकनीक मेरे लिए नए हैं और खुद को समझाते हुए सहन करते हैं।

संस्करण नियंत्रण करें, अपनी प्रथाओं में सुधार करें, आदि .... उपरोक्त सभी। लेकिन अपने आप को चीजों को समझाएं जैसे आप जाते हैं। यह वास्तव में अच्छी तरह से काम करता है।

— बॉब नेवेल
स्रोत

4

इस तरह के कार्यक्रम के लिए कौन से गुण महत्वपूर्ण हैं?

यह शायद कोई फर्क नहीं पड़ता कि इसका आसान रखरखाव या इसे विकसित करना है, क्योंकि संभावना है कि ऐसा होने वाला नहीं है।

यह संभवतः कितना कुशल है, इससे कोई फर्क नहीं पड़ता।

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

यह मामला हो सकता है कि यह पठनीय है: आपके कोड को पढ़ने वाला कोई व्यक्ति आसानी से खुद को समझा सकता है कि यह वही करता है जो यह करने का दावा करता है।

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

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

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

— माइकल के
स्रोत

4

मैंने शिक्षाविदों के साथ एक समान वातावरण में काम किया है जो बहुत सारे (गणित / विज्ञान) कोड लिखते हैं लेकिन उनकी प्रगति उन्हीं कारणों से धीमी होती है जिनका आप वर्णन करते हैं। हालाँकि मैंने एक विशेष बात पर ध्यान दिया है जो मुझे लगता है कि आपकी मदद भी कर सकता है: विशेष पुस्तकालयों के संग्रह का निर्माण और रखरखाव करना जो कि कई परियोजनाओं में इस्तेमाल किए जा सकते हैं। इन पुस्तकालयों को उपयोगिता कार्य प्रदान करना चाहिए और इसलिए यह आपकी वर्तमान परियोजना को समस्या डोमेन के लिए विशिष्ट रखने में मदद करेगा।

उदाहरण के लिए, आपको अपने क्षेत्र (ECEF, NED, lat / lon, WGS84 इत्यादि) में बहुत अधिक समन्वयकारी परिवर्तनों से निपटना पड़ सकता है, इसलिए एक फ़ंक्शन जैसे convert_ecef_to_ned()एक नए प्रोजेक्ट में जाना चाहिए CoordinateTransformations। प्रोजेक्ट को संस्करण नियंत्रण में रखें और इसे अपने विभाग के सर्वर पर होस्ट करें ताकि अन्य लोग इसका उपयोग कर सकें (और उम्मीद है कि इसमें सुधार होगा)। फिर कुछ वर्षों के बाद आपके पास अपनी परियोजनाओं के साथ पुस्तकालयों का एक मजबूत संग्रह होना चाहिए जिसमें केवल एक विशेष समस्या / अनुसंधान डोमेन के लिए विशिष्ट कोड हो।

कुछ और सामान्य सलाह:

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

— Jigglypuff
स्रोत

दूसरे लोगों को इसमें सुधार न करने दें। संभावना है कि वे कोड के उद्देश्य को नहीं समझते हैं और वे सिर्फ चीजों को गड़बड़ करेंगे।

— मैथ्यूडलर

@ मैथ्रेडलर यदि वे सामान्य उपयोगिता पुस्तकालय हैं तो दूसरों के लिए गड़बड़ करना थोड़ा मुश्किल होगा, यह विचार है।

— जिग्लीपफ जूल

सामान्य प्रयोजन पुस्तकालयों को गड़बड़ाना कठिन क्यों है? यह बहुत कठिन नहीं है यदि आपको पता नहीं है कि आप क्या कर रहे हैं, या यदि आप वास्तव में कठिन प्रयास करते हैं, तो उस मामले के लिए।

— मैथडेलर

@ मैथ्रेडलर क्योंकि आम तौर पर रूपांतरण के लिए समन्वय या इकाई रूपांतरण करने का केवल एक ही तरीका है।

— जिग्लीपफ

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

— मैथिल्रेडर

3

निम्नलिखित मेरी राय हैं और मेरे अपने विशेष पथ से बहुत प्रभावित हैं।

कोडिंग अक्सर हठधर्मी दृष्टिकोण को बढ़ाता है कि आपको चीजों को कैसे करना चाहिए। तकनीकों और उपकरणों के बजाय, मुझे लगता है कि आपको उचित रणनीति पर निर्णय लेने के लिए संचयी मूल्यों और लागतों को देखना होगा।

अच्छा, पठनीय, डीबग करने योग्य, ठोस कोड लिखने में बहुत समय और मेहनत लगती है। कई मामलों में, एक सीमित नियोजन क्षितिज को देखते हुए, यह ऐसा करना सार्थक नहीं है (विश्लेषण पक्षाघात)।

एक सहकर्मी के पास अंगूठे का एक नियम था; यदि आप तीसरी बार अनिवार्य रूप से एक ही तरह का काम कर रहे हैं, तो प्रयास करें, अन्यथा एक त्वरित और गंदा काम उचित है।

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

अपनी स्वयं की एक स्क्रिप्ट के लिए (अक्सर किसी संभावना के अनुमान को मान्य करने जैसी चीजों के लिए, या इसी तरह की), मुझे दो छोटी चीजें बहुत उपयोगी लगीं: 1. एक टिप्पणी शामिल करें जिसमें यह दिखाया गया हो कि यह कोड कैसे उपयोग किया जाता है। 2. आपने कोड क्यों लिखा इसका संक्षिप्त विवरण शामिल करें। जब आप कोड लिखते हैं तो ये बातें स्पष्ट रूप से स्पष्ट होती हैं, लेकिन समय के साथ स्पष्टता बर्बाद होती है।

OOP कोड का पुन: उपयोग करने के बारे में है, अमूर्त, encapsulating, फैक्टरिंग, आदि बहुत उपयोगी है, लेकिन खो जाने में आसान अगर गुणवत्ता कोड और डिजाइन का निर्माण करना आपका अंतिम लक्ष्य नहीं है। गुणवत्ता वाले सामान के उत्पादन में समय और मेहनत लगती है।

— copper.hat
स्रोत

3

जबकि मुझे लगता है कि यूनिट परीक्षणों में उनकी खूबियां हैं, वे वैज्ञानिक विकास के लिए संदिग्ध मूल्य के हैं - वे अक्सर बहुत सारे मूल्य देने के लिए बहुत छोटे होते हैं।

लेकिन मुझे वास्तव में वैज्ञानिक कोड के लिए एकीकरण परीक्षण पसंद हैं:

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

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

मैं अक्सर इस तकनीक का उपयोग कर रहा हूं, और अक्सर एक भरोसेमंद पठनीय मुख्य कार्य के साथ समाप्त होता है लेकिन उप-कार्य अक्सर काफी लंबे और बदसूरत होते हैं, लेकिन मजबूत I / O सीमाओं के कारण इसे जल्दी से संशोधित और पुन: व्यवस्थित किया जा सकता है।

— क्रिश्चियन सउर
स्रोत

2

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

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

— user1118321
स्रोत

2

लेखन कोड के साथ - सामान्य रूप में लेखन के साथ - मुख्य सवाल यह है:

आपके मन में कौन सा पाठक है? या आपका कोड कौन खाता है?

औपचारिक कोडिंग दिशानिर्देशों जैसी चीजें आपके पूर्ण दर्शक होने पर कोई मतलब नहीं रखती हैं।

यह कहा जा रहा है, दूसरी तरफ, यह एक तरह से कोड लिखने में मददगार होगा, आपका भविष्य आप इसे तुरंत समझने में सक्षम हैं।

तो एक "अच्छी शैली" एक होगी, जो आपको सबसे अधिक मदद करती है। उस शैली को क्या दिखना चाहिए यह एक ऐसा उत्तर है जो मैं नहीं दे सकता।

मुझे लगता है कि आपको 150 LOC की फाइलों के लिए OOP या Unit परीक्षणों की आवश्यकता नहीं है। एक समर्पित वीसीएस दिलचस्प होगा जब आपके पास कुछ स्पष्ट कोड होंगे। नहीं तो एक .bakचाल है। ये उपकरण एक बीमारी का इलाज हैं, आप भी नहीं कर सकते हैं।

शायद आपको अपना कोड इस तरह से लिखना चाहिए, कि अगर आप नशे में रहते हुए भी इसे पढ़ते हैं, तो भी आप इसे पढ़, समझ और संशोधित कर सकते हैं।

— थॉमस जंक
स्रोत

वैज्ञानिक कोड लिखते समय सफाई से प्रोग्रामिंग करें

अपडेट करें

चर नाम:

अपने कोड को कार्यों में विभाजित करें:

सार्वत्रिक चर:

संस्करण नियंत्रण

स्वच्छ वैज्ञानिक संहिता के लाभ

स्वच्छ कोड को आपके परिणामों को सत्यापित करना आसान बनाना चाहिए

क्लीन कोड भविष्य के कोडर के लिए उदाहरण कोड के रूप में काम कर सकता है

अनुशंसाएँ

टिप्पणियों का उपयोग करते हुए "सूत्र" गणितीय सूत्र।

टिप्पणियों का बुद्धिमानी से उपयोग करें

वर्णनात्मक चर नामों का उपयोग करें

ज्ञात अच्छे और ज्ञात बुरे डेटा के खिलाफ अपना प्रोग्राम चलाने के लिए कोड लिखें।

संस्करण नियंत्रण का उपयोग करें

लाभ:

कोड / कॉपी पेस्ट करते समय सावधानी बरतें