क्या ऐसी भाषा जो टिप्पणियों को अधिक पठनीय कोड नहीं देती है? [बन्द है]

Question

जिज्ञासा से बाहर, मैं सोच रहा था कि क्या एक ऐसी भाषा जो टिप्पणियों की अनुमति नहीं देती है और अधिक पठनीय कोड प्राप्त होगा, क्योंकि आपको आत्म-टिप्पणी कोड लिखने के लिए मजबूर किया जाएगा।

तो फिर, आप बस के रूप में पहले के रूप में बुरा कोड लिख सकते हैं क्योंकि आप सिर्फ परवाह नहीं है। लेकिन आपकी क्या राय है?

Comments

क्या आपको लगता है कि उन भाषाओं के बीच कोई अंतर है जो टिप्पणियों और डेवलपर्स को अनुमति नहीं देता है जो उनका उपयोग नहीं करते हैं?

— जेरेमी हेइलर

टिप्पणियों को अस्वीकार करने का विचार डेवलपर्स को अधिक स्व-दस्तावेजीकरण कोड लिखने के लिए मजबूर करेगा ।

— एडम क्रॉसलैंड

@Jeff जो एक IDE / एडिटर फीचर है, लैंगुगे फीचर IMHO

— jk नहीं।

im यकीन नहीं है कि डेवलपर्स को कुछ भी करने के लिए मजबूर करना संभव है

— jk।

@Adam @ jk01: वे भी एक भाषा है कि बलों डेवलपर्स एक विशिष्ट तरीके से ;-) कोड इंडेंट करने के लिए है

— जोरिस Meys

Answer 1

मुझे लगता है कि प्रोग्रामर टिप्पणियों को जोड़ने का एक और तरीका समझेंगे ...

string aComment = "This is a kludge.";

Comments

मुझे पसंद है कि इस "टिप्पणी" में कई परतें हैं

— लोगन कैपल्डो

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

आप सही हे। हमें इसके बजाय #ifdef कथनों का उपयोग करना होगा।

— जेम्स

यह शायद " किसी भाषा में प्रोग्रामिंग" का सबसे अच्छा उदाहरण है, जैसा कि मैंने कभी देखा "भाषा में प्रोग्रामिंग" के विपरीत । =)

— गाब्लिन

एमओओ में टिप्पणियों के लिए समर्थन है, लेकिन सभी कार्यक्रमों को भंडारण के लिए पार्स किया जाता है और प्रदर्शन के लिए अप्रकाशित किया जाता है ताकि टिप्पणियां खो जाती हैं। लगातार टिप्पणियों के लिए मुहावरा स्ट्रिंग शाब्दिक है अला"this is a comment";

— बेन जैक्सन

Answer 2

मुझे नहीं लगता कि यह इतना आसान है:

यहां तक ​​कि अच्छी तरह से लिखित, स्व-दस्तावेजीकरण कोड में, ऐसी वैध परिस्थितियां हैं जहां आपको टिप्पणियां लिखनी चाहिए।

Comments

कोड क्या कर रहा है की एक साधारण कथन से अधिक होने के लिए +1। यहां तक ​​कि सबसे अच्छे 'सेल्फ-डॉक्यूमेंटिंग कोड' के लिए कई चीजों के विस्तार के लिए टिप्पणी की जरूरत है। अक्सर बार, कोड में बाहरी निर्भरताएं, इनपुट धारणाएं, कैविएट, कामचलाऊ क्षेत्र, ज्ञात कमजोरियां और अनगिनत अन्य चीजें होती हैं जिन्हें कभी स्वीकार नहीं किया जाता है। टिप्पणियों के कई उपयोग हैं।

— एडम क्रॉसलैंड

बिल्कुल सही। आप टिप्पणियों के बिना "आशय" या "क्यों" या "शुद्धता का प्रमाण" कैसे दर्ज करते हैं?

— S.Lott

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

— मैथ्यू पढ़ें

@ मैथ्यू: निष्पक्ष होने के लिए, आप आसानी से कोड लिख सकते हैं जो आसानी से डिक्रिपर्ड नहीं है। लेकिन हाँ, पठनीय कोड "क्या" के लिए सबसे अच्छा स्रोत है।

Answer 3

मान लें कि आप एक आदर्श प्रोग्रामर हैं (जो आप नहीं हैं, लेकिन चलो मान लेते हैं) ...

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

Answer 4

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

अच्छी विकास प्रथाओं का कोई विकल्प नहीं है।

Answer 5

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

(की यानी चर नाम टिप्पणियों को निकालने लिखने कोड के लिए कुछ डेवलपर्स कि स्वयं प्रलेखन में बेहतर है के लिए मजबूर कर सकते हैं, वहाँ अभी भी वहाँ बाहर डेवलपर्स कि लिखने खराब प्रलेखित कोड हैं a, b, c, आदि) और यह उन करने वाला है कि लोगों को बाहर प्रशिक्षित करने की आवश्यकता है के के। उन मामलों में, टिप्पणियों को हटाने से उन डेवलपर्स पर असर नहीं पड़ेगा और कोड के जटिल टुकड़ों को समझाने के लिए अन्य डेवलपर्स के प्रयासों में बाधा पड़ सकती है।

Comments

मैं अब इसके साथ कुछ कोड पढ़ रहा हूं: argument = 3.0; aa = sqrt( argument ); bb = f( aa ); आह।

— एस.लॉट

कोबोल एक विशेष भाषा है। लेकिन वो "।" संचालक बुराई है !!! यह एक वाक्य के वाक्य रचना को तोड़ता है।

— Lo11c Faure-Lacroix

Answer 6

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

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

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

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

यह सभी देखें...

Answer 7

मैं कहीं काम करता हूं जो इनलाइन टिप्पणियों की अनुमति नहीं देता (यानी आप केवल कार्यों के शीर्ष पर टिप्पणी कर सकते हैं)। नहीं, यह कोड को पढ़ना आसान नहीं बनाता है। यह इसे परिमाण के आदेशों को बदतर बनाता है।

Comments

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

— स्कॉट व्हिटलॉक

@ बहिष्कार - मैं एक दृढ़ वकील हूं कि कोड स्व-दस्तावेजीकरण होना चाहिए और इनलाइन टिप्पणियों से बचना है, लेकिन स्पष्ट रूप से मना किया गया है कि वे ओवरकिल हैं।

— जेसन बेकर

@ जेसन - मैं आपसे सहमत हूं, लेकिन मैं सिर्फ इस विचार से सहमत नहीं हूं कि इनलाइन टिप्पणियों के बिना यह "परिमाण के आदेश बदतर" हैं।

— स्कॉट व्हिटलॉक

@ संकेत: आपको बहुत सारी टिप्पणियां मिलती हैं जैसे "हम लाइन 37 पर अजीब अशक्त जांच करते हैं ..." और फिर आपको कोड और टिप्पणियों के बीच अपनी आँखों को झपकाना होगा। बस 37 से ऊपर की टिप्पणी के लिए यह बहुत आसान होगा।

— Xodarap

Answer 8

मैं कोड टिप्पणी करने से बचता हूं, और यह काम करता है।

मैं docblock + सार्थक चर + संयमी प्रोग्रामिंग के पक्ष में सभी इन-कोड (इनलाइन या स्ट्रीम) टिप्पणियों से बचता हूं , और यह काम करता है।

और हां, मुझे पता है कि डॉकब्लॉक तकनीकी रूप से टिप्पणियां हैं, फिर भी, वे वास्तव में कोड के पूरक हैं, घुसपैठ नहीं और "मानकीकृत" ... सब कुछ एक सामान्य टिप्पणी नहीं है।

मुझे लगता है कि टिप्पणियों के विकल्प के रूप में काम कर सकते हैं: एक मानकीकृत docblock भाषा / वाक्यविन्यास / मुहावरा, जावा में एनोटेशन जैसी कुछ।

Comments

"एक मानकीकृत डॉकब्लॉक भाषा / वाक्य रचना / मुहावरा": इसके doxygenलिए काम नहीं करेंगे ? en.wikipedia.org/wiki/Doxygen

— sleske

Doxygen एक प्रलेखन उपकरण है, जो phpdocumentor के समान है और वह चीज़ जो जावा दस्तावेज़ को javadoc (homonim?) से उत्पन्न करती है। मेरा मतलब यह है कि भाषा / वाक्य रचना / मुहावरे प्रोग्रामिंग भाषा का ही हिस्सा थे, न कि कोई टिप्पणी जो टैग / प्रॉपर्टीज के लिए पार्स की जानी है।

— ड्यूकफैगिंग

तो, आप उन्हें कुछ और कॉल करके टिप्पणियों से बचें।

— नैट सीके

Answer 9

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

मुझे यकीन है कि हम में से अधिकांश ने समय-समय पर ऐसा कुछ किया है:

foreach ( myObject obj in SomeList )
 {
    Debug.Writeline( obj.Name );
//  for some reason this isn't working
//  obj.SetArielPotency( setting );
//  obj.DoSomeProcess();       
 }

यदि आप उस बग की ओर से आ रहे हैं, तो यह पता लगाने के लिए कि आप कोड की कुछ पंक्तियों पर टिप्पणी नहीं कर सकते, तो यह कितना परेशान करने वाला होगा?

कोड के संचालन के बारे में टिप्पणियों के बावजूद, उस तरह की सरल व्यावहारिक चीजें या सुविधाजनक TODOनोट में छोड़ना ऐसी चीजें हैं जो मामूली समस्याओं को ठीक करना आसान बनाती हैं और याद रखती हैं कि जब हम कोड लिखना शुरू कर रहे थे तब हम क्या कर रहे थे।

Answer 10

टिप्पणियाँ एक पुस्तक सारांश की तरह हैं। ज़रूर, आप कोड को पढ़कर सब कुछ समझ सकते हैं, लेकिन पृथ्वी पर आप एक पूरा पृष्ठ क्यों पढ़ना चाहते हैं जब इसे एक टिप्पणी लाइन में संक्षेप में प्रस्तुत किया जा सकता है?

Comments

यदि आप इसे एक पंक्ति में सारांशित कर सकते हैं, तो आप यह बताने के लिए पर्याप्त रूप से वर्णन करने के लिए किसी फ़ंक्शन या विधि का नाम दे सकते हैं।

— स्कॉट व्हिटलॉक

Answer 11

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

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

Comments

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

— एस.लॉट

@DisgrunteldGoat: उस के बारे में भूल जाओ। आपको एक विशेष भाषा से शुरू करना होगा, और मैं केवल 5 बोलता हूं। बाकी सभी भाषाएँ मैं उतनी ही खो जाऊंगी जितनी आप डच भाषा में होगी।

— जोरिस मेय्स

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

— किट

Answer 12

अनुशासनहीन प्रोग्रामर खराब कोड लिखेंगे, चाहे वह कोई भी भाषा हो।

उस अजगर को आत्मसात करना, जिसके पास सिर्फ सम्मेलन (_-उपसर्ग) द्वारा निजी है, यह पुलिस के लिए कोई प्रयास नहीं करता है , और बहुत अच्छा कोड अभी भी लिखा जा रहा है।

रेंट: कभी-कभी मुझे लगता है कि अधिक अनुज्ञेय लैंगगेज अधिक लोगों को ठीक से कोड करने के लिए सीखने के लिए मजबूर करेंगे , बजाय रिवर्स (यानी जावा के केवल-एक तरह से और शापित हो यदि आप फ़र्स्ट क्लास ऑब्जेक्ट के रूप में फ़ंक्शंस के बारे में सोचना चाहते हैं)।

Answer 13

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

Answer 14

कोड निश्चित रूप से यह समझाने में स्व-टिप्पणी कर सकता है कि वह क्या कर रहा है, लेकिन कोड के लिए यह हमेशा संभव नहीं है कि वह यह क्यों कर रहा है। यह वह जगह है जहाँ टिप्पणियों की सबसे अधिक आवश्यकता है।

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

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

Answer 15

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

(if (= x y)
    x
    y)

...इस मामले में:

(if (= x y)
    :then x
    :else y)

यदि आपके पास बिलकुल है, तो आप इनलाइन टिप्पणी बनाने के लिए कई एक-शब्द टिप्पणियों की श्रृंखला बना सकते हैं:

(if x :Remember, :x :could :be :nil!
    ...)

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

Comments

यह पढ़ना भी कठिन बनाता है, जो कोड को अधिक पठनीय बनाने के लिए टिप्पणियों के उपयोग को पराजित करता है।

— नैट सीके

Answer 16

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

कारण यह एक अच्छा विचार है: - कोई नहीं

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

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