कोड लिखने के चरण में त्रुटियों की संभावना को कैसे कम करें। नोट N2

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

परिचय

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

1. टर्नरी ऑपरेशन का उपयोग न करें? '' 'यौगिक अभिव्यक्तियों में

Ternary सशर्त संचालन C / C ++ में '?:' संचालक का उपयोग करके लिखा गया है। एक ऑपरेशन जो पहले ऑपरेंड द्वारा निर्दिष्ट तार्किक अभिव्यक्ति के मूल्य के आधार पर अपना दूसरा या तीसरा ऑपरेंड लौटाता है। एक उदाहरण:

  int minValue = A <B?  ए: बी; 

टर्नरी ऑपरेशन में बहुत कम प्राथमिकता है (तालिका देखें)। यह अक्सर भुला दिया जाता है और यह इस वजह से ठीक है कि टर्नरी ऑपरेशन बेहद खतरनाक है।

चित्र 1 - C / C ++ भाषा संचालन, प्राथमिकता घटने के क्रम में

ध्यान दें कि ऑपरेशन '?:' में इसके अलावा, गुणन, बिटवाइज़ या ऑपरेटर, और इसी तरह की तुलना में कम प्राथमिकता है। कोड पर विचार करें:

int Z = X + (A == B)? 1: 2;

यह कोड काम नहीं करता है क्योंकि यह पहली नज़र में लग सकता है। प्रोग्रामर सबसे अधिक संभावना एक्स (1 = बी) स्थिति के आधार पर नंबर 1 के साथ या 2 नंबर के साथ मूल्य जोड़ना चाहता था। लेकिन वास्तव में, स्थिति "X + (A == B)" की अभिव्यक्ति है। वास्तव में, यह यहाँ कहता है:

int Z = (X + (A == B))? 1: 2;

मैं चाहता था:

int Z = X + (A == B; 1: 2);

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

V502 शायद '?:' ऑपरेटर अपेक्षा के अनुरूप काम करता है। '?:' ऑपरेटर की '*' ऑपरेटर की तुलना में कम प्राथमिकता है। भौतिकी dgminkowskiconv.cpp 1061

  dgInt32 परिकलित करें
 {
   ...
   den = dgFloat32 (1.0e-24f) *
         (den> dgFloat32 (0.0f))? 
            dgFloat32 (1.0f): dgFloat32 (-1.0f);
   ...
 } 

V502 शायद '?:' ऑपरेटर अपेक्षा के अनुरूप काम करता है। '?:' ऑपरेटर की '-' ऑपरेटर की तुलना में कम प्राथमिकता है। विचार custom_frame_view.cc 400

  स्थिर कास्ट int kClientEdgeThickness;
 इंट हाइट () कास्ट;
 बूल चाहिए कंधेक्लेड एडज () कास्ट;
 void CustomFrameView :: PaintMaximizedFrameBorder (gfx :: कैनवास * कैनवास) {
   ...
   int edge_height = titlebar_bottom-> ऊँचाई () -
                     चाहिएShowClientEdge ()?  kClientEdgeThickness: 0;
   ...
 } 

V502 शायद '?:' ऑपरेटर अपेक्षा के अनुरूप काम करता है। '?:' की तुलना में ऑपरेटर की प्राथमिकता कम है। ऑपरेटर। vm vm_file_win.c 393

  #define FILE_ATTRIBUTE_NORMAL 0x00000080
 #define FILE_FLAG_NO_BUFFERING 0x20000000
 vm_file * vm_file_fopen (...)
 {
   ...
   mds [3] = FILE_ATTRIBUTE_NORMAL |
            (islog == 0)?  0: FILE_FLAG_NO_BUFFERING;
   ...
 } 

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

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

बेशक, '?:' संचालक सिंटैक्टिक शुगर है और लगभग हमेशा अगर के साथ प्रतिस्थापित किया जा सकता है। दुर्लभ अपवादों में लिंक आरंभीकरण जैसे कार्य शामिल हैं:

  MyObject & Ref = X?  ए: बी; 

बेशक, इससे कोई समस्या नहीं है, लेकिन A या B के बिना '?' का लिंक बनाना है? '' ऑपरेटर बहुत अधिक होगा:

  MyObject * tmpPtr;
 यदि (x)
   tmpPtr = & A;
 अन्यथा
   tmpPtr = & B;
 MyObject & Ref = * tmpPtr; 

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

  int Z = X + (A == B)?  1: 2; 

मैं इस तरह से लिखने का सुझाव देता हूं:

  int Z = X;
 जेड + = ए == बी?  1: 2; 

IPP नमूने से संबंधित एक उदाहरण के मामले में, मैं इसे लिखूंगा:

  mds [3] = FILE_ATTRIBUTE_NORMAL;
 mds [3] | = (islog == 0)?  0: FILE_FLAG_NO_BUFFERING; 

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

2. ब्रैकेट का उपयोग करने के लिए स्वतंत्र महसूस करें

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

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

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

V564 '&' ऑपरेटर बूल प्रकार के मूल्य पर लागू होता है। आप शायद कोष्ठकों को शामिल करना भूल गए हैं या '&&' ऑपरेटर का उपयोग करना चाहते हैं। गेम g_client.c 1534

  #define SVF_CASTAI 0x00000010
 char * ClientConnect (...) {
   ...
   अगर (ent-> r.svFlags & SVF_CASTAI) {
   ...
 } 

V564 '&' ऑपरेटर बूल प्रकार के मूल्य पर लागू होता है। आप शायद कोष्ठकों को शामिल करना भूल गए हैं या '&&' ऑपरेटर का उपयोग करना चाहते हैं। dosbox sdlmain.cpp 519

  स्थिर SDL_Surface * GFX_SetupSurfaceScaled (Bit32u sdl_flags) 
                                             Bit32u bpp) {
   ...
   if (sdl.blit.surface || (sdl.blit.surface-> झंडे और SDL_HWSURFACE)) {
   ...
 } 

खैर, क्रोमियम से एक और उदाहरण:

V564 '&' ऑपरेटर बूल प्रकार के मूल्य पर लागू होता है। आप शायद कोष्ठकों को शामिल करना भूल गए हैं या '&&' ऑपरेटर का उपयोग करना चाहते हैं। आधार platform_file_win.cc 216

  #define FILE_ATTRIBUTE_DIRECTORY 0x00000010
 बूल GetPlatformFileInfo (PlatformFile फ़ाइल, PlatformFileInfo * जानकारी) {
   ...
   जानकारी-> is_directory = है
     file_info.dwFileAttributes & FILE_ATTRIBUTE_DIRECTORY! = 0;
   ...
 } 

भाव सरल हैं। डेवलपर्स अच्छी तरह से किया। लेकिन अभी भी गलतियाँ हैं। तो फिसलन वाली जगहों पर कोष्ठक का उपयोग अतिश्योक्तिपूर्ण नहीं होगा।

शायद ऐसा करने लायक। यदि ऑपरेशन सरल और परिचित हैं, तो अतिरिक्त कोष्ठक की आवश्यकता नहीं है। उदाहरण:

  अगर (A == B && X! = Y)
 अगर (A - B <Foo () * 2) 

लेकिन अगर दुर्लभ ऑपरेटर का उपयोग किया जाता है (~, ^, &; |, <<, >> ,?? :), तो स्पष्ट कोष्ठक चोट नहीं पहुंचाएगा। यह संभावित त्रुटियों के खिलाफ कोड को पढ़ने और सुरक्षा को सरल करेगा। उदाहरण:

  यदि ((A & B))
 x = ए |  B |  (z <१; २: ३); 

दुर्लभ ऑपरेशन का उपयोग करते समय कोष्ठक का उपयोग करने में संकोच न करें और पहले से विचार किए गए ऑपरेटर के लिए मदद करेंगे? ":"। क्या वास्तव में सबसे अच्छी चीज है "?:" स्वाद का मामला है। मुझे सरलीकृत विकल्प अधिक पसंद है।

निष्कर्ष

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

जहां दुर्लभ संचालकों का उपयोग किया जाता है या जहां बिट और लॉजिकल ऑपरेशंस को मिलाया जाता है, वहां पर कोष्ठकों पर लालच न करें।

एक प्रोग्रामर जो भविष्य में कोष्ठक में आपके कोड को पढ़ेगा, उसके लिए केवल धन्यवाद कहेंगे।