सवाल MATLAB कोड लिखने में अच्छी प्रथाओं? [बन्द है]


मैं एक अच्छी तरह से संरचित कोड लिखने के बुनियादी सिद्धांतों और शिष्टाचार को जानना चाहता हूं।


44
2017-08-30 20:09


मूल


महत्वपूर्ण बात यह है कि आप अपनी समस्या को सरल, प्रबंधनीय भागों में विघटित करते हैं, और इन भागों में जितना संभव हो उतना अंतःविषयता है। ऑब्जेक्ट उन्मुख प्रोग्रामिंग इसके साथ मदद कर सकता है, जैसा कि अन्य तरीकों से हो सकता है। मैं कोड पूर्ण करने की भी सिफारिश करता हूं, यह मानते हुए कि आप बड़ी परियोजनाओं को विकसित करना जारी रखेंगे। - Seamus Connor
@ सेमस: कार्यात्मक प्रोग्रामिंग एक बेहतर उदाहरण होगा। यह अपने तार्किक निष्कर्ष पर अपघटन लेता है। - Clark Gaebel
@ हरप्रीत: ज़रूर। कल्पना कीजिए कि आपने अपनी समस्या को छोटे हिस्सों में विभाजित कर दिया है और कोडिंग शुरू कर दी है। आप उस बिंदु तक पहुंचते हैं जब आपको किसी ऐसे फ़ंक्शन की आवश्यकता होती है जिसे आपने पहले से ही किसी अन्य "भागों" में लिखा है, इसलिए आप केवल नए कोड से फ़ंक्शन को कॉल करते हैं। आपने ऐसा करके एक अंतःक्रियात्मकता बनाई है क्योंकि जब आप वापस जाते हैं और बग को ठीक करने या सुविधा जोड़ने के लिए पहले "भाग" को बदलते हैं, तो अब आपको अवगत होना चाहिए कि मनमानी स्थान में अन्य कोड इस पर निर्भर करता है, और आपके पास परिवर्तन हैं आपके कोड में एक मनमानी स्थान में एक नई बग बनाने का मौका। - Seamus Connor
@ हरप्रीत: बेशक, पूरी तरह से अंतःविषय से परहेज करना असंभव है, इसलिए आपको उन्हें तार्किक तरीके से प्रबंधित करने की आवश्यकता है। ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग में, आपको बस ऐसा करने के लिए टूल प्रदान किए जाते हैं। कक्षाएं और इंटरफेस दो बहुत ही महत्वपूर्ण अवधारणाएं हैं। एक वर्ग आपको लॉजिकल मॉड्यूल में कार्यक्षमता (विधियों) और राज्य (सदस्य चर) को समूहबद्ध करने की अनुमति देता है। एक बार ऐसा करने के बाद, आप एक इंटरफ़ेस का उपयोग करके अंतःविषयताओं को "रूपरेखा" कर सकते हैं, जो मूल रूप से एक अनुबंध है जो कक्षा करता है। - Seamus Connor
@ हरप्रीत: प्रोग्रामिंग भाषाओं की कई अलग-अलग शैलियों भी हैं, जिनमें से सभी लाभ प्रदान करते हैं। ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग सिर्फ एक प्रोग्रामिंग मॉडल है, और यह सभी समस्याओं का उत्तर नहीं है। क्लार्क गेबेल ने कार्यात्मक प्रोग्रामिंग का उल्लेख किया है, जो एक और प्रतिमान है जो सॉफ्टवेयर इंजीनियरिंग समस्याओं के समाधान प्रदान करता है। दुर्भाग्य से, MATLAB में कार्यात्मक प्रोग्रामिंग उपलब्ध नहीं है और पायथन में एक उन्नत विषय है। - Seamus Connor


जवाब:


जब आप कोड लिख रहे हों तो ये ध्यान में रखना सबसे महत्वपूर्ण दो चीजें हैं:

  1. कोड लिखो जो आपने पहले ही लिखा है।
  2. वह कोड न लिखें जिसे आपको लिखने की आवश्यकता नहीं है।

21
2017-08-30 21:31





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


34
2017-08-30 20:11



कोड पूर्ण की मेरी प्रति गायब हो गई! सब खो दिया है! - Seamus Connor
मैं कोड पूर्ण की मेरी प्रतिलिपि wub। तुम्हारा खोना कितना दुखद बात है! डी: - Ashley Grenon
आह - स्टीव मैककोनेल। वह किताब पुरानी स्कूल है लेकिन अभी भी बहुत प्रासंगिक है! उनकी एक और अच्छी किताब 'रैपिड डेवलपमेंट' है - Dan Esparza
@ डैन एस्परजा - ओह हाँ, रैपिड डेवलपमेंट ने जिस तरीके से देखा, उसमें से एक समूह के लिए काम पर कैसे चल रहा था, जिनके सदस्य मैं हूं। तब से हमारे पास नए प्रबंधक हैं लेकिन क्लासिक गलतियों की संख्या ... कौन लड़का! - wheaties
@Dan - दूसरा संस्करण अच्छा है, अपडेट किया गया। यदि आपके पास पहला संस्करण है तो पढ़ने की कोई ज़रूरत नहीं है। - Marc


MATLAB प्रोग्रामिंग शैली दिशानिर्देश रिचर्ड जॉनसन द्वारा एक अच्छा संसाधन है।


17
2017-08-30 21:40





खैर, अगर आप इसे आम आदमी के नियमों में चाहते हैं:

मैं लोगों को लिखने के लिए reccomend काम करता है कि सबसे छोटा पठनीय कार्यक्रम

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


15
2017-08-30 21:28



उत्कृष्ट सलाह। या तो चरम (verbosity या terseness) कोड पढ़ने के लिए मुश्किल बनाता है। जावा और पर्ल प्रोग्रामर इसे समझने से इनकार करते हैं। - dsimcha
मुझे वह सुझाव पसंद है। यह एक बहुत अच्छा मुद्दा है, हालांकि इसे वास्तव में एक कोड लिखते समय इसे पालन करने के लिए ध्यान में रखा जाना चाहिए क्योंकि इसकी तुलना में आसान सुनना आसान है।
मैं इसे पठनीय लघु कार्यक्रम के काम में बदलने के लिए बदलूंगा :) पठनीय से काम करना अधिक महत्वपूर्ण है, जो कि कम से कम महत्वपूर्ण है। +1 हालांकि। - Billy ONeal
@ बिली ओनेल: लेकिन फिर यह अंग्रेजी काम नहीं करेगा। - intuited
@intuited: शायद, लेकिन यह और अधिक सही होगा :) - Billy ONeal


यह सूची लंबे समय तक चल सकती है लेकिन कुछ प्रमुख चीजें हैं:

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

शुरू करने के लिए दो अच्छी जगहें:

स्वच्छ कोड हैंडबुक

कोड: पूर्ण


7
2017-08-30 20:14



उनका उपयोग न करें - अधिकांश मामलों में, वे काफी अनावश्यक हैं। - Puppy
@DeadMG: मुझे आशा है कि इसका मतलब है कि आपको कक्षाओं को लागू करना चाहिए ताकि गेटर्स और सेटर्स अनावश्यक हों, इसके बजाय आपको डेटा सदस्यों को क्लाइंट कोड में बेनकाब करना चाहिए। - Billy ONeal
इस बात से सहमत हैं कि बहुत से लोग निजी सूची की तरह सामान करके अनावश्यक चीजें करते हैं, फिर उस पर एक प्राप्त / सेट करें। वास्तव में अच्छे गेटर्स / बसने वालों को डिजाइन करने के लिए एक कला है। - Luke Belbina
@ बिली: सार्वजनिक सदस्य चर के अर्थ होने पर बहुत सारे मामले हैं। यदि आप एक सदस्य चर के लिए गेटर और एक सेटटर लिखते हैं, तो आपने वास्तव में यह सोचने के बिना ओओ को होंठ सेवा की है कि यह कैसे किया जा रहा है। - Puppy
@DeadMG: अगले सप्ताह तक आप एक चर का उपयोग करने के बजाय मूल्य की गणना करने का निर्णय लेते हैं, और आपके सभी ग्राहकों को संशोधित और पुन: संकलित करने की आवश्यकता होती है। (हालांकि मैं सामान्य रूप से सहमत हूं कि प्रत्येक चर के पास गेटर / सेटर नहीं होना चाहिए, अगर यह ऐसी स्थिति में है जहां इसे सार्वजनिक चर की तरह कार्य करना है, तो उसे फ़ील्ड को उजागर करने के बजाय गेटर्स और सेटर्स होना चाहिए। - Billy ONeal


यदि आप संदर्भ या शिष्टाचार के रूप में कुछ उपयोग करना चाहते हैं, तो मैं अक्सर जो भी भाषा काम कर रहा हूं, उसके लिए मैं आधिकारिक Google स्टाइल सम्मेलनों का पालन करता हूं, जैसे कि सी ++ या के लिए अजगर

प्रोग्रामिंग का अभ्यास रॉब पाइक और ब्रायन डब्ल्यू। केर्निगन द्वारा शैली पर एक अनुभाग भी है जो मुझे सहायक पाया।


5
2017-08-30 20:22



Google शैली सम्मेलन सी ++ में अपवादों के उपयोग को रोकते हैं और कुछ परिस्थितियों में चर पारित करने के लिए कुछ हद तक अलग नियमों का प्रस्ताव भी देते हैं। मैं उन्हें अत्यधिक अनुशंसा नहीं करता। - Omnifarious
केर्निगन और पाइक के लिए +1! - J. Polfer


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

-

अच्छा स्रोत कोड लिखना:

  1. अपना कोड टिप्पणी करें।
  2. कई अक्षरों से अधिक परिवर्तनीय नामों का प्रयोग करें। 5 और 20 के बीच अंगूठे का एक अच्छा नियम है।
  3. कोड की छोटी रेखाएं बेहतर नहीं हैं - व्हाइटस्पेस का उपयोग करें।
  4. अपने कोड के साथ "चालाक" होने के नाते बाद में या किसी अन्य व्यक्ति को भ्रमित करने का एक अच्छा तरीका है।
  5. समस्या को अपने घटकों में विघटित करें और समाधान को इकट्ठा करने के लिए पदानुक्रमित डिज़ाइन का उपयोग करें।
  6. याद रखें कि आपको बाद में अपना प्रोग्राम बदलना होगा।
  7. अपना कोड टिप्पणी करें।

कंप्यूटर प्रोग्रामिंग में कई fads हैं। उनके समर्थक उन लोगों पर विचार करते हैं जो फड को अनजान नहीं कर रहे हैं और बहुत कुछ नहीं। वर्तमान प्रमुख fads "टेस्ट संचालित विकास" और "Agile" प्रतीत होता है। 1 99 0 के दशक में फड 'ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग' था। विचारों के उपयोगी कोर भागों को जानें जो आसपास आते हैं, लेकिन डॉगमैटिक न हों और याद रखें कि सबसे अच्छा कार्यक्रम वह है जो काम करने की ज़रूरत है।

बहुत मेरे सिर के ऊपर से अधिक संघनित कोड का मामूली उदाहरण

for(int i=0,j=i; i<10 && j!=100;i++){
     if i==j return i*j; 
     else j*=2;
}}

जबकि यह अधिक पठनीय है:

int j = 0;
for(int i = 0; i < 10; i++)
{
   if i == j 
   {
      return i * j;
   }
   else
   { 
     j *= 2;
     if(j == 100)
     {
        break;
     }
   }
}

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

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

यही वह सार है जो अन्य पोस्टर ने व्यक्त करने की कोशिश की - कार्यक्रम की आवश्यकता से अधिक समय तक नहीं बनें। लंबे समय के दो अर्थ हैं: कोड की अधिक रेखाएं (यानी, अपनी रेखा पर ब्रेसिज़ डालने), और अधिक जटिल। एक कार्यक्रम को आवश्यकता से अधिक जटिल बनाना अच्छा नहीं है। इसे और अधिक पठनीय बनाना अच्छा है।


5
2017-08-30 21:52



@ हरप्रीत: संपादन देखें। - Paul Nathan
@ पॉल नाथन: आपने दो बार "अपना कोड टिप्पणी" सूचीबद्ध किया है। टिप्पणी करना महत्वपूर्ण है, लेकिन यह भी महत्वपूर्ण है कि इसे अधिक न करें। किसी को आमतौर पर 'क्या' कोड नहीं करना चाहिए - यह कोड से स्पष्ट होना चाहिए; यदि यह स्पष्ट नहीं है, तो यह अक्सर एक संकेत है कि कोड को और अधिक स्पष्ट रूप से लिखा जाना चाहिए। टिप्पणियाँ 'क्यों' कोड कुछ कर रही है, या कोड क्या कर रहा है पर ध्यान केंद्रित करना चाहिए। एक टिप्पणी जैसे "ए + = 5; / * 4 * ए / * में जोड़ें, पठनीयता में सुधार नहीं करता है Iota। - supercat
@supercat: कोड स्वयं टिप्पणी नहीं है। यह कमजोर पड़ने से ज्यादा बेहतर है। - Paul Nathan
@ हरप्रीत टिप्पणी नहीं करते कि कौन सा कोड कहता है लेकिन क्या नहीं कह सकता। - systempuntoout
मुझे पहला उदाहरण बहुत स्पष्ट लगता है। अगर मुझे कोड की 10 लाइनें दिखाई देती हैं, तो मुझे उम्मीद है कि यह कुछ जटिल हो जाएगा। - intuited