जटिल कोड आधारों में, साइड इफेक्ट्स के जटिल इंटरैक्शन सबसे कठिन बात हैं जिनके बारे में मुझे लगता है। मैं केवल अपने मस्तिष्क के काम करने के तरीके को व्यक्तिगत रूप से बोल सकता हूं। साइड इफेक्ट्स और लगातार स्थिति और म्यूटिंग इनपुट्स और इसी तरह मुझे "जब" और "जहां" के बारे में सोचना पड़ता है कि क्या चीजें सही होने के कारण होती हैं, न कि प्रत्येक व्यक्तिगत फ़ंक्शन में "क्या" हो रहा है।
मैं सिर्फ "क्या" पर ध्यान केंद्रित नहीं कर सकता। मैं किसी फ़ंक्शन का पूरी तरह से परीक्षण करने के बाद निष्कर्ष नहीं निकाल सकता हूं जो साइड इफेक्ट्स का कारण बनता है कि यह उपयोग करने वाले कोड में विश्वसनीयता की एक हवा फैलाएगा, क्योंकि कॉलर्स गलत समय पर गलत थ्रेड से गलत तरीके से कॉल करके इसका दुरुपयोग कर सकते हैं। गण। इस बीच एक ऐसा फ़ंक्शन जिसके कारण कोई साइड इफेक्ट नहीं होता है और बस एक नया आउटपुट देता है एक इनपुट दिया (इनपुट को छुए बिना) इस तरह से दुरुपयोग करना बहुत असंभव है।
लेकिन मैं एक व्यावहारिक प्रकार हूं, मुझे लगता है, या कम से कम होने की कोशिश करो, और मुझे नहीं लगता कि हमारे पास हमारे कोड की शुद्धता के बारे में तर्क करने के लिए न्यूनतम न्यूनतम करने के लिए सभी साइड इफेक्ट्स पर मुहर लगाना जरूरी है (बहुत कम से कम मुझे C) जैसी भाषाओं में ऐसा करना बहुत मुश्किल होगा। जहां मुझे शुद्धता के बारे में तर्क करना बहुत मुश्किल लगता है, जब हमारे पास जटिल नियंत्रण प्रवाह और दुष्प्रभावों का संयोजन होता है।
कॉम्प्लेक्स कंट्रोल फ्लो मेरे लिए ऐसे हैं जो प्रकृति में ग्राफ-जैसे होते हैं, अक्सर पुनरावर्ती या पुनरावर्ती-जैसे (घटना कतार, उदाहरण के लिए, जो सीधे घटनाओं को पुनरावर्ती नहीं कह रहे हैं, लेकिन प्रकृति में "पुनरावर्ती-जैसे" हैं), शायद चीजें कर रहे हैं एक वास्तविक लिंक्ड ग्राफ़ संरचना को ट्रेस करने की प्रक्रिया में, या एक गैर-सजातीय ईवेंट कतार को संसाधित करना जिसमें घटनाओं का एक उदार मिश्रण होता है जो हमें कोडबेस के सभी भागों और सभी विभिन्न दुष्प्रभावों को ट्रिगर करने के लिए अग्रणी बनाता है। यदि आपने उन सभी स्थानों को बाहर निकालने की कोशिश की है जो आप अंततः कोड में समाप्त करेंगे, तो यह एक जटिल ग्राफ जैसा होगा और संभावित रूप से ग्राफ़ में नोड्स के साथ जो आपको कभी भी उम्मीद नहीं थी कि उस दिए गए क्षण में होगा, और यह देखते हुए कि वे सभी हैं दुष्प्रभाव का कारण,
कार्यात्मक भाषाओं में बेहद जटिल और पुनरावर्ती नियंत्रण प्रवाह हो सकता है, लेकिन परिणाम शुद्धता के संदर्भ में समझना इतना आसान है क्योंकि प्रक्रिया में सभी प्रकार के पारिस्थितिक दुष्प्रभाव नहीं हैं। यह केवल तभी होता है जब जटिल नियंत्रण प्रवाह परिलक्षित होता है, जो मुझे लगता है कि यह सिरदर्द-उत्प्रेरण जो कि चल रहा है और क्या यह हमेशा सही काम करेगा, की संपूर्णता को समझने की कोशिश करता है।
इसलिए जब मेरे पास ऐसे मामले होते हैं, तो मुझे अक्सर यह बहुत मुश्किल लगता है, अगर असंभव नहीं है, तो इस तरह के कोड की शुद्धता के बारे में बहुत आश्वस्त महसूस करने के लिए, अकेले बहुत आत्मविश्वास से बताएं कि मैं किसी अप्रत्याशित चीज पर ट्रिप किए बिना ऐसे कोड में बदलाव कर सकता हूं। तो मेरे लिए इसका समाधान या तो नियंत्रण के प्रवाह को सरल बनाना है या साइड इफेक्ट्स को कम से कम करना / एकजुट करना है (एकीकृत करके, मेरा मतलब है कि सिस्टम में एक विशेष चरण के दौरान कई चीजों के लिए केवल एक प्रकार का दुष्प्रभाव होता है, दो या तीन या एक नहीं दर्जन)। मुझे उन दो चीजों में से एक की आवश्यकता है जो मेरे सिंपल ब्रेन को मौजूद कोड की शुद्धता और मेरे द्वारा किए गए परिवर्तनों की शुद्धता के बारे में आश्वस्त महसूस करने की अनुमति दें। यह बहुत आसान है कि साइड इफेक्ट्स को लागू करने वाले कोड की शुद्धता के बारे में आश्वस्त रहें यदि साइड इफेक्ट समान और सरल हैं, तो नियंत्रण प्रवाह के साथ, जैसे:
for each pixel in an image:
make it red
इस तरह के कोड की शुद्धता के बारे में तर्क करना बहुत आसान है, लेकिन मुख्य रूप से क्योंकि दुष्प्रभाव इतने समान हैं और नियंत्रण प्रवाह इतना आसान है। लेकिन मान लें कि हमारे पास इस तरह का कोड था:
for each vertex to remove in a mesh:
start removing vertex from connected edges():
start removing connected edges from connected faces():
rebuild connected faces excluding edges to remove():
if face has less than 3 edges:
remove face
remove edge
remove vertex
फिर यह हास्यास्पद रूप से स्यूडोकोड है, जिसमें आमतौर पर अधिक कार्य और नेस्टेड लूप शामिल होते हैं और बहुत सी चीजें होती हैं, जिन पर चलना होता है (कई बनावट के नक्शे, हड्डी के वजन, चयन की स्थिति, आदि) को अपडेट करना, लेकिन यहां तक कि स्यूडोकोड भी मुश्किल बना देता है। शुद्धता के बारे में कारण जटिल ग्राफ की तरह नियंत्रण प्रवाह और साइड इफेक्ट के चल रहे हैं। तो एक रणनीति है कि प्रसंस्करण को स्थगित करना और एक समय में एक प्रकार के दुष्प्रभावों पर ध्यान केंद्रित करना है:
for each vertex to remove:
mark connected edges
for each marked edge:
mark connected faces
for each marked face:
remove marked edges from face
if num_edges < 3:
remove face
for each marked edge:
remove edge
for each vertex to remove:
remove vertex
... सरलीकरण के एक पुनरावृत्ति के रूप में इस आशय के लिए कुछ। इसका मतलब है कि हम कई बार डेटा से गुजर रहे हैं, जो निश्चित रूप से एक कम्प्यूटेशनल लागत लगा रहा है, लेकिन हम अक्सर पाते हैं कि हम इस तरह के परिणामी कोड को अधिक आसानी से गुणा कर सकते हैं, अब यह समान और सरल प्रकृति पर दुष्प्रभाव और नियंत्रण प्रवाह ले लिया है। इसके अलावा प्रत्येक लूप को जुड़े हुए ग्राफ को ट्रेस करने और साइड इफेक्ट के कारण अधिक कैश-फ्रेंडली बनाया जा सकता है, क्योंकि हम जाते हैं (उदाहरण: एक समानांतर बिट सेट का उपयोग करें जो ट्रैवर्स किए जाने की आवश्यकता है ताकि हम फिर क्रमबद्ध क्रमबद्ध क्रम में आस्थगित पास कर सकें। बिटमास्क और एफएफएस का उपयोग करना)। लेकिन सबसे महत्वपूर्ण बात यह है कि मुझे दूसरा संस्करण इतना आसान लगता है कि शुद्धता के मामले में बगैर किसी कारण के बगैर बदलाव के कारण आसान हो जाता है। इसलिए कि'
और आखिरकार, हमें कुछ बिंदुओं पर होने वाले साइड इफेक्ट्स की आवश्यकता होती है, या फिर हमारे पास केवल ऐसे फ़ंक्शन होते हैं जो आउटपुट डेटा के साथ कहीं नहीं जाते हैं। अक्सर हमें किसी फ़ाइल में कुछ रिकॉर्ड करने, स्क्रीन पर कुछ प्रदर्शित करने, सॉकेट के माध्यम से डेटा भेजने, इस प्रकार का कुछ करने और इन सभी चीजों के साइड इफेक्ट्स होने की आवश्यकता होती है। लेकिन हम निश्चित रूप से चल रहे अतिप्रभावी दुष्प्रभावों की संख्या को कम कर सकते हैं, और जब नियंत्रण प्रवाह बहुत जटिल होते हैं, तो होने वाले दुष्प्रभावों की संख्या को भी कम कर सकते हैं, और मुझे लगता है कि अगर हमने किया तो कीड़े से बचना बहुत आसान होगा।