क्या हमें झूठे कोड की तलाश में रहना चाहिए?

Question

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

क्या हमें झूठे कोड की तलाश में रहना चाहिए, इसकी तुलना किसी मौजूदा दस्तावेज़ से की जाए? या क्या यह आमतौर पर इसके लिए सबसे अच्छा स्रोत है जो इसे करने की आवश्यकता है? यदि यह चुस्त कोड है, तो क्या यह झूठ होने की संभावना कम है, या क्या वह कोड बिल्कुल झूठ नहीं हो सकता है?

Comments

क्या आप स्पष्ट कर सकते हैं कि "झूठ" से आपका क्या मतलब है? हमें आपका संदर्भ पाने के लिए किसी अन्य प्रश्न में टिप्पणियों का उल्लेख नहीं करना चाहिए।

— user16764

@ user16764 दूसरे धागे को देखे बिना, पहली बात यह है कि दिमाग में पॉप करने के लिए सबसे पहले अंडरहैंड सी कॉन्टेस्ट है

— इजाका

यदि प्रलेखन कहता है कि कोड को फू करना चाहिए, और कोड बार करता है, तो क्या इसका मतलब यह है कि कोड क्या होना चाहिए? या क्या हम मान रहे हैं कि बार सही कार्रवाई है क्योंकि हमने कभी दस्तावेज नहीं पढ़ा, क्योंकि कोड हमेशा सही होता है?

— thursdaysgeek

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

— thursdaysgeek

Answer 1

आम आदमी के शब्दों में:

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

कई तरीके कोड झूठ बोल सकते हैं, जिनमें से मैं सिर्फ कुछ का उल्लेख करूंगा:

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

जितना छोटा होता है, उतना कम होता है। यह स्वयं स्पष्ट है।

यह कोड जितना जटिल है, उतना ही पारदर्शी भी है। तो यह कम झूठ है।

आर्कियन सिंटेक्स ट्रिक्स बहुत झूठ बोलते हैं। स्पष्ट, चरण-दर-चरण एल्गोरिदम को प्राथमिकता दें। वे कम झूठ बोलते हैं।

एक अच्छा स्थिर कोड विश्लेषण टूल आपको झूठ बोलने वाले कोड को खोजने में मदद कर सकता है।

साथ ही एक अच्छी स्वचालित परीक्षण बैटरी कोड को सच बताने में मजबूर करती है।

Comments

The shorter and terser the code is, the less it lies. It's self evident. मैं शायद ही ऐसा कहूंगा। मेरे अनुभव में, कोड जितना छोटा और निडर होता है, उतने अधिक अवसर उसे गलीचा के नीचे झूठ बोलना पड़ता है, आम तौर पर उन्हें भ्रामक फ़ंक्शन कॉल में छिपाकर।

— मेसन व्हीलर

@MasonWheeler आप सही हैं। मैंने "terse" भाग को संपादित किया।

— ट्यूलेंस कोर्डोवा

मैं "बिना नामकरण वाले झूठ के साथ कोड" से आश्वस्त नहीं हूं। यह निश्चित रूप से बुरा है, लेकिन अगर यह आपको कुछ नहीं बता रहा है तो यह झूठ कैसे हो सकता है? "मुझे आपको नहीं बताना है!" हठपूर्वक अवरोधी और असंयमी है लेकिन भ्रामक नहीं है। निश्चित रूप से "झूठ" तब होता है जब एक नामकरण सम्मेलन मौजूद होता है, लेकिन इसका उपयोग उस तरीके से किया जाता है जो कोड से वास्तव में मेल नहीं खाता है - उदाहरण के लिए यदि आप हंगेरियन (yuck!) का उपयोग कर रहे हैं, लेकिन कभी-कभी pएक चर के लिए उपसर्ग होता है! पॉइंटर नहीं है

— स्टीव 314

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

— स्टीव 314

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

— जस्टिन सी सी

Answer 2

कोड झूठ नहीं बोल सकता।

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

कोड निश्चित रूप से गलत हो सकता है । यह निश्चित रूप से इसके नामकरण या संगठन में भ्रामक हो सकता है। यह निश्चित रूप से अपठनीय हो सकता है।

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

Comments

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

— स्टीव 314

क्षमा करें, लेकिन "लेकिन यह काफी हद तक सही था" का मतलब यह नहीं है कि आपको झूठा नहीं कहा जा सकता है - भले ही लोग बहस न करें, फिर भी वे इसे जानते हैं।

— स्टीव

@ steve314 - pssh। मूल प्रश्न टिप्पणियों के आसपास था। इन दुर्लभ परिदृश्यों के लिए एक पुआल आदमी का निर्माण करना जहां टिप्पणी के पक्ष में बहस करने के लिए कोड को भ्रामक रूप से नाम दिया गया है (और टिप्पणियों के अब तक के सामान्य परिदृश्य की अनदेखी करना) बेतुका है।

— तेलस्टीन

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

— स्टीव ३४

@Telastyn मैं अनुमान लगा रहा हूँ कि आपने कभी भी फ़िल्टर नहीं किया है एक रीडायरेक्ट जिसके कारण वास्तव में व्हाट्सएप पर एक स्टेप-थ्रू हुआ है और फिर उस विधि से कोड में नहीं जाना है, कभी वापस नहीं आना है, क्या आपके पास है? भगवान मैं नफरत करता हूँ! @ # $ जावा देवता जावा के साथ करते हैं।

— एरिक रेपेन

Answer 3

आप कई सवाल पूछते हैं।

क्या हमें झूठ बोलने वाले कोड की तलाश में होना चाहिए?

बेशक!

क्या हमें किसी मौजूदा दस्तावेज़ के खिलाफ [कोड] की तुलना करनी चाहिए?

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

या [कोड] आमतौर पर इसके लिए सबसे अच्छा स्रोत है कि उसे क्या करने की आवश्यकता है?

यह हमेशा यह क्या के लिए सबसे अच्छा स्रोत है है कर। क्या कोड होना चाहिए के लिए सबसे अच्छा स्रोत (हालांकि) अलग-अलग चीजों का एक संयोजन हो सकता है, मुख्य हैं:

• कोड ही;
• कॉलिंग कोड;
• उस कोड में टिप्पणियाँ;
• प्रलेखन;
• इकाई परीक्षण;
• एकीकरण और प्रतिगमन परीक्षण;
• प्रोग्रामर;
• अंतिम उपयोगकर्ता;

जो "सबसे अच्छा" स्रोत है (या उसके संयोजन) आपकी स्थिति पर निर्भर करता है।

यदि यह चुस्त कोड है, तो क्या यह झूठ होने की संभावना कम है, या क्या वह कोड बिल्कुल झूठ नहीं हो सकता है?

मुझे यकीन नहीं है कि आप "चुस्त कोड" से क्या मतलब है, AFAIK "चुस्त" आमतौर पर कोडिंग प्रक्रिया को संदर्भित करता है। मान लें कि "एक चुस्त प्रोग्रामिंग प्रक्रिया में बनाया गया कोड" तो मुझे लगता है कि यह कहना सुरक्षित है कि यह अभी भी झूठ हो सकता है। झूठ बोलना कितना संभव है, उदाहरण के लिए, जलप्रपात शैली की परियोजनाओं में बनाए गए कोड की तुलना में एक व्यक्तिपरक मामला है (व्यक्तिगत रूप से मुझे नहीं लगता कि एक बड़ा संबंध है)।

---

फुटनोट
उपरोक्त सभी इस धारणा के तहत है कि कोड झूठ हो सकता है, और यह एक बुनियादी (हालांकि थोड़ा विवादित) उदाहरण है:

public int DivideByTwo(int input) 
{
    return input / 3;
}

यह सिर्फ एक उदाहरण है जहां मैं "कोड झूठ" कहूंगा, @ user61852 में कुछ अन्य (अनुपलब्ध कोड, कोड की जटिलता समस्या की जटिलता का मिलान नहीं करना, बुरा नामकरण) है, और मुझे लगता है कि कई और भी हैं। विकिपीडिया में कुछ हद तक झूठ का एक अच्छा सारांश है , उनमें से कई कोड पाए जा सकते हैं।

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

Answer 4

if (x > 5) {
  doSomething();
} else {
  doADifferentThing();
}

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

इसके अलावा, संकलक ने इस पर ध्यान दिया हो सकता है, और कोड के इस ब्लॉक को बस के साथ बदल दिया है

doSomething()

यदि doADifferentThing को आपके प्रोग्राम में कहीं और नहीं बुलाया गया है, तो इसे प्रोग्राम से पूरी तरह से हटाया जा सकता है।

यदि आपकी भाषा assertकिसी प्रकार का समर्थन करती है, जिसे उत्पादन में बंद कर दिया जाता है, तो प्रत्येक assertकथन संभावित रूप से एक झूठ है। एक टाइपकास्ट एक और जोर है जो झूठ हो सकता है।