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

मुझे जाने-माने मिरांडा IM इंस्टेंट मैसेंजर क्लाइंट का कोड मिला। विभिन्न प्लगइन्स के साथ, यह एक काफी बड़ी परियोजना है, जिसका आकार C और C ++ में लगभग 950 हजार लाइनें हैं। और, विकास के इतिहास के साथ किसी भी ठोस परियोजना में, इसमें त्रुटियों और टाइपोस की काफी संख्या है।

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



मिरांडा आईएम के विश्लेषण के लिए, मैंने पीवीएस-स्टूडियो 4.14 विश्लेषक का उपयोग किया (हां, आपने इसका अनुमान लगाया था)। मिरांडा आईएम परियोजना का कोड बहुत उच्च गुणवत्ता वाला है, जो इस कार्यक्रम की लोकप्रियता की पुष्टि करता है। मैं स्वयं इस ग्राहक का उपयोगकर्ता हूं और गुणवत्ता के मामले में इसकी कोई शिकायत नहीं है। प्रोजेक्ट को विजुअल स्टूडियो में चेतावनी स्तर 3 (/ W3) के साथ इकट्ठा किया गया है, और टिप्पणियों की संख्या पूरे कार्यक्रम पाठ का 20% है।

1. कार्यों को शुरू करने से बचें, memcpy, ZeroMemory और पसंद करें

हम निम्न त्रुटियों के साथ शुरू करेंगे, जो निम्न-स्तरीय मेमोरी फ़ंक्शंस जैसे कि मेमसेट, मेमसीपी, ज़ीरोमेरी और जैसे का उपयोग करते समय होती हैं।

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

1) बड़े सरणियों का प्रसंस्करण। यही है, जहां एक अनुकूलित फ़ंक्शन एल्गोरिथ्म एक सरल चक्र में प्रसंस्करण तत्वों की तुलना में लाभ देगा।

2) बड़ी संख्या में छोटे सरणियों का प्रसंस्करण। यह प्रदर्शन में सुधार के संदर्भ में भी समझ में आता है।

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

V512 ' मेमसीपी ' फंक्शन के कॉल से बफर ओवरफ्लो या अंडरफ्लो हो जाएगा। tabsrmm बर्तन। 1080

  typedef संरचना _textrangew
 {
   वर्ण क्रम;
   LPWSTR lpstrText;
 } TEXTRANGEW;

 const wchar_t * Utils: extractURLFromRichEdit (...)
 {
   ...
   :: कॉपीमेरी (tr.lpstrText, L "mailto:", 7);
   ...
 } 

केवल स्ट्रिंग का एक टुकड़ा कॉपी करें। एक गलती अपमानजनक है, लेकिन यह एक गलती नहीं है। सबसे अधिक संभावना है, पहले 'चार' से युक्त एक स्ट्रिंग का उपयोग यहां किया गया था। फिर उन्होंने यूनिकोड स्ट्रिंग्स पर स्विच किया, और निरंतर बदलने के लिए भूल गए।

यदि आप शुरू में उन कार्यों का उपयोग करते हैं जो इसके लिए स्ट्रिंग की प्रतिलिपि बनाने के लिए हैं, तो ऐसी त्रुटि बस नहीं हो सकती है। कल्पना कीजिए कि ऐसा क्या लिखा गया था:

  strncpy (tr.lpstrText, "mailto:", 7); 

फिर, यूनिकोड के तारों पर स्विच करते समय, संख्या 7 को बदलने की आवश्यकता नहीं है:

  wcsncpy (tr.lpstrText, L "mailto:", 7); 

मैं यह नहीं कह रहा हूं कि यह एकदम सही कोड है। लेकिन यह पहले से ही CopyMemory का उपयोग करने से बहुत बेहतर है। एक अन्य उदाहरण पर विचार करें।

V568 यह अजीब है कि आकार का तर्क () ऑपरेटर 'और ImgIndex' अभिव्यक्ति है। clist_modern modern_extraimage.cpp 302

  व्यर्थ एक्स्ट्राइमेज_सेटएक्लेक्ट्राइकन्स (HWND hwndList, HANDLE hContact)
 {
   ...
   चार * (ImgIndex [64]);
   ...
   मेमसेट (& ImgIndex, 0, sizeof (& ImgIndex));
   ...
 } 

यहाँ मैं 64 पॉइंट की एक सरणी को शून्य करना चाहता था। लेकिन इसके बजाय, हम केवल पहले तत्व को रीसेट करते हैं। उसी त्रुटि, वैसे, एक और फ़ाइल में फिर से मौजूद है। कॉपी-पेस्ट के लिए धन्यवाद कहें:

V568 यह अजीब है कि आकार का तर्क () ऑपरेटर 'और ImgIndex' अभिव्यक्ति है। clist_mw extraimage.c 295

कोड का सही संस्करण इस तरह दिखना चाहिए:

  मेमसेट (& ImgIndex, 0, sizeof (ImgIndex)); 

वैसे, एक सरणी से एक पता लेने से केवल उस व्यक्ति को भ्रमित किया जा सकता है जो कोड पढ़ता है। यहां, पते लेने का कोई प्रभाव नहीं है। और कोड इस तरह लिखा जा सकता है:

  मेमसेट (ImgIndex, 0, sizeof (ImgIndex)); 

निम्न उदाहरण।

V568 यह विचित्र है कि sizeof () ऑपरेटर का तर्क 'और rowOptTA' अभिव्यक्ति है। clist_modern modern_rowtemplateopt.cpp 258

  स्थिर ROWCELL * rowOptTA [100];

 शून्य पंक्तिOptAddContainer (HWND htree, HTREEITEM hti)
 {
   ...
   ZeroMemory (rowOptTA, sizeof (& rowOptTA));
   ...
 } 

फिर से, सरणी के आकार की गणना करने के बजाय, हम सूचक के आकार की गणना करते हैं। सही अभिव्यक्ति "sizeof (rowOptTA)" है। सरणी को साफ करने के लिए, मैं इस तरह के कोड के निम्नलिखित संस्करण का प्रस्ताव करता हूं:

  const size_t ArraySize = 100;
 स्थिर ROWCELL * rowOptTA [ArraySize];
 ...
 std :: fill (rowOptTA, rowOptTA + ArraySize, nullptr); 

मैं पहले से ही इस तथ्य का उपयोग कर रहा हूं कि इस तरह की लाइनें प्रोग्राम को कॉपी करके पुन: पेश करना पसंद करती हैं:

V568 यह विचित्र है कि sizeof () ऑपरेटर का तर्क 'और rowOptTA' अभिव्यक्ति है। clist_modern modern_rowtemplateopt.cpp 308

V568 यह विचित्र है कि sizeof () ऑपरेटर का तर्क 'और rowOptTA' अभिव्यक्ति है। clist_modern modern_rowtemplateopt.cpp 438

क्या आपको लगता है कि यह सरणियों के साथ निचले स्तर के काम के बारे में है? नहीं, बिलकुल नहीं। आगे देखिए, डरो और फैंस के हाथ हिलाकर लिखो यादगार।

V512 'मेमसेट' फ़ंक्शन की कॉल से बफर ओवरफ़्लो या अंडरफ़्लो हो जाएगा। clist_modern modern_image_array.cpp 59

  स्थिर BOOL ImageArray_Alloc (LP_IMAGE_ARRAY_DATA iad, int आकार)
 {
   ...
   मेमसेट (& iad-> नोड्स [iad-> nodes_allocated_size], 
     (size_grow - iad-> nodes_allocated_size) *
        sizeof (IMAGE_ARRAY_DATA_NODE),
     0);
   ...
 } 

इस बार कॉपी किए गए डेटा के आकार की सही गणना की जाती है। दूसरे और तीसरे तर्क सिर्फ भ्रमित हैं। परिणामस्वरूप, हम 0 तत्वों को भरते हैं। सही विकल्प:

  मेमसेट (& iad-> नोड्स [iad-> nodes_allocated_size], 0,
   (size_grow - iad-> nodes_allocated_size) *
      sizeof (IMAGE_ARRAY_DATA_NODE)); 

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

सवाल यह है कि, OPENFILENAME जैसी संरचनाओं के साथ काम करते समय मैं बिना किसी परेशानी के कैसे कर सकता हूं:

  OPENFILENAME x;
 मेमसेट (& x, 0, sizeof (x)); 

बहुत सरल है। आप इस तरह एक अशक्त संरचना बना सकते हैं:

  OPENFILENAME x = {0}; 

2. बारीकी से निगरानी करें कि क्या आप एक हस्ताक्षरित या अहस्ताक्षरित प्रकार के साथ काम करते हैं

हस्ताक्षरित और अहस्ताक्षरित प्रकारों के बीच भ्रम की समस्या पहली नज़र में दूर की कौड़ी लग सकती है। लेकिन इस सवाल को प्रोग्रामर्स ने बेकार में कम करके आंका है।

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

मेरा सुझाव है कि आप ऐसा दोबारा नहीं करते हैं और हर बार स्थिति का विश्लेषण करते हैं जब एक हस्ताक्षरित प्रकार एक अहस्ताक्षरित के साथ सामना किया जाता है। और, सामान्य तौर पर, इस बात के प्रति चौकस रहें कि अभिव्यक्ति किस प्रकार की है या फ़ंक्शन क्या देता है। अब इस विषय पर कुछ उदाहरण।

V547 अभिव्यक्ति 'wParam> = 0' हमेशा सच होती है। अहस्ताक्षरित प्रकार का मान हमेशा> = 0. clist_mw cluiframes.c 3140 है

प्रोग्राम कोड में एक id2pos फ़ंक्शन होता है, जो त्रुटि के मामले में '-1' मान लौटाता है। इस सुविधा में कुछ भी गलत नहीं है। अन्यत्र, id2pos फ़ंक्शन का परिणाम निम्नानुसार है:

  टाइपेडिफ UINT_PTR WPARAM; 
 स्थिर int id2pos (int id);
 स्थिर int nFramescount = 0;

 INT_PTR CLUIFrameSetFloat (WPARAM wParam, LPARAM lParam)
 {
   ...
   wParam = id2pos (wParam);
   अगर (wParam> = 0 && (int) wParam <nFramescount)
     अगर (फ्रेम [wParam] .फ्लोटिंग)
   ...
 } 

समस्या यह है कि wParam चर का एक अहस्ताक्षरित प्रकार है। इसलिए, शर्त 'wParam> = 0' हमेशा सही होती है। यदि id2pos फ़ंक्शन '-1' देता है, तो अमान्य मानों की जाँच करने की शर्त काम नहीं करेगी और हम एक नकारात्मक सूचकांक का उपयोग करना शुरू कर देंगे।

मुझे पूरा यकीन है कि निम्नलिखित कोड पहले लिखा गया था:

अगर (wParam> = 0 && wParam <nFramescount)

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

if ((int) wParam> = 0 && (int) wParam <nFramescount)

इसलिए ध्यान दें और एक बार फिर से ऐसी जगहों पर ध्यान दें। मिरांडा आईएम में, मैंने 33 शर्तें गिनाईं, जो हस्ताक्षरित / अहस्ताक्षरित के साथ भ्रम के कारण हमेशा सही या हमेशा गलत होती हैं।

चलिए जारी रखते हैं। मैं विशेष रूप से निम्नलिखित उदाहरण को पसंद करता हूं। और टिप्पणी सिर्फ अद्भुत है।

V547 अभिव्यक्ति 'nOldLength <0' हमेशा झूठी होती है। अहस्ताक्षरित प्रकार का मान कभी <0 नहीं है। IRC mstring.h 229

  शून्य परिशिष्ट (PCXSTR pszSrc, int nLength)
 {
   ...
   UINT nOldLength = GetLength ();
   अगर (nOldLength <0)
   {
     // अंडरफ्लो से बचाता है
     nOldLength = 0;
   }
   ...
 } 

मुझे लगता है कि इस कोड के लिए कोई स्पष्टीकरण की आवश्यकता नहीं है।

बेशक, केवल प्रोग्रामर हमेशा त्रुटियों के लिए दोषी नहीं होते हैं। कभी-कभी पुस्तकालय डेवलपर्स (इस मामले में, WinAPI) भी एक सुअर जोड़ते हैं।

  #define SRMSGSET_LIMITNAMESLEN_MIN 0
 स्थिर INT_PTR कॉलबैक DlgProcTabsOptions (...)
 {
   ...
   LimLength =
     GetDlgItemInt (hwndDlg, IDC_LIMITNAMESLEN, NULL, TRUE)> =
     SRMSGSET_LIMITNAMESLEN_MIN?
     GetDlgItemInt (hwndDlg, IDC_LIMITNAMESLEN, NULL, TRUE):
     SRMSGSET_LIMITNAMESLEN_MIN;
   ...
 } 

यदि आप एक अत्यधिक जटिल अभिव्यक्ति पर ध्यान नहीं देते हैं, तो कोड सही दिखता है। वैसे, यह आम तौर पर एक पंक्ति थी। सुविधा के लिए, मैंने इसे कई हिस्सों में तोड़ दिया। हालाँकि, अब हम कोड के प्रारूपण पर स्पर्श नहीं करेंगे।

समस्या यह है कि GetDlgItemInt () फ़ंक्शन बिल्कुल भी 'int' वापस नहीं करता है, जैसा कि प्रोग्रामर को उम्मीद है। यह फ़ंक्शन एक UINT देता है। यहाँ WinUser.h फ़ाइल से उसका प्रोटोटाइप है:

  WINUSERAPI
 uint
 WINAPI
 GetDlgItemInt (
     एचआईएनड एचडीडीजी,
     __ में int nIDDlgItem,
     __out_opt BOOL * lpTranslated,
     __IN BOOL bSign); 

परिणामस्वरूप, PVS-Studio एक संदेश प्रदर्शित करता है:

V547 अभिव्यक्ति हमेशा सच है। अहस्ताक्षरित प्रकार का मान हमेशा होता है> = 0. स्क्राइवर msgoptions.c 458

और यह वास्तव में है। अभिव्यक्ति "GetDlgItemInt (hwndDlg, IDC_LIMITNAMESLEN, NULL, TRUE)> = SRMSGSET_LIMITNAMESLEN_MIN" हमेशा सत्य है।

विशेष रूप से, इस मामले में, शायद, कोई गलती नहीं होगी। लेकिन मेरी चेतावनी का अर्थ, मुझे आशा है, स्पष्ट है। ध्यान से देखें कि कौन से कार्य आपके पास लौटते हैं

3. एक पंक्ति में बहुत अधिक गणनाओं से बचें।

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

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

V567 अपरिभाषित व्यवहार। अनुक्रम बिंदुओं के बीच दो बार उपयोग किए जाने के दौरान 's' वेरिएबल को संशोधित किया जाता है। एमएसएन ezxml.c 371

  लघु ezxml_internal_dtd (ezxml_root_t रूट, char * s, size_n le)
 {
   ...
   जबकि (* (n = ++ s + strspn (s, EZXML_WS)) && * n! = '' '' {{!
   ...
 } 

यह वह जगह है जहाँ अपरिभाषित व्यवहार उत्पन्न होता है। यह कोड कार्यक्रम के लंबे जीवन पर सही ढंग से काम कर सकता है। लेकिन इसकी कोई गारंटी नहीं है कि यह संकलक संस्करण या अनुकूलन कुंजी को बदलने के बाद भी व्यवहार करेगा। संकलक के पास पहले '++ s' की गणना करने का अधिकार है, और फिर फ़ंक्शन को 'strspn (s, EZXML_WSP') कहा जाता है। या, इसके विपरीत, सबसे पहले यह एक फ़ंक्शन को कॉल कर सकता है, और उसके बाद ही चर 's' के मान को बढ़ाता है।

मैं एक और उदाहरण दूंगा, कि आपको एक लाइन में सब कुछ इकट्ठा करने की कोशिश क्यों नहीं करनी चाहिए। मिरांडा IM में, प्रोग्राम निष्पादन की कुछ शाखाएँ '&& 0' फॉर्म के आवेषण का उपयोग करके अक्षम / सक्षम हैं। उदाहरण:

  अगर (1 || altDraw) && ...
 अगर (g_CluiData.bCurrentAlpha == GoalAlpha && 0)
 अगर (checkboxWidth && (subindex == - 1 || 1)) { 

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

V560 सशर्त अभिव्यक्ति का एक हिस्सा हमेशा गलत होता है: 0. clist_modern modern_clui.cpp 2979

  LRESULT CLUI :: OnDrawItem (UINT msg, WPARAM wParam, LPARAM lParam)
 {
   ...
   ड्रास्टेट (dis-> hDC, NULL, NULL, (LPARAM) hIcon, 0,
     dis-> rcItem.right + dis-> rcItem.left-
     GetSystemMetrics (SM_CXSMICON)) / 2 + dx,
     (dis-> rcItem.bottom + dis-> rcItem.top-
     GetSystemMetrics (SM_CYSMICON)) / 2 + dx,
     0.0
     DST_ICON |
     (dis-> itemState और ODS_INACTIVE && FALSE; DSS_DISABLED: DSS_NORMAL));
    ...
 } 

यदि कोई गलती नहीं है, तो इस पंक्ति में FALSE शब्द को याद रखना और खोजना अभी भी आसान नहीं है। क्या तुमने उसे पाया? सहमत - एक आसान काम नहीं है। और अगर यह एक गलती है? फिर कोड को देखकर इसे खोजने का कोई मौका नहीं है। इस तरह के भाव अलग से बनाने के लिए बहुत उपयोगी होते हैं। एक उदाहरण:

  UINT uFlags = DST_ICON;
 uFlags | = dis-> itemState & ODS_INACTIVE && FALSE?
             DSS_DISABLED: DSS_NORMAL; 

और मैं खुद, शायद, इसे लंबे, लेकिन अधिक समझने योग्य तरीके से लिखूंगा:

  UINT uFlags;
 अगर (dis-> itemState & ODS_INACTIVE && (((FALSE))))
   uFlags = DST_ICON |  DSS_DISABLED;
 अन्यथा 
   uFlags = DST_ICON |  DSS_NORMAL; 

हां, यह लंबा है, लेकिन इसे पढ़ना आसान है, और FALSE शब्द बेहतर है।

4. कोड में सब कुछ संभव संरेखित करें

कोड संरेखण टाइपो या कॉपी-पेस्ट में त्रुटियों की संभावना को कम करता है। यदि कोई त्रुटि अभी भी बनी है, तो कोड समीक्षा प्रक्रिया के दौरान इसे ढूंढना कई बार आसान होगा। एक कोड उदाहरण पर विचार करें।

V537 'मैक्सएक्स' आइटम के उपयोग की शुद्धता की समीक्षा करने पर विचार करें। clist_modern modern_skinengine.cpp 2898

  स्थिर BOOL ske_DrawTextEffect (...)
 {
   ...
   minX = max (0, minX + mcLeftStart-2);
   minY = max (0, minY + mcTopStart-2);
   maxX = min ((int) चौड़ाई, maxX + mcRightEnd-1);
   maxY = min ((int) height, maxX + mcBottomEnd-1);
   ...
 } 

कोड का एक अखंड टुकड़ा जो पढ़ने के लिए पूरी तरह से निर्बाध है। इसे प्रारूपित करें:

  minX = max (0, minX + mcLeftStart - 2);
 minY = max (0, minY + mcTopStart - 2);
 maxX = min ((int) चौड़ाई, maxX + mcRightEnd - 1);
 maxY = min ((int) height, maxX + mcBottomEnd - 1); 

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

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

V536 सलाह दी जाती है कि उपयोग किए गए स्थिर मूल्य को एक अष्टाधारी रूप द्वारा दर्शाया जाए। अक्टूबर: 037, दिसंबर: 31. एमएसएन msn_mime.cpp 192

  स्थिर कास्ट संरचना _tag_cpltbl
 {
   अहस्ताक्षरित सीपी;
   const char * मिमेकप;
 } cptbl [] =
 {
   {037, "IBM037"}, // IBM EBCDIC यूएस-कनाडा 
   {437, "IBM437"}, // ओईएम यूनाइटेड स्टेट्स 
   {500, "IBM500"}, // IBM EBCDIC इंटरनेशनल 
   {708, "ASMO-708"}, // अरबी (ASMO 708) 
   ...
 } 

संख्याओं का एक अच्छा स्तंभ बनाना चाहते हैं, शुरुआत में '0' दर्ज करना और ऑक्टल को स्थिर बनाना आसान है।

सिफारिश को स्पष्ट करें। कोड में सब कुछ संभव संरेखित करें। लेकिन शून्य जोड़कर संख्याओं को संरेखित न करें।

5. एक से अधिक बार एक स्ट्रिंग का प्रचार न करें

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

V525 समान ब्लॉकों के संग्रह वाले कोड। चेक आइटम '1316', '1319', '1318', '1323', '1323', '1317', '1321' लाइनों में 954, 955, 956, 957, 957, 958, 959, 960: clist_modern modern_clcopts.cpp 954

  स्थिर INT_PTR कॉलबैक DlgProcTrayOpts (...)
 {
   ...
   EnableWindow (GetDlgItem (hwndDlg, IDC_PRIMARYSTATUS), TRY);
   EnableWindow (GetDlgItem (hwndDlg, IDC_CYCLETIMESPIN), FALSE);
   EnableWindow (GetDlgItem (hwndDlg, IDC_CYCLETIME), FUTSE);    
   EnableWindow (GetDlgItem (hwndDlg, IDC_ALWAYSPRIMARY), FALSE);
   EnableWindow (GetDlgItem (hwndDlg, IDC_ALWAYSPRIMARY), FALSE);
   EnableWindow (GetDlgItem (hwndDlg, IDC_CYCLE), FALSE);
   EnableWindow (GetDlgItem (hwndDlg, IDC_MULTITRAY), FUTSE);
   ...
 } 

सबसे अधिक संभावना है, यहां कोई वास्तविक गलती नहीं है। हम सिर्फ IDC_ALWAYSPRIMARY तत्व के साथ दो बार काम करते हैं। फिर भी, कॉपी किए गए लाइनों से ऐसे ब्लॉकों में गलतियां करना बहुत आसान है।

6. कंपाइलर पर उच्च स्तर की चेतावनी सेट करें और स्टैटिक एनालाइजर का उपयोग करें

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

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

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

त्रुटियों के कुछ उदाहरणों पर विचार करें जिन्हें स्रोत कोड एनालाइज़र द्वारा जल्दी से पता लगाया जा सकता है:

V560 सशर्त अभिव्यक्ति का एक हिस्सा हमेशा सच होता है: 0x01000। tabsrmm tools.cpp 1023

  # डेफिन GC_UNICODE 0x01000

 DWORD dwFlags;

 UINT CreateGCMenu (...)
 {
   ...
   अगर (iIndex == 1 && si-> iType! = GCW_SERVER &&
       ((सी-> dwFlags && GC_UNICODE)) {
   ...
 } 

टाइपो अनुमति दी। 'और' ऑपरेटर के बजाय, '&&' ऑपरेटर का उपयोग किया जाता है। कोड लिखते समय यहां कैसे सुरक्षित रहें, मुझे नहीं पता। हालत का सही संस्करण:

  (si-> dwFlags & GC_UNICODE) 

निम्न उदाहरण।

V528 यह अजीब है कि 'char' प्रकार के सूचक की तुलना '\ 0' मान से की जाती है। शायद इसका मतलब है: * str! = '\ 0'। clist_modern modern_skinbutton.cpp 282

V528 यह अजीब है कि 'char' प्रकार के सूचक की तुलना '\ 0' मान से की जाती है। संभवत: इसका मतलब है: * अंत:! '' 0 '। clist_modern modern_skinbutton.cpp 283

  स्टेटिक चार * _स्किपब्लैंक (चार * स्ट्र)
 {
   char * endstr = str + strlen (str);
   जबकि ((* str == '' || * str == '\ t') && str! = '' 0 '') str ++;
   जबकि ((* endstr == '' || * * endstr == '\ t') &&
          endstr! = '' 0 '' && endstr <str)
     endstr--;
   ...
 } 

इस कोड में, केवल दो तारांकन '*' केवल डेरेफ़रिंग पॉइंटर्स के लिए भुला दिए जाते हैं। इसका परिणाम घातक हो सकता है। इस कोड का उल्लंघन करने की संभावना है। कोड का सही संस्करण:

  जबकि ((* str == '' || * str == '\ t') && * str! = '\' 0 ') str ++;
 जबकि ((* endstr == '' || * * endstr == '\ t') &&
        * endstr! = '\ 0' && endstr <str)
   endstr--; 

यहां फिर से, कोड की जांच करने के लिए विशेष उपकरणों का उपयोग करने के अलावा अन्य सलाह देना कठिन है।

निम्न उदाहरण।

V514 एक और मान द्वारा एक पॉइंटर 'sizeof (पाठ)' आकार का विभाजन। तार्किक त्रुटि उपस्थिति की संभावना है। clist_modern modern_cachefuncs.cpp 567

  #define SIZEOF (X) (sizeof (X) / sizeof (X [0]))

 int Cache_GetLineText (..., LPTSTR टेक्स्ट, int text_size, ...)
 {
   ...
   tmi.printDateTime (pdnce-> hTimeZone, _T ("t"), पाठ, SIZEOF (पाठ), 0);
   ...
 } 

पहली नज़र में, सब कुछ ठीक है। पाठ और इसकी लंबाई SIZEOF मैक्रो का उपयोग करके गणना की जाती है। वास्तव में, मैक्रो को COUNT_OF कहा जाना चाहिए, लेकिन वह बिंदु नहीं है। परेशानी यह है कि हम सूचकांक में वर्णों की संख्या को गिनने की कोशिश कर रहे हैं। यहाँ यह "sizeof (LPTSTR) / sizeof (TCHAR)" की गणना करता है। एक व्यक्ति ऐसे संदिग्ध स्थानों को खराब तरीके से नोटिस करता है, लेकिन संकलक और स्थिर विश्लेषक अच्छे हैं। कोड का सही संस्करण:

  tmi.printDateTime (pdnce-> hTimeZone, _T ("t"), text, text_size, 0); 

अगला उदाहरण

V560 सशर्त अभिव्यक्ति का एक हिस्सा हमेशा सच होता है: 0x29। icqoscar8 fam_03buddy.cpp 632

  शून्य CIcqProto :: handleUserOffline (BYTE * buf, WORD wLen)
 {
   ...
   और यदि (wTLVType = 0x29 && wTLVLen == sizeof (DWORD))
   ...
 } 

यहां अनुशंसा यह है कि पहली जगह में स्थिति में स्थिर लिखना है। इस तरह का कोड केवल संकलन नहीं करता है:

  यदि (0x29 = wTLVType && sizeof (DWORD) == wTLVLen) 

लेकिन मेरे सहित कई प्रोग्रामर्स को यह स्टाइल पसंद नहीं है। उदाहरण के लिए, यह मुझे कोड को पढ़ने से रोकता है, क्योंकि पहली बार में मैं यह पता लगाना चाहता हूं कि किस चर की तुलना की गई है, और उसके बाद ही वास्तव में।

यदि प्रोग्रामर तुलना की इस शैली से इनकार करता है, तो वह या तो कंपाइलर / विश्लेषक पर भरोसा कर सकता है या जोखिम ले सकता है।

वैसे, इस तथ्य के बावजूद कि हर कोई इस त्रुटि के बारे में जानता है, यह दुर्लभ नहीं है। मिरांडा IM के तीन और उदाहरण, जहाँ PVS-Studio विश्लेषक ने एक चेतावनी V559 जारी की:

  और अगर (ft-> ft_magic = FT_MAGIC_OSCAR)
 अगर (सेवानिवृत्त = 0) {वापसी (0) ;;
 यदि (ड्राइंग-> प्रकार = CLCIT_CONTACT) 

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

V542 एक विषम प्रकार की कास्ट का निरीक्षण करने पर विचार करें: 'char *' से 'char'। clist_modern modern_toolbar.cpp 586

  स्थिर शून्य
 sttRegisterToolBarButton (..., char * pszButtonName, ...)
 {
   ...
   अगर (BYTE) pszButtonName)
     tbb.tbbFlags = TBBF_FLEXSIZESEPARATOR;
   अन्यथा
     tbb.tbbFlags = TBBF_ISSEPARATOR;
   ...
 } 

वास्तव में, हम जाँचते हैं कि लाइन का पता 256 का गुणक नहीं है। मुझे यह समझ में नहीं आया कि हम वास्तव में क्या लिखना चाहते थे। शायद यह सही भी है, लेकिन अत्यधिक संदिग्ध है।

कोड का विश्लेषण करके, आप कई गलत स्थितियां पा सकते हैं। एक उदाहरण:

V501 बायीं और '&&' ऑपरेटर के दाईं ओर समान उप-अभिव्यक्तियाँ 'उपयोगकर्ता-> स्टेटसमैसेज' हैं। jabber jabber_chat.cpp 214

  शून्य CJabberProto :: GcLogShowInformation (...)
 {
   ...
   अगर (उपयोगकर्ता- statusMessage && उपयोगकर्ता-> statusMessage)
   ...
 } 

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

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

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

निष्कर्ष

इस लेख में, मैंने C ++ में प्रोग्रामिंग करते समय कम गलतियों को कैसे किया जाए, इस पर केवल कुछ विचार साझा किए। अन्य विचार पक रहे हैं, जिनके बारे में मैं निम्नलिखित लेखों और नोट्स में लिखने का प्रयास करूंगा।

पुनश्च

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

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

यह समझाने के लायक भी है कि मैं अक्सर यह अनुमान लगाने के लिए क्यों नहीं हूं कि यह या वह कोड त्रुटि है या नहीं। अस्पष्ट कोड उदाहरण:

V523 'तत्कालीन' कथन 'और' कथन के बराबर है। स्क्राइवर msglog.c 695

  अगर (स्ट्रीमडैट-> फ़र्स्ट) {
   अगर (घटना-> dwFlags & IEEDF_RTL) {
     AppendToBuffer (और बफ़र, और बफ़रएंड, और बफ़रऑलरेटेड, "\\ rtlpar");
   } {
     AppendToBuffer (और बफ़र, और बफ़रएंड, और बफ़रऑलरेटेड, "\\ ltrpar");
   }
 } {
   अगर (घटना-> dwFlags & IEEDF_RTL) {
     AppendToBuffer (और बफ़र, और बफ़रएंड, और बफ़रऑलरेटेड, "\\ rtlpar");
   } {
     AppendToBuffer (और बफ़र, और बफ़रएंड, और बफ़रऑलरेटेड, "\\ ltrpar");
   }
 } 

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