क्या सामान्य कोडिंग मानकों की अनदेखी करने के लिए वैज्ञानिक कोड एक अलग पर्याप्त क्षेत्र है?


21

हाल ही में मैं निम्नलिखित तथ्य के बारे में अपने दिमाग को लपेटने की कोशिश कर रहा हूं।

एक तरफ, कोड को "स्वस्थ", "स्वच्छ", "अच्छी तरह से लिखा" और इतने पर कोड माना जाता है के लिए दिशानिर्देश और मानकों का एक मेजबान है। "क्लीन कोड" देखें जो यहाँ भी व्यापक रूप से चर्चा में दिखाई देता है। उदाहरण नियम: 7 लाइन लंबी विधियाँ और 1 या 2 स्तर का इंडेंटेशन। कोड जो पालन नहीं करता है वह किसी भी तरह से खराब रखरखाव से मरने की उम्मीद करता है।

दूसरी ओर, मुझे OpenCV, OpenCascade, VTK, आदि के साथ काम करना है, यह वैज्ञानिक कोड है। उनके पास 2 पृष्ठ लंबी विधियाँ हैं (स्वयं सेन), ओपनकैस्केड में एक विधि है या 10 फ़ाइलों में विभाजित है (यहां कोई चुटकुले नहीं), वीटीके कई बार गड़बड़ है। फिर भी ये परियोजनाएं समृद्ध हैं, कायम हैं और व्यापक रूप से उपयोग की जाती हैं!

पकड़ कहां है? क्या हमें वैज्ञानिक, गणित-भारी कोड लिखने की अनुमति है कि यह सिर्फ काम करता है, और हम इसे बनाए रख सकते हैं? क्या आप ऐसी परियोजनाओं के लिए मानकों का एक अलग सेट है, यदि कोई हो?

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


25
नहीं, यह नहीं है, लेकिन अधिकांश वैज्ञानिकों के पास बेहतर जानने के लिए इंजीनियरिंग प्रशिक्षण नहीं है।
रोबोट

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

2
@JustinCaveL या: "यदि यह नहीं टूटा है, तो इसे ठीक न करें।" विशेष रूप से केवल-लिखने के लिए लागू होता है । यह भी देखें plaza.ufl.edu/johnaris/PDFs/ProblemSolveFlowChart.pdf
रॉबर्ट हार्वे

आप निश्चित रूप से मेरे पहले के प्रश्न को प्रासंगिक पाएंगे: प्रोग्रामर.स्टैकएक्सचेंज.
com

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

जवाबों:


28

क्या सामान्य कोडिंग मानकों की अनदेखी करने के लिए वैज्ञानिक कोड एक अलग पर्याप्त क्षेत्र है?

नहीं यह नहीं।

अनुसंधान कोड अक्सर "फेंक दिया जाता है" और ऐसे लोगों द्वारा लिखा जाता है जो पृष्ठभूमि से डेवलपर्स नहीं हैं, हालांकि उनकी शैक्षणिक साख को मजबूत करते हैं। मेरे द्वारा लिखे गए कुछ शोध कोड मुझे वर्तमान में रुला देते हैं । लेकिन यह काम किया!

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

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

यह और भी मुश्किल है अगर वह सभी कोड काम करता है। क्योंकि यह टूटा नहीं है। इसे ठीक क्यों करें?

फिर भी ये परियोजनाएं समृद्ध हैं, कायम हैं और व्यापक रूप से उपयोग की जाती हैं!

यह एक अर्थ में, उत्तर है। कार्य कोड अभी भी उपयोगी है और इसलिए इसे बनाए रखने की अधिक संभावना है।

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

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

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

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

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

वास्तविकता यह है कि कई परियोजनाएं शुरू होती हैं और मर जाती हैं। ओपनसीवी या वीटीके आदि के स्तर पर "इसे" बनाते हुए हास्यास्पद रूप से छोटे प्रतिशत

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

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

मुझे यह भी इंगित करना चाहिए कि ओपनसीवी एजाइल मेनिफेस्टो से पहले कई वर्षों के लिए आसपास था कि क्लीन कोड से प्रेरणा मिलती थी (और वीटीके लगभग 10)। VTK को क्लीन कोड के प्रकाशन से 17 साल पहले शुरू किया गया था (OpenCV "केवल" 9 साल पहले) था।


2
मैं 2004 में OpenCV का उपयोग कर रहा था और यह बहुत ही भयानक था। विलो गैराज (नए मालिकों ) ने लगभग सब कुछ सी ++ में परिवर्तित करके एक महान काम किया। वास्तव में यह कुछ वैज्ञानिक पुस्तकालयों में से एक है जिसमें अच्छे कोड होते हैं।
निकम्मा हुआ

15

वैज्ञानिक डेवलपर नहीं हैं। उनका काम प्रति सेड लिखना नहीं है। उनका काम समस्याओं को हल करना है, और प्रोग्रामिंग सिर्फ एक उपकरण है जिसका वे उपयोग कर सकते हैं।

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

क्या एक वास्तविक पेशेवर डेवलपर अपने करियर के दौरान एक वैज्ञानिक को लाभान्वित करता है? पूर्ण रूप से। क्या हर वैज्ञानिक के लिए अपने जीवन के पांच से दस साल सॉफ्टवेयर डेवलपमेंट पर खर्च करना संभव होगा? शायद ऩही। इसलिए, कोड की गुणवत्ता जैसा है वैसा ही है।

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

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


"उनका काम प्रति सेड कोड लिखना नहीं है। उनका काम समस्याओं को हल करना है" - ध्यान दें कि तकनीकी रूप से एक डेवलपर का काम कोड लिखना भी नहीं है। उसकी / उसकी नौकरी, वैज्ञानिक की तरह, समस्याओं को हल करने के लिए है। मैं सॉफ्टवेयर फैक्ट्रियों और कोड बंदरों को छोड़ रहा हूं, जिन्हें कुर्सियों को गर्म रखने के लिए भुगतान किया जाता है, लेकिन परिभाषा के अनुसार वे साफ कोड के बारे में ज्यादा परवाह नहीं करते हैं, इसलिए वे इस सवाल के लिए प्रासंगिक नहीं हैं :)
एंड्रेस एफ।

8

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

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


4
चर नामकरण टिप्पणी के लिए +1। जब मैं स्कूल में था तब मैंने विभिन्न विभागों के लिए कुछ फ्रीलांस कोडिंग की थी, और स्टेट और गणित विभागों में मुझे "दृढ़ता से प्रोत्साहित" किया गया था जैसे कि चर नामों का उपयोग करना Ajऔर T0क्योंकि जिस तरह से चर को नाम दिया गया था, मैं कोड में अनुवाद कर रहा था। जैसे कुछ का उपयोग कर correlationIndexया startTimeआप पर grumbled मिल जाएगा।
टीएमएन

4

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

सामान्य तौर पर, वहाँ के लिए स्रोत कोड KISS होने के लिए व्यापार लाभ का एक बहुत कुछ है - "। यह सरल बेवकूफ रखने के लिए," एक संबंधित YAGNI भी है - "यू आर नॉट गॉन नीड इट"।

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


परंपरागत रूप से, ओपनसीवी सामान्यीकरण (विभिन्न विकल्पों का समर्थन करने के लिए कोड दोहराव की बहुत कमी) से पीड़ित था, जबकि वीटीके अत्यधिक सामान्यीकरण (टेम्पलेट) से पीड़ित था।

शुरुआती दिनों में, OpenCV के कुछ हिस्सों को मूल रूप से C. बाद में विकसित किया गया था, OpenCV ने C ++ API को अपनाया जिसे आज हम परिचित हैं। कुछ एल्गोरिदम को C ++ इंटरफेस (अमूर्त बेस क्लास) और C ++ टेम्प्लेट का लाभ लेने के लिए फिर से लिखा गया है। अन्य एल्गोरिदम मूल सी कोड के लिए बस रैपर थे। इन कोड के अवशेषों को "imgproc" मॉड्यूल में चारों ओर बिखरे हुए पाया जा सकता है।

OpenCV में बहुत सारे SIMD प्रोग्रामिंग (वैश्वीकरण) हैं। इस तिथि, सी में SIMD प्रोग्रामिंग करने के लिए ++ अभी भी के उपयोग की आवश्यकता intrinsics (intel.com) , (arm.com)

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

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


नीचे विचारों की एक लंबी सूची है जब मैं विश्लेषण करने के लिए क्यों कम्प्यूटेशनल सॉफ्टवेयर KISS या YAGNI नहीं किया जा सकता की कोशिश है। हालांकि, ये सभी विचार अति-सामान्यीकरण हैं, और वे उपरोक्त अवलोकन का समर्थन नहीं करते हैं।

मुख्य योगदान कारक हैं:

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

उपर्युक्त योगदान कारकों में से कई व्यवसाय सॉफ्टवेयर विकास के साथ एंटीपोड हैं :

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

1
आप तालिका में बहुत सारे बिंदु ला रहे हैं जो सभी प्रश्न के लिए काफी अप्रासंगिक लगते हैं।
मार्टिन माट

@MartinMaat यदि आपके पास इस प्रश्न को जोड़ने के लिए सकारात्मक बातें हैं, तो कृपया अपने उत्तर में लिखें।
रवांग

3

क्या सामान्य कोडिंग मानकों की अनदेखी करने के लिए वैज्ञानिक कोड एक अलग पर्याप्त क्षेत्र है?

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

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


2
"फुर्तीली" कोडिंग मानकों के साथ कुछ भी नहीं है।
रोबोट

@StevenBurnap - निश्चित रूप से यह करता है। "क्लीन कोड" देखें। इसमें कोडिंग मानकों के oodles हैं।
डेविड हैमेन ने

1
बहुत सारे कोडिंग मानकों वाले स्वच्छ कोड एक बुरा तर्क है। एजाइल मैनिफेस्टो का कोडिंग मानकों से कोई लेना-देना नहीं हो सकता है, लेकिन एजाइल लचीलेपन को बढ़ावा देता है और कोडिंग मानकों को बदलने और चिपकाने या सर्वोत्तम प्रथाओं का समर्थन करता है। इसलिए - एक बहुत ही अप्रत्यक्ष और चौकस तरीके से फुर्तीले का कोडिंग मानकों से कोई लेना-देना नहीं हो सकता है, लेकिन कोडिंग मानक का चुस्त से बहुत कुछ होता है।
मार्जन वेनमा

1

मैंने इसे एक नए उत्तर के रूप में पोस्ट करने का फैसला किया क्योंकि यह पूरी तरह से अलग परिप्रेक्ष्य है।

आइए एक कोड नमूने पर नज़र डालें, जिसे मैं कंप्यूटर विज़न और छवि समझ के मामले में "क्लीन कोड" मानता हूं:

https://github.com/opencv/opencv/blob/05b15943d6a42c99e5f921b7dbaa8323f3c042c6/modules/photo/src/seamless_cloning_impl.cpp

MATLAB और वैज्ञानिक कंप्यूटिंग से परिचित लोगों के लिए, C ++ में कोड लगभग साफ-सुथरे MATLAB कोड के रूप में संक्षिप्त है।


अब हमें यह पूछना है कि पूरे पुस्तकालय कोड आधार (इस उदाहरण में OpenCV) को इस कोड नमूने के समान मानक के लिए क्यों नहीं लिखा गया है?


हम चाहिए विभक्त हो जाना में एक बड़ी वैज्ञानिक पुस्तकालय के कोड बेस अमूर्त स्तरों

पर निम्न स्तर , आप फिर से लागू करने परिवर्धन और subtractions सचमुच कर रहे हैं। या, प्रत्येक प्लेटफ़ॉर्म पर सबसे तेज़ कार्यान्वयन के लिए प्रत्येक ऑपरेशन का शाब्दिक पुन: मानचित्रण।

https://github.com/opencv/opencv/blob/master/modules/core/src/hal_replacement.hpp

मध्य स्तर सीपीयू निष्पादन समय का 90% खर्च किया जाता है - जहां हम "गंदे" कोड है, जो भीतर हो सकता है 80% लगता है। (इसी प्रकार, शायद spent०% - ९ ०% विकास के प्रयास मध्य-स्तर में बिताए गए थे, अगर हम वैज्ञानिक अनुसंधान से अलग सॉफ्टवेयर विकास के प्रयासों को गिनें।)

पर उच्च स्तर , हम साफ कोड, शोधकर्ताओं ने लिखा है।


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

उदाहरण के लिए, कभी-कभी एक ओपन-सोर्स प्रोजेक्ट को दो में विभाजित करने का निर्णय लिया जाता है। आप कोड कमिट द्वारा इन चीजों को नहीं कर सकते।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.