उचित टाइपिंग: स्वच्छ कोड का अंडरेटेड पहलू

नमस्कार साथियों!

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



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

मंगल की जलवायु परिक्रमा करती है

मार्स क्लाइमेट ऑर्बिटर अंतरिक्ष यान लैंडिंग के दौरान दुर्घटनाग्रस्त हो गया और मार्टियन वातावरण में अलग हो गया, क्योंकि लॉकहीड सॉफ्टवेयर घटक ने गति को महत्व दिया, पाउंड-बल सेकंड में मापा गया, जबकि नासा द्वारा विकसित अन्य घटक ने न्यूमॉन में गति का मान लिया- सेकंड।

आप लगभग निम्नलिखित रूप में नासा द्वारा विकसित घटक की कल्पना कर सकते हैं:

//    ,  >= 2 N s void trajectory_correction(double momentum) { if (momentum < 2 /* N s */) { disintegrate(); } /* ... */ } 

आप यह भी सोच सकते हैं कि लॉकहीड घटक ने उपरोक्त कोड को इस तरह कहा है:

 void main() { trajectory_correction(1.5 /* lbf s */); } 

पाउंड-फोर्स-सेकंड (lbfs) लगभग 4.448222 न्यूटन प्रति सेकंड (एनएस) है। इस प्रकार, लॉकहीड के दृष्टिकोण से, trajectory_correction लिए 1.5 lbfs से गुजरना पूरी तरह से सामान्य होना चाहिए: 1.5 lbfs लगभग 6.672333 एनएस, 2 एनएस की दहलीज के ऊपर है।

समस्या डेटा व्याख्या है। नतीजतन, नासा घटक रूपांतरण के बिना एनएस के साथ lbfs की तुलना करता है और गलती से इनपुट को lbfs को एनएस के इनपुट के रूप में व्याख्या करता है। चूंकि 1.5 2 से कम है, ऑर्बिटर ढह गया। यह एक प्रसिद्ध एंटीपैटर्न है जिसे आदिम जुनून कहा जाता है।

आदिम के साथ जुनून

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

एक सरल प्रकार के Ns को परिभाषित करना अधिक सुरक्षित होगा:

 struct Ns { double value; }; bool operator<(const Ns& a, const Ns& b) { return a.value < b.value; } 

इसी तरह, आप एक साधारण प्रकार की lbfs को परिभाषित कर सकते हैं:

 struct lbfs { double value; }; bool operator<(const lbfs& a, const lbfs& b) { return a.value < b.value; } 

अब आप trajectory_correction एक प्रकार-सुरक्षित संस्करण को लागू कर सकते हैं:

 //  ,   >= 2 N s void trajectory_correction(Ns momentum) { if (momentum < Ns{ 2 }) { disintegrate(); } /* ... */ } 

यदि आप इसे lbfs साथ lbfs , जैसा कि ऊपर दिए गए उदाहरण में है, तो कोड केवल असंगतता के कारण संकलित नहीं करता है:

 void main() { trajectory_correction(lbfs{ 1.5 }); } 

ध्यान दें कि मूल्य प्रकार की जानकारी, जो आमतौर पर टिप्पणियों में इंगित की जाती है, ( 2 /*Ns */, /* lbfs */ ) अब टाइप सिस्टम में तैयार की गई है और कोड में व्यक्त की गई है: ( Ns{ 2 }, lbfs{ 1.5 } ) ।

बेशक, एक स्पष्ट ऑपरेटर के रूप में lbfs को lbfs कमी प्रदान करना संभव है:

 struct lbfs { double value; explicit operator Ns() { return value * 4.448222; } }; 

इस तकनीक से लैस, आप स्थैतिक कलाकारों का उपयोग करके trajectory_correction कह सकते हैं:

 void main() { trajectory_correction(static_cast<Ns>(lbfs{ 1.5 })); } 

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

निहितार्थ की तुलना में स्पष्ट है

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

राज्य का स्थान

परेशानी तब होती है जब कोई कार्यक्रम खराब स्थिति में समाप्त हो जाता है। प्रकार उनकी घटना के लिए क्षेत्र को संकीर्ण करने में मदद करते हैं। आइए प्रकार को संभव मानों के सेट के रूप में मानने का प्रयास करें। उदाहरण के लिए, बूल सेट {true, false} , जहां इस प्रकार का एक चर इन दो मूल्यों में से एक ले सकता है। इसी तरह, uint32_t सेट {0 ...4294967295} । इस प्रकार के प्रकारों को ध्यान में रखते हुए, हम अपने कार्यक्रम के राज्य स्थान को एक निश्चित समय पर सभी जीवित चर के प्रकारों के उत्पाद के रूप में परिभाषित कर सकते हैं।

यदि हमारे पास प्रकार bool का एक चर और प्रकार uint32_t का एक चर है, तो हमारा राज्य स्थान {true, false} X {0 ...4294967295} । इसका मतलब सिर्फ इतना है कि दोनों चर उनके लिए किसी भी स्थिति में संभव हो सकते हैं, और चूंकि हमारे पास दो चर हैं, इसलिए कार्यक्रम इन दो प्रकारों के किसी भी संयुक्त राज्य में समाप्त हो सकता है।

यदि हम उन कार्यों पर विचार करते हैं जो मूल्यों को आरंभ करते हैं तो सब कुछ बहुत अधिक दिलचस्प हो जाता है:

 bool get_momentum(Ns& momentum) { if (!some_condition()) return false; momentum = Ns{ 3 }; return true; } 

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

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

 void example() { Ns momenum; get_momentum(momentum); trajectory_correction(momentum); } 

इसके बजाय, हमें बस यह करना है:

 void example() { Ns momentum; if (get_momentum(momentum)) { trajectory_correction(momentum); } } 

हालांकि, एक बेहतर तरीका है जिसमें यह जबरन किया जा सकता है:

 std::optional<Ns> get_momentum() { if (!some_condition()) return std::nullopt; return std::make_optional(Ns{ 3 }); } 

यदि आप optional उपयोग करते हैं, तो इस फ़ंक्शन का राज्य स्थान काफी कम हो जाएगा: bool X Ns बजाय bool X Ns हमें Ns + 1 मिलता है। यह फ़ंक्शन या तो nullopt इंगित करने के लिए एक वैध nullopt या nullopt । अब, हमारे पास एक अमान्य Ns नहीं है जो सिस्टम में फैल जाएगा। इसके अलावा अब वापसी मूल्य की जांच करना भूल जाना असंभव हो गया है, क्योंकि वैकल्पिक को Ns परिवर्तित नहीं किया जा सकता है - हमें इसकी कीमत को एक करने की आवश्यकता होगी:

 void example() { auto maybeMomentum = get_momentum(); if (maybeMomentum) { trajectory_correction(*maybeMomentum); } } 

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

इस दृष्टिकोण से, अपवादों को फेंकना सामान्य है, क्योंकि यह ऊपर वर्णित सिद्धांत से मेल खाता है: एक फ़ंक्शन या तो एक परिणाम लौटाएगा या एक अपवाद फेंक देगा।

आरए II

RAII का मतलब रिसोर्स एक्विजिशन इनिशियलाइज़ेशन है, लेकिन बहुत हद तक यह सिद्धांत संसाधनों की रिहाई से जुड़ा है। नाम पहली बार C ++ में दिखाई दिया, हालांकि, इस पैटर्न को किसी भी भाषा में लागू किया जा सकता है (उदाहरण के लिए, .NET से IDisposable देखें)। RAII स्वचालित संसाधन सफाई प्रदान करता है।

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

चूंकि ये संसाधन बाहरी हैं, इसलिए वे हमारे प्रकार प्रणाली में स्पष्ट रूप से व्यक्त नहीं किए गए हैं। उदाहरण के लिए, यदि हम डायनेमिक मेमोरी का एक टुकड़ा चुनते हैं, तो हमें एक पॉइंटर मिलेगा, जिसके द्वारा हमें delete कॉल करना होगा:

 struct Foo {}; void example() { Foo* foo = new Foo(); /*  foo */ delete foo; } 

लेकिन अगर हम ऐसा करना भूल जाते हैं, या क्या हमें कॉल delete से रोकता है?

 void example() { Foo* foo = new Foo(); throw std::exception(); delete foo; } 

इस मामले में, हम अब delete कॉल नहीं करते हैं और रिसोर्स लीक करते हैं। सिद्धांत रूप में, संसाधनों की ऐसी मैनुअल सफाई अवांछनीय है। डायनेमिक मेमोरी के लिए, हमें इसे प्रबंधित करने में मदद करने के लिए unique_ptr है:

 void example() { auto foo = std::make_unique<Foo>(); throw std::exception(); } 

हमारा unique_ptr एक स्टैक ऑब्जेक्ट है, इसलिए यदि यह स्कोप unique_ptr (जब फंक्शन एक अपवाद फेंकता है या जब स्टैक अनइंस्टॉल होता है जब एक अपवाद फेंका जाता है), तो इसके डिस्ट्रक्टर को कहा जाता है। यह वह विध्वंसक है जो delete कॉल को लागू करता है। तदनुसार, हमें अब स्मृति संसाधन का प्रबंधन नहीं करना है - हम इस काम को रैपर में स्थानांतरित करते हैं, जो इसके मालिक हैं और इसकी रिहाई के लिए जिम्मेदार है।

इसी तरह के रैपर मौजूद हैं (या निर्मित किए जा सकते हैं) किसी अन्य संसाधन के लिए (उदाहरण के लिए, विंडोज से ओएस CloseHandle को एक प्रकार से लपेटा जा सकता है, इस स्थिति में इसका विध्वंसक CloseHandle )।

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

निष्कर्ष

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

• घोषित करना और मजबूत प्रकारों का उपयोग करना (जैसा कि आदिम के प्रति जुनून के विपरीत)।
• राज्य स्थान को कम करना, परिणाम या त्रुटि लौटना, परिणाम या त्रुटि नहीं।
• RAII और स्वचालित संसाधन प्रबंधन।

इसलिए, कोड को सुरक्षित बनाने और पुन: उपयोग के लिए इसे अनुकूलित करने में बहुत मदद करते हैं।