मेरी पसंदीदा प्रोग्रामिंग गलतियाँ

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

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

त्रुटियां अलग-अलग हो सकती हैं: गणना में महत्वपूर्ण त्रुटियों और त्रुटियों के लिए सरल वाक्यविन्यास त्रुटियों (उदाहरण के लिए, भूल जाना}) से।

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

डिबग मोड बंद नहीं हुआ

इस लेख में मैं जिन पहली दो त्रुटियों का उल्लेख करूंगा, वे पूरी तरह विफल थीं।

जब मैंने पहली बार फ्रीलान्स की शुरुआत की, तो मैंने डेटाबेस क्वेश्चन, फॉर्म और पेज टेम्प्लेट को संभालने के लिए कई PHP लाइब्रेरीज़ लिखीं। डीबग मोड को पुस्तकालयों में काफी गहरे स्तर पर बनाया गया था, जो वैश्विक चर $ DEBUG पर निर्भर था।

मैंने विकास, डिबगिंग और परीक्षण के लिए मेरे द्वारा काम की गई प्रत्येक प्रमुख साइट की एक स्थानीय प्रति भी रखी। इस प्रकार, जब कोई समस्या उत्पन्न होती है, तो मैं हमेशा $ DEBUG = 1 सेट कर सकता हूं; जो मुझे विभिन्न चीजें बताती हैं, उदाहरण के लिए, सभी निष्पादन योग्य डेटाबेस स्टेटमेंट। मैंने ऑनलाइन साइटों के लिए शायद ही कभी इस त्रुटि का उपयोग किया था, यह स्थानीय उपयोग के लिए था।

लेकिन एक दिन, मैंने एक लोकप्रिय ई-कॉमर्स साइट पर एक छोटी सी समस्या को ठीक करते हुए, देर रात तक काम किया। मैंने $ DEBUG = 1 सेट किया; कई पृष्ठों के शीर्ष पर और उनके बीच स्विच किया गया। मेरे सिर में थकान से, सब कुछ मिलाया गया, और अंत में मैंने किसी तरह साइट के सबसे महत्वपूर्ण पृष्ठ पर एक डिबगिंग चर जोड़ा, जिसे उपयोगकर्ता "पे नाऊ" बटन पर क्लिक करने के तुरंत बाद देखते हैं, और इस रूप में साइट के कामकाजी संस्करण पर अपलोड किया जाता है।

अगली सुबह मैं जल्दी घर से निकल गया, और रात 9 बजे लौटा, मुझे उत्तर देने वाली मशीन पर 12 संदेश मिले, एक और कष्टप्रद, और बहुत अधिक ई-मेल। लगभग 20 घंटों तक, "पे नाउ" पर क्लिक करने वाले उपयोगकर्ताओं को निम्नलिखित कुछ दिखाई दिया:

मैंने त्रुटि को ठीक करने में केवल 10 सेकंड का समय बिताया, लेकिन ग्राहक को मिस्ड ऑर्डर के पूरे दिन के लिए माफी माँगने में बहुत अधिक समय लगा।

सबक सीखा

मैंने इस मामले पर विचार किया और पाया कि यह इस प्रकार है:
1. देर रात तक काम करने से बचें
2. हर बार जब मैं आदेश प्रसंस्करण में भी मामूली बदलाव करता हूं तो पूर्ण परीक्षण आयोजित करता हूं
3. सुनिश्चित करें कि डिबग रिपोर्ट कभी भी किसी लाइव साइट पर दिखाई न दें
4. आपातकालीन स्थिति के लिए ग्राहक को संपर्क जानकारी प्रदान करें।

सावधान डिबगिंग

तीसरे बिंदु के संबंध में, मैंने कई कार्य लिखे ताकि डिबगिंग संदेशों का प्रदर्शन केवल मेरे लिए प्रदर्शित हो:

 function CanDebug() { global $DEBUG; $allowed = array ('127.0.0.1', '81.1.1.1'); if (in_array ($_SERVER['REMOTE_ADDR'], $allowed)) return $DEBUG; else return 0; } function Debug ($message) { if (!CanDebug()) return; echo '<div style="background:yellow; color:black; border: 1px solid black;'; echo 'padding: 5px; margin: 5px; white-space: pre;">'; if (is_string ($message)) echo $message; else var_dump ($message); echo '</div>'; } 

$ अनुमत सरणी में स्थानीय परीक्षण (127.0.0.1) और एक बाहरी आईपी के लिए मेरा आईपी पता है।
अब मैं चीजों को आउटपुट कर सकता हूं:

 $DEBUG = 1; Debug ("The total is now $total"); //about a debugging message Debug ($somevariable); //output a variable Debug ("About to run: $query"); //before running any database query mysql_query ($query); 

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

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

 if (CanDebug()) {ini_set ('display_errors', 1); error_reporting (E_ALL);} else {ini_set ('display_errors', 0); error_reporting (E_ALL & ~E_NOTICE);} 

डिबगर

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

 ini_set ('xdebug.collect_params', 1); xdebug_start_trace ('/tmp/mytrace'); echo substr ("This will be traced", 0, 10); xdebug_stop_trace(); 

यह कोड /tmp/mytrace.xt फ़ाइल में सभी फ़ंक्शन कॉल और उनके मापदंडों को पंजीकृत करता है, जो इस तरह दिखता है:

Xdebug किसी भी PHP चेतावनी या त्रुटि के बारे में बहुत अधिक जानकारी दिखाता है। हालाँकि, इसे सर्वर पर इंस्टॉल किया जाना चाहिए, इसलिए यह अधिकांश होस्टिंग कंपनियों के लिए संभव नहीं है।
दूसरी ओर, FirePHP एक PHP लाइब्रेरी के रूप में काम करती है, जो Firebug addon के साथ इंटरैक्ट करती है। आप PHP से सीधे डीबगिंग जानकारी को फायरबग कंसोल पर आउटपुट कर सकते हैं - फिर से, यह उपयोगकर्ता के लिए अदृश्य है।
दोनों विधियों में, उपरोक्त कैनडबग की तरह एक फ़ंक्शन अभी भी उपयोगी है ताकि स्टैक के निशान और लॉग फाइलें बनाने से प्रत्येक फायरबग मालिक तक पहुंच न हो।

डिबग मोड को बंद करें

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

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

 function SendEmail ($to, $from, $subject, $message) { if (CanDebug() >= 10) Debug ("Would have emailed $to:\n$message"); else { if (CanDebug()) {$subject = "Test to $to: $subject"; $to = "test@test.com";} mail ($to, $subject, $message, "From: $from"); } } 

अगर मैंने $ DEBUG = 1 सेट किया, तो स्क्रिप्ट ने परीक्षण पते पर ईमेल (सभी 20 हजार) भेजे, जिसे मैं जांच सकता था। अगर मैंने $ DEBUG = 10 सेट किया, तो उसने मुझे सूचित किया कि वह एक ई-मेल भेजने की कोशिश कर रहा है, लेकिन वास्तव में उसने कुछ भी नहीं भेजा। स्क्रिप्ट शुरू करने के कुछ समय बाद ही समस्याएं शुरू हो गईं। मुझे लगता है कि वह लगातार 20,000 बार कम प्रदर्शन वाली सूचना प्रसंस्करण के कारण स्मृति से बाहर भाग गया। कुछ बिंदु पर, मैंने किसी प्रकार की त्रुटि को ठीक करने में देरी की, अपने $ DEBUG चर (या मेरा बाहरी आईपी गलत समय पर बदल गया) के बारे में भूल गया और गलती से 20 हजार लोगों को पत्र भेजे।

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

सबक सीखा

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

PHP रिक्त पृष्ठ

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

 function TestMe() {TestMe();} TestMe(); 

सर्वर पर Apache और PHP के ब्राउज़र और संस्करणों के आधार पर, आपको एक रिक्त पृष्ठ प्राप्त हो सकता है, "यह वेब पेज उपलब्ध नहीं है," स्मृति की कमी के कारण एक महत्वपूर्ण त्रुटि, या "सहेजें" या "ओपन" पृष्ठ वाक्य:

यह अनिवार्य रूप से अनंत पुनरावृत्ति का कारण बनता है, जो स्मृति और / या सर्वर थ्रेड क्रैश की कमी का कारण बन सकता है। यदि यह काम करना बंद कर देता है, तो त्रुटि लॉग में एक छोटा सा निशान रह सकता है:
[सोम जून ०६:२४:१० २०११] [नोटिस] बच्चा 19१ ९ २
निकास संकेत विभाजन दोष (11)
यह हमें संकेत देता है कि त्रुटि कहां और क्यों हुई है। और विभिन्न स्थानों में आउटपुट लाइनों को जोड़ने के साथ सभी त्वरित डिबगिंग के तरीके एक विशेष परिणाम नहीं देंगे, क्योंकि जब तक समस्या कोड निष्पादित नहीं किया जाता है, तब तक पूरा पृष्ठ काम नहीं करेगा। असल में, यह इस तथ्य के कारण है कि PHP उत्पन्न HTML को केवल समय-समय पर ब्राउज़र को भेजता है। इसलिए, बहुत सारे भावों को जोड़ना (); कम से कम आपको दिखाते हैं कि पुनरावर्ती त्रुटि से पहले आपकी स्क्रिप्ट ने क्या किया।
बेशक, इस त्रुटि का कारण कोड ऊपर दिखाए गए की तुलना में बहुत अधिक परिष्कृत हो सकता है। इसमें ऐसी विधियाँ शामिल हो सकती हैं जो कक्षाओं को अन्य कक्षाओं में बुलाती हैं जो मूल कक्षाओं में वापस आती हैं। और यह त्रुटि केवल परिस्थितियों को पुन: उत्पन्न करने के लिए मुश्किल में हो सकती है, और केवल इसलिए कि आपने कहीं और कुछ बदल दिया है।

सबक सीखा

1. पता है कि कुछ भी लिखे जाने की स्थिति में त्रुटि लॉग का स्थान।
2. ऐसी स्थितियों में, Xdebug जैसे स्टैक-ट्रेसिंग डिबगर बहुत उपयोगी हो सकते हैं।
3. अन्यथा, सभी कोड के माध्यम से जाने के लिए एक टन का समय बचाएं, लाइन द्वारा लाइन करें, और अनावश्यक भागों पर टिप्पणी करें जब तक कि यह काम न करे।

अमान्य चर प्रकार

यह त्रुटि अक्सर डेटाबेस में होती है। यदि ये SQL स्टेटमेंट दिए गए हैं ...

 CREATE TABLE products ( id INT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(60), category VARCHAR(10), price DECIMAL(6,2) ); INSERT INTO products VALUES (1, 'Great Expectations', 'book', 12.99); INSERT INTO products VALUES (2, 'Meagre Expectations', 'cd', 2.50); INSERT INTO products VALUES (3, 'Flared corduroys', 'retro clothing', 25); 

... अनुमान करें कि यदि आप निम्नलिखित चलाते हैं तो क्या होगा?

 SELECT * FROM products WHERE category='retro clothing'; 

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

 ALTER TABLE products MODIFY category VARCHAR(30); UPDATE products SET category='retro clothing' WHERE category='retro clot'; 

मैंने अपनी पहली प्रमुख ई-कॉमर्स साइट पर काम करते समय एक और अधिक गंभीर गलती की। आदेश देने की प्रक्रिया के अंत में, साइट ने ग्राहक को क्रेडिट कार्ड विवरण दर्ज करने के लिए कहा और फिर एक जावा प्रोग्राम को कॉल किया जिसने बार्कलेज ePDQ को भुगतान अनुरोध भेजा। राशि की गणना पेंशन में की गई थी। मैं जावा से परिचित नहीं था, इसलिए मैंने आधार कोड के नमूने के रूप में लिया, जो इस राशि का प्रतिनिधित्व करता था
छोटा कुल;
जावा प्रोग्राम कमांड लाइन से मंगाया गया था। यदि वह कुछ भी नहीं लौटाती है, तो लेनदेन को पूरा माना जाता है, ग्राहक को एक ई-मेल मिला और आदेश पूरा हो गया। यदि क्रेडिट कार्ड की जाँच करते समय कोई त्रुटि हुई, तो प्रोग्राम ने "कार्ड अधिकृत नहीं है" या "कार्ड विफल प्रमाणीकरण" जैसे संदेश लौटा दिए।
लघु पूर्णांक -32768 और +32767 के बीच मान संग्रहीत कर सकते हैं। ये संख्या बहुत बड़ी लग रही थी। लेकिन मैंने इस तथ्य पर ध्यान नहीं दिया कि राशि की गणना पेंस में की गई थी, पाउंड में नहीं, यानी सबसे बड़ी संभव राशि £ 327.67 थी। और सबसे बुरी बात यह है कि यदि आदेश राशि इससे अधिक थी, तो जावा प्रोग्राम ने बस काम करना बंद कर दिया और कुछ भी वापस नहीं किया। यह पूरी तरह से एक सफलतापूर्वक पूरा हुआ आदेश जैसा लग रहा था, और फिर खरीद प्रक्रिया हमेशा की तरह चली गई। कई बड़े अवैतनिक आदेशों के बाद, त्रुटि को या तो लेखा विभाग द्वारा देखा गया, या एक सतर्क और ईमानदार खरीदार द्वारा, कुछ महीनों बाद।

सबक सीखा

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

"एक पैसा की त्रुटियाँ"

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

 <script type="text/javascript"> function GetMoney (amount) {return Math.round (amount * 100) / 100;} </script> 

हालांकि, यह जल्द ही स्पष्ट हो गया कि 1.20 जैसी मात्रा 1.2 के रूप में स्क्रीन पर प्रदर्शित की गई थी, जो कि अव्यवसायिक लग रही थी। इसलिए मैंने कोड को इस तरह से बदल दिया:

 <script type="text/javascript"> function GetMoney (amount) { var pounds = Math.floor (amount); var pence = Math.round (amount * 100) % 100; return pounds + '.' + (pence < 10 ? '0' : '') + pence; } </script> 

मुख्य अंतर अंतिम पंक्ति में एक अतिरिक्त 0 है। लेकिन अब चूंकि पेनी की अलग से गणना की जाती है, मात्रा को 100 से विभाजित करने पर शेष प्राप्त करने के लिए% ऑपरेटर की आवश्यकता होती है। ऐसी विषम परिस्थितियों को खोजने की कोशिश करें कि यह कोड त्रुटि का कारण बनेगा।
यह उस साइट पर हुआ जहां उन्होंने मोतियों की बिक्री की। तब मुझे पता चला कि मोतियों को विभिन्न रूपों और मात्राओं में बेचा जा सकता है, जिसमें भिन्नात्मक मूल्यों वाले कस्टम मिश्रण शामिल हैं। एक बार एक ग्राहक ने £ 4.95 के 1.01 आइटम खरीदे और केवल £ 4.00 का भुगतान किया। चूंकि राशि को 4.9995 के रूप में परिभाषित किया गया था, इसलिए कार्यक्रम ने पेंस को 100, और% 100 को 0 पेंस छोड़ दिया। इस प्रकार, भुगतान की गई राशि घटकर 4 पाउंड हो गई।

गोलाई में एक साधारण दोष, जहां 101 मोतियों के लिए £ 4.95 प्रति सौ पर बेचा गया, उन्होंने £ 5 के बजाय £ 4 का भुगतान किया।
मैंने जल्दी से कोड ठीक किया:

 <script type="text/javascript"> function GetMoney (amount) { var pounds = Math.floor (amount); var pence = Math.floor (amount * 100) % 100; return pounds + '.' + (pence < 10 ? '0' : '') + pence; } </script> 

हालांकि, यह एक अच्छा फिक्स नहीं था, क्योंकि यह 4.9995 से £ 4.99 तक गोल था, जो सर्वर से किसी भी संबंधित गणना के साथ सिंक्रनाइज़ेशन को रोकता था। इससे भी बुरी बात यह थी कि ०. was पाउंड की कीमत के worth. the पाउंड के ऑर्डर के मामले में यह राशि ence० के बजाय ६ ९ पेंस निकली! ऐसा इसलिए था क्योंकि 0.7 में जैसे फ्लोटिंग पॉइंट नंबर बाइनरी में दिखाई देते हैं, बल्कि 0.6999999999999999 पर दिखाई देते हैं, जो बाद में 70 के चक्कर लगाने के बजाय 69 पेंस हो जाएगा।
यह एक वास्तविक "एकल-पैसा गलती" है। इसे ठीक करने के लिए, मैंने शुरुआत में एक और गोलाई जोड़ी:

 <script type="text/javascript"> function GetMoney (amount) { var pence = Math.round (100 * amount); var pounds = Math.floor (pence / 100); pence %= 100; return pound + '.' + (pence < 10 ? '0' : '') + pence; } </script> 

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

 <script type="text/javascript"> function GetMoney (amount) {return amount.toFixed (2);} alert (GetMoney (4.9995) + ' ' + GetMoney (0.1 * 0.7)); </script> 

पेपाल के साथ छूट प्रदान करना

पेपल एक "एकल-पैसा गलती" है जो पंखों में इंतजार कर रहा है। कई साइटें कोड प्रदान करती हैं जो आदेश राशि के एक निश्चित प्रतिशत की छूट देती हैं। इसकी गणना बहुत अंत में की जाती है। यदि आपने 95 पेंस के लिए 2 आइटम का आदेश दिया है, तो कुल राशि £ 1.90 होगी और आपको 19 पेंस की छूट मिलेगी, इसलिए £ 1.71 का भुगतान करें।
हालाँकि, PayPal इस प्रकार की छूट का समर्थन नहीं करता है। यदि आप चाहते हैं कि पेपाल आपकी खरीदारी की टोकरी में वस्तुओं को प्रदर्शित करे, तो आपको उनमें से प्रत्येक की कीमत और मात्रा की अलग से गणना करने की आवश्यकता है:

 <input name="item_name_1" type="hidden" value="My Difficult Product" /> <input name="amount_1" type="hidden" value="0.99" /> <input name="quantity_1" type="hidden" value="1" /> 

इसलिए, आपको प्रत्येक आइटम के लिए अलग से छूट प्राप्त करनी चाहिए। 95 पेंस से 10% की छूट 85.5 पेंस है। पेपाल भिन्नात्मक संख्याओं के साथ काम नहीं करता है, इसलिए आपको उन्हें 86 पेंस पर गोल करने की आवश्यकता है, जो पेपाल में £ 1.72 की कुल राशि देता है। यदि 85p को गोल किया जाता है, तो कुल £ 1.70 होगा।
इस समस्या को हल करने के लिए, मुझे प्रत्येक आइटम के लिए छूट की गणना अलग से करनी होगी। 10% × £ 1.90 की सामान्य गणना के बजाय, कोड हर बार पेंस की पूरी राशि का उपयोग करके आइटम से आइटम पर छूट जमा करता है। $ आइटम मानकर ऑर्डर आइटम का एक PHP सरणी है:

 $discount = 0; $discountpercent = 10; foreach ($items as $item) { $mydiscount = floor ($item->price * $discountpercent) / 100; $item->priceforpaypal = $item->price - $mydiscount; $discount += $mydiscount * $item->quantity; } 

सबक सीखा

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

घड़ी बदल गई

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

 mysql_query ("SELECT * FROM orders WHERE completeddate < '" . date ('Ymd H:i:s', (time() - 7 * 86400 + 600)) . "'") 

मैंने आवर्ती साप्ताहिक आदेश के लिए सिस्टम में एक समान लाइन का उपयोग किया। उसने पिछले हफ्ते किए गए आदेशों का चयन किया, उन्हें दोहराया और वर्तमान सप्ताह के लिए बाहर कर दिया। 86,400 एक दिन में सेकंड की संख्या है, इसलिए समय () - 7 * 86400 एक सप्ताह पहले था, और +600 अतिरिक्त समय के 10 मिनट जोड़ता है।
यह आवर्ती आदेशों को लागू करने की एक कम लागत वाली विधि थी। यदि मेरे पास अधिक समय होता है, तो मैं बार-बार और न दोहराने वाले आदेशों के बीच अंतर करने के लिए एक अलग टेबल और / या शॉपिंग बास्केट बनाऊंगा। यह पता चला कि इस कोड ने कई महीनों तक काम किया और रहस्यमय कारणों से मार्च के अंत में विफल रहा।
दोष के उन्मूलन और इसके परिणामों में बहुत समय लगा, मुझे मैन्युअल रूप से आदेश निष्पादित करना पड़ा। कारण की पहचान करने में और भी अधिक समय लगा, खासकर क्योंकि मुझे पूरी साइट को यह सोचने के लिए मजबूर करना पड़ा कि यार्ड एक और दिन था।
सामान्य तौर पर, मैंने पहले से ही अनुभाग के शीर्षक में कारण के बारे में बात की थी: मैं दिन के उजाले की बचत के लिए घंटों के रूपांतरण को ध्यान में रखना भूल गया था, जब एक सप्ताह 7 * 86400 सेकंड से कम है।
ठीक एक सप्ताह पहले प्राप्त करने के लिए निम्नलिखित तीन तरीकों की तुलना करें। उत्तरार्द्ध सबसे सुरुचिपूर्ण है। मैंने हाल ही में इसे खोजा है:

 $time = strtotime ('28 March 2011 00:01'); echo date ('Ymd H:i:s', ($time - 7 * 86400)) . '<br/>'; echo date ('Ymd H:i:s', mktime (date ('H', $time), date ('i', $time), 0, date ('n', $time), date ('j', $time) - 7, date ('Y', $time))); echo date ('Ymd H:i:s', (strtotime ('-1 week', $time))) . '<br/>'; 

सबक सीखा

ऐसी त्रुटि से सामान्य निष्कर्ष निकालना मुश्किल है, लेकिन एक निश्चित सबक सीखा गया है:
1. कुछ दोहराए जाने वाली साइटों पर, समय ज़ोन और घड़ी को ध्यान में रखना न भूलें।
2. फिर से, पहिया को सुदृढ़ न करें।

निष्कर्ष

प्रोग्रामिंग में त्रुटियां कई आकारों और आकारों में आती हैं। इस लेख में, वे बहुत स्पष्ट विफलताओं से लेकर अविश्वसनीय रूप से सूक्ष्म मिसकल्चुलेशन तक हैं। और ऐसा लगता है कि ये सभी मर्फी के नियम की पुष्टि करते हैं: यदि परेशानी हो सकती है, तो यह होगा।

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

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