क्या डेड कोड उपयोगी है?

16

क्या आपको डेड कोड लिखना उपयोगी लगता है?

कुछ का कहना है "यदि आपके पास कुछ ऑपरेशन करने के लिए 2 तर्क हैं तो अन्य तर्क कोड टिप्पणी करने या कोड हटाने के बजाय इसे मृत कोड बना दें क्योंकि यह ऑपरेशन को प्रभावित नहीं करेगा।"

उदाहरण:-

if(true){
    // logic - 1
} else {
    // logic - 2  // dead code
}

क्या यह सच है?

मैं आमतौर पर मृत कोड नहीं लिखता, इसके बजाय मैं सिर्फ दूसरा तर्क निकालता हूं।

java

— हैरी जॉय
स्रोत

6

इसे जटिल क्यों बनाया जा रहा है। बस इसे निकालने के लिए, बस KISS

— जिगर जोशी

1

मुझे यह बात दिखाई नहीं देती ...

— फिल

13

सामान की एक अनंतता है जो मैं नहीं चाहता कि मेरा कार्यक्रम हो। आप कैसे तय करते हैं कि दूसरी शाखा में क्या रखा जाए?

— पॉल कसाई

4

मैंने इसका उपयोग कोड के उन हिस्सों का परीक्षण करने से पहले किया है जो सामान्य ऑपरेशन में एक मार्ग को इंजीनियर करना मुश्किल होगा (फिर रिलीज के लिए स्थिति बदल रहा है) लेकिन मैं शुरू से जानबूझकर इस कोड को लिखने से कोई लाभ नहीं देख सकता: - यह पाठक को भ्रमित करता है, यह कोड को ब्लॉट करता है और निश्चित रूप से इसे गति नहीं देगा!

— मैट विल्को

1

बस एक टिप्पणी जो कोड पिछले कोड परिवर्तनों को संग्रहीत करने का स्थान नहीं है। स्रोत नियंत्रण क्या है।

— फंकीमुशरूम

67

IMO, यह व्यर्थ से भी बदतर है।

समय की बर्बादी होने के अलावा, यह आपको (या अगले आदमी) भ्रम देता है कि आपको कुछ कोड मिला है जो आपके द्वारा परिवर्तित किए trueजाने पर काम करेंगे false। यह केवल एक भ्रम है ... जब तक आप इसका परीक्षण नहीं करते।

और अगर बेशक, यह अव्यवस्था है जो कोड को पढ़ने के लिए कठिन बना देता है।

— स्टीफन सी
स्रोत

7

+1 "व्यर्थ से बदतर" के लिए। यह एक बग होने की प्रतीक्षा कर रहा है। यह जटिलता को जोड़ता है जहां इसकी आवश्यकता नहीं है। कोड को समझने में अतिरिक्त समय लगता है।

— आहारबुद्ध

13

यदि आप किसी भी प्रकार के SCM डेड कोड का उपयोग करते हैं तो शायद ही कभी उपयोगी हो। आपको इसके बजाय इसे हटाना चाहिए और यदि आपको कभी तर्क 2 के कोड को देखने की आवश्यकता हो तो आप इसे SCM रिपॉजिटरी से पुनः प्राप्त करते हैं।

संपादित करें:

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

यदि आप एक विधि को हटाते हैं, तो इसे "लाइव" कोड द्वारा उपयोग नहीं किया जा सकता है, लेकिन केवल मृत कोड द्वारा, आपको या तो अपना मृत कोड बदलना होगा (या संभावित रूप से विराम) या अन्य विधि को मृत कोड बनाना होगा।

अंत में आप निश्चित रूप से किसी न किसी प्रकार के रखरखाव नरक में समाप्त हो जाएंगे।

इस प्रकार, सबसे अच्छा कोड हटा दिया गया कोड है, क्योंकि यह गलत परिणाम नहीं दे सकता है या रखरखाव को विचलित नहीं कर सकता है। :)

— थॉमस
स्रोत

आप यह कैसे जान सकते हैं कि यह भंडार में मौजूद है, हालांकि?

— माइकल बोर्गवर्ड

@ मिचेल आपके पास सामान्य रूप से रिपॉजिटरी टिप्पणियाँ या किसी प्रकार के प्रलेखन हैं जहां आप उस कोड के अस्तित्व पर एक संकेत दे सकते हैं।

— थॉमस

8

नहीं, यह बुरा है, क्योंकि यह आपके कोड को बंद कर देता है और स्थिरता को कम कर देता है।

आमतौर पर, वैकल्पिक "लॉजिक्स" में से एक को पसंद करने का एक स्पष्ट कारण है। इस कारण (और एक अस्वीकृत विकल्प के अस्तित्व) को एक कोड टिप्पणी में प्रलेखित किया जाना चाहिए। अपेक्षाकृत अप्रत्याशित घटना में कि कारण अमान्य हो जाता है, वैकल्पिक कोड को रिपॉजिटरी इतिहास (यदि यह पहले से पसंद किया गया, लागू किया गया समाधान है) से पुनर्प्राप्त किया जा सकता है, या पूर्ण वर्तमान ज्ञान और आवश्यकताओं का उपयोग करके कार्यान्वित किया जाता है (यदि यह सिर्फ एक अस्पष्ट है) विचार)।

— माइकल बोर्गवर्ड
स्रोत

4

यह ऑपरेशन को प्रभावित नहीं करता है लेकिन यह रखरखाव को प्रभावित करता है। आप कोड को यथासंभव सरल बनाए रखना चाहते हैं।

— पीटर लॉरी
स्रोत

4

मैं ईमानदारी से उलझन में हूँ कि आप क्या कर रहे हैं।

अवरोही प्राथमिकता के क्रम में:

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

कारण यह है कि मुझे लगता है कि यह बहुत अधिक है: संदेह होने से (अक्सर सही ढंग से) कि लोग वास्तव में स्रोत नियंत्रण इतिहास पढ़ेंगे यदि उन्हें कोई समस्या है; डरने से नया कोड काम नहीं करेगा और एक आसान प्रत्यावर्तन विकल्प चाहिए। आप दोनों को पूरा करने का प्रयास करने के लिए एक समझौता हो सकता है "टिप्पणी की गणना करने के लिए बदल ... पर (तिथि)। यदि कोई समस्या है, तो पुराने संस्करण को स्रोत नियंत्रण में देखें" या समान।

— जैक वी।
स्रोत

3

नहीं, यह उपयोगी नहीं है। वह elseब्लॉक किसी उद्देश्य को पूरा नहीं करता है। यदि आप अनिश्चित हैं कि किस कार्यान्वयन का उपयोग करना है, तो टिप्पणी करें, अलग कक्षाएं बनाएं या इसे कहीं और सहेजें। इसके अलावा, ज्यादातर आपके पास - या कम से कम होना चाहिए - आपके स्रोत फ़ाइलों का स्थानीय या दूरस्थ इतिहास।

— ऊंचे पहाड़
स्रोत

1

अगर वास्तव में या तो बहुत उद्देश्य नहीं है! अगर (सच) प्रभाव में नहीं है

— Zachary K

यकीन है, यह सही है।

— अल्प

3

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

यदि आप दो कोड विकल्पों के बीच जल्दी से स्विच करने में सक्षम होना चाहते हैं, तो आप निम्नलिखित सुविधाजनक टिप्पणी निर्माण का उपयोग कर सकते हैं:

//*
alternative 1 is active
/*/
alternative 2 is commented out
//*/

यदि आप /पहली टिप्पणी लाइन में केवल पहली हटाते हैं तो यह बन जाती है:

/*
alternative 1 is commented out
/*/
alternative 2 is active
//*/

इसके साथ आप केवल एक को जोड़कर या हटाकर विकल्पों के बीच स्विच कर सकते हैं / कोड में केवल ।

यह पहली बार में थोड़ा अजीब लग सकता है लेकिन एक बार जब आप इसके आदी हो जाते हैं तो आप इसे आसानी से किसी तरह के पैटर्न के रूप में पहचान लेंगे।

आप इसे चेन भी कर सकते हैं और इस प्रकार एक ही बार में कई ब्लॉक स्विच कर सकते हैं:

//*
first block of code for alternative 1
/*/
first block of code for alternative 2
/*/
second block of code for alternative 1
/*/
second block of code for alternative 2
//*/

मैं इसे इस तरह से उपयोग नहीं करता, लेकिन यह काम करता है।

— रेव्स , 2 उपयोगकर्ता 68% x4u
स्रोत

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

— रोमन ग्रेजडान

यह और अधिक स्पष्ट लग रहा था, जबकि यह सवाल अभी भी स्टैक्वेरफ्लो पर था जिसने टिप्पणियों को सही ढंग से उजागर किया था।

— x4u

1

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

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

— डेव
स्रोत

यह वही है जो README फाइल के लिए है

— Wipqozn

0

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

— टॉम जेफ़री
स्रोत

0

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

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

— Dysaster
स्रोत

0

मैं तुरंत ऐसी स्थिति के बारे में नहीं सोच सकता जहाँ मुझे मृत कोड लिखना उपयोगी लगा। यदि वैकल्पिक एल्गोरिदम हैं, तो:

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

किसी भी स्थिति में, आप कोई मृत कोड नहीं रखते हैं।

— जोनाथन लेफ़लर
स्रोत

0

यदि आप अपने मृत कोड को हटाते या टिप्पणी नहीं करते हैं, तो आपको संकलक त्रुटियों से बचने के लिए इसे बनाए रखना होगा। यह समय बर्बाद किया है। यदि आपके पास SCM है तो इसे हटा दें।

— rockeye
स्रोत

क्या एससीएम एसवीएन के समान है? यदि नहीं, तो हमारे पास एससीएम नहीं है। हमारे पास एसवीएन है।

— हैरी जॉय

1

SCM का अर्थ है सोर्स कोड मैनेजमेंट ( en.wikipedia.org/wiki/Source_Code_Management )। यदि आपके पास SVN है, तो आपके पास SCM है! ;)

SCM वास्तव में सॉफ्टवेयर कॉन्फ़िगरेशन प्रबंधन का मतलब है। यदि आपके पास SVN है, जिसका अर्थ है कि आपके पास संस्करण नियंत्रण है, तो आपके पास SCM है या नहीं, यह एक और प्रश्न है।

— मुलायम

3

@Pratik: नहीं, SCM का वास्तव में मतलब सॉफ्टवेयर चेनसॉ नरसंहार है। अन्यथा सोचना मूर्खतापूर्ण है। स्रोत कोड प्रबंधन, या सॉफ़्टवेयर कॉन्फ़िगरेशन प्रबंधन, या आपूर्ति श्रृंखला प्रबंधन के रूप में ऐसी कोई भी साइटलाइन नहीं है। एससीएम का सही अर्थ सॉफ्टवेयर चेनसॉ नरसंहार, अवधि है।

— रेयान

सॉफ्टवेयर काइंसॉ या सॉफ्टवेयर नरसंहार?

— रोमन ग्रेजडान

0

नहीं

कुछ प्रोग्रामर इस शैली का उपयोग टिप्पणियों के विकल्प के रूप में करते हैं और इसे सुरुचिपूर्ण पाते हैं।

if (1 == 0) 
{
    std::cout <<"I am a dead code capable of resurrection, once a programmer changes the condition!";
}

— setzamora
स्रोत

0

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

जिस समय मुझे कुछ लिखना था, वह कंपाइलर बग के लिए एक काम के रूप में था, यह कंपाइलर विक्रेता द्वारा इस काम का उपयोग करने के लिए भी सिफारिश की गई थी।

— tehnyit
स्रोत

0

क्या आप लिखने वाले डेड कोड का परीक्षण करते हैं? कुछ भी करने की पुष्टि करें कि यह शायद अच्छा है? यदि नहीं, तो इससे छुटकारा पाएं।

भविष्य के कोड परिवर्तन के लिए, क्या आप यह सत्यापित करने जा रहे हैं कि मृत कोड अभी भी काम करता है? यदि नहीं, तो इससे छुटकारा पाएं।

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

टिप्पणी-आउट कोड (या, सी या सी ++, #ifdefएड आउट कोड) रखने के कारण हो सकते हैं , लेकिन यह टिप्पणियों के साथ होना चाहिए कि यह अभी भी क्यों है और यह किस उद्देश्य से कार्य करता है।

— डेविड थॉर्नले
स्रोत

0

ध्यान दें कि जावा में, निम्नलिखित अनुपलब्ध कोड के कारण भी संकलन नहीं करेगा:

int someFunc() {
    return 10;
    int x = 12;
    return x;
}

आदर्श रूप से, यदि आपके कोड में कुछ गड़बड़ है, तो आप इसे जल्द से जल्द ढूंढना चाहते हैं, बजाय इसे उत्पादन में जाने के और अपने उपयोगकर्ताओं द्वारा पाया जाना चाहिए।

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

आप तर्क दे सकते हैं कि मृत कोड तक नहीं पहुंचा जा सकता है, इसलिए समस्याएँ पैदा नहीं हो सकती हैं, लेकिन कुछ टिप्पणी, ब्रेसिंग और इंडेंटेशन में गड़बड़ी हो सकती है जो ऐसा हो सकता है।

— पॉल कसाई
स्रोत

साथ ही C # में यह कंपाइल होगा, लेकिन एक चेतावनी प्रदर्शित करेगा।

— मॉर्गन हेरलॉकर

0

लोग कुछ पुराने तर्क बताते हैं क्योंकि वे कोड में बड़े बदलाव करने से डरते हैं। और वास्तव में, एक हफ्ते बाद यह महसूस करना कि पुराना कोड वास्तव में सही था और अब आपको इसे स्क्रैच से लिखना होगा, एक कुतिया है। लेकिन यही स्रोत नियंत्रण के लिए है। यदि आप कुछ तर्क बदलने का निर्णय लेते हैं, तो कुछ हद तक काम कर रहे वर्तमान कोड को खोने से डरें नहीं। इसे निकालें और अपने SVN / Git / TFS को आपके लिए संस्करण बनाने का ध्यान रखें।

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

— Dyppl
स्रोत

0

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

लोग अपने कोड को संक्षिप्त रखने और कोडबेस को बहुत बड़ा बनने से रोकने के लिए बहुत कुछ कर रहे हैं, अक्सर प्रदर्शन को त्यागने से भी (जहां यह ज्यादा मायने नहीं रखता है)। तो, क्या आप वास्तव में सोचते हैं कि मृत कोड की 100 लाइनें एक अच्छी बात हो सकती हैं?

— Dyppl
स्रोत

0

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

— सुबु शंकर सुब्रमण्यन
स्रोत

0

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

यह महत्वपूर्ण रूप से महत्वपूर्ण है कि त्रुटि संदेश कुछ इस तरह का है "दहशत: हम कभी भी फ़ाइल% s में लाइन% d पर यहाँ नहीं होना चाहिए ..."

— हैक कर लिया
स्रोत