क्या विभिन्न प्रोग्रामिंग भाषाओं के लिए प्रति व्यक्ति बग की औसत संख्या समान है? [बन्द है]

Question

मुझे बताया गया है कि कोड की प्रति पंक्ति बग्स / दोषों की औसत संख्या विभिन्न प्रोग्रामिंग भाषाओं के लिए "स्थिर" है। रूबी के 10 KLOC में C ++ के 10 KLOC के समान कीड़े होंगे। तर्क आमतौर पर अभिव्यंजक भाषाओं के उपयोग को बढ़ावा देने के लिए उपयोग किया जाता है (विचार करें कि सी ++ / असेंबली पर पायथन / रूबी) के बाद से समान कार्यक्षमता का वर्णन करने के लिए लाइनों की संख्या छोटी होगी।

क्या किसी को पता है कि यह दावा कहां से आता है? क्या उच्च-स्तरीय भाषाओं में कम कीड़े होते हैं?

Comments

यह देखते हुए अनुचित लगता है कि कुछ भाषाएँ ऐसी शैली को प्रोत्साहित करती हैं जो दूसरों की तुलना में एक पंक्ति में अधिक कथन पैक करती हैं।

— कालेब

कीड़े / LOC सब कुछ के लिए एक बहुत ही गलत मीट्रिक है। यह भाषा पर निर्भर करता है, लेकिन यह प्रोग्रामर पर बहुत अधिक निर्भर करता है, इसे लिख रहा है। इसलिए भाषा के लिए औसत लेने का कोई मतलब नहीं है, क्योंकि बड़े उतार-चढ़ाव दूसरे चर में हैं। यह सिर्फ IMO, ofc है।

— Ktete

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

— कालेब

क्या आपको वास्तव में लगता है कि {1≥⍴⍵:⍵⋄e←⍵[?⍴⍵]⋄ (∇(⍵<e)/⍵) , ((⍵=e)/⍵) , ∇(⍵>e)/⍵}इसमें त्रुटि होने की संभावना है int pivot = arr.Count / 2;?

— 20

मैं बस इस सवाल पर भागा। मैंने फोग्गेस्ट को बंद क्यों नहीं किया है; यह इस साइट के लिए एक आदर्श प्रश्न है। एक बड़ी परियोजना के लिए, KLOC प्रति बग कितने अच्छे प्रोग्रामर हैं, इसका कोई माप नहीं है। यह एक उपाय है कि संगठन और प्रक्रिया कितनी अच्छी है।

— डेविड हैमेन

Answer 1

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

मेरे पास आसानी से हाथ में मेरी प्रतियां नहीं हैं - वे काम पर मेरे बुकशेल्फ़ पर बैठे हैं - लेकिन एक त्वरित Google ने एक प्रासंगिक उद्धरण पाया:

उद्योग औसत: "वितरित कोड की प्रति 1000 लाइनों में लगभग 15 - 50 त्रुटियां।"
(स्टीव) आगे कहते हैं कि यह आमतौर पर कोड का प्रतिनिधि होता है जिसमें इसके पीछे संरचित प्रोग्रामिंग का कुछ स्तर होता है, लेकिन संभवतः कोडिंग तकनीकों का मिश्रण भी शामिल है।

कोड कम्प्लीट से उद्धृत , यहाँ पाया गया: http://mayerdan.com/ruby/2012/11/11/bugs-per-line-of-code-ratio/

यदि स्मृति सही ढंग से कार्य करती है, तो स्टीव इस पर गहन चर्चा करता है, यह दर्शाता है कि आंकड़े भाषाओं (सी, सी ++, जावा, असेंबली और इतने पर) में स्थिर हैं और कठिनाइयों के बावजूद (जैसे कि "कोड की लाइन का अर्थ है" परिभाषित करना)।

सबसे महत्वपूर्ण बात यह है कि उनके स्रोतों के लिए बहुत सारे उद्धरण हैं - वह असम्मानित राय नहीं दे रहे हैं, लेकिन उन्हें वापस करने के लिए संदर्भ हैं।

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

(इसके अलावा: यदि आपके पास पहले से ही कोड पूरा नहीं है, तो स्वयं कॉपी खरीदें और इसे अच्छी तरह से पढ़ें - यह अच्छी तरह से निवेश के लायक है)

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

Comments

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

— Roc Martí

कोड का कौन सा संस्करण आपके पास है @ RocMartí? मुझे पता है कि दूसरा संस्करण एक बड़ा अपडेट था। इसे खोदना होगा और देखना होगा कि सोमवार को काम करने पर मुझे क्या कहना है।

— बेवन

मुझे लगता है कि आपका संपादन ( अपडेट :) समस्या का मूल है। या, जैसा कि मार्क ट्वेन ने कहा, तीन तरह के झूठ हैं: झूठ, लानत झूठ और सांख्यिकी।

— गैलेक्टिक

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

— पार्थियन ने

उद्धरण गलत है या पुराना है। दूसरे संस्करण में, यह पृष्ठ 521 पर है: "उद्योग का औसत अनुभव वितरित सॉफ़्टवेयर के लिए कोड की प्रति 1000 पंक्तियों में लगभग 1 - 25 त्रुटियां हैं। सॉफ्टवेयर को आमतौर पर तकनीकों के एक हॉज के उपयोग से विकसित किया गया है।"

— आर्येह लीब तौआरोग

Answer 2

दावा है - सबसे अच्छा - भोला।

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

for (i = 0; i < 100; i += 1) printf("hello"); 

यहां हमारे पास एक भौतिक LOC है, लेकिन दो तार्किक ( forऔर printfकथन) हैं। लेकिन हम निश्चित रूप से उदाहरण लिख सकते हैं:

for (i = 0; i < 100; i += 1) 
  printf("hello"); 

जो हमें दो भौतिक और दो तार्किक LOC प्रदान करेगा। मुझे लगता है कि यह स्पष्ट है कि कोई भी "बग प्रति नियंत्रण" माप जो कि भौतिक LOC पर निर्भर करेगा, प्रोग्रामिंग शैली द्वारा दागी जाएगी, इस प्रकार हमारा माप काफी हद तक बेकार हो जाएगा।

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

दावे के लिए एक संभावित स्रोत लेस हैटन के सॉफ्टवेयर विफलताओं-फॉलियों और पतन :

हम यह निष्कर्ष निकाल सकते हैं कि प्रोग्रामिंग भाषा की पसंद विश्वसनीयता से सबसे कमजोर रूप से संबंधित है।

बाद में, कागज में C और C ++ के समान दोष घनत्व का उल्लेख किया गया है:

हाल के एक अध्ययन में समान आकार की दो समान प्रणालियों की तुलना, (लगभग 50,000 लाइनें प्रत्येक), सी में एक और ऑब्जेक्ट-डिज़ाइन किए गए C ++ में एक, परिणामी दोष घनत्व क्रमशः 2.4 और 2.9 प्रति 1000 लाइनों पर समान रूप से दिखाए गए थे।

हालांकि, इसका मतलब यह नहीं है कि "बग प्रति LOC" प्रोग्रामिंग भाषाओं में निरंतर है, या यह महत्वपूर्ण है कि अगर यह होता।

Comments

यदि आप मानते हैं कि बग / कथन स्थिर है तो भाषाओं के लिए अंतर है। C उदाहरण में आमतौर पर () और प्रिंटफ () args के बग होते हैं। अगर आपको प्रिंटफ कार्यक्षमता को पूरा करना था तो आनुपातिक रूप से अधिक कीड़े होंगे और यदि आपके पास एक एकल प्रिंटरिपेट () कॉल के साथ उच्च स्तर की भाषा थी तो गलत होने के कम अवसर होंगे।

— मार्टिन बेकेट

सारांश: प्रति स्टेटमेंट / फंक्शन पॉइंट बग्स स्थिर है, निम्न स्तर की भाषाओं में अधिक संख्या में कोड होते हैं, जो गिरने योग्य प्रोग्रामर द्वारा लिखी जाती हैं, उच्च स्तरीय भाषाएं जो आप कम टाइप करते हैं - इसलिए कम बग। हालांकि पूरी तरह से गलत डिजाइन प्रकार के कीड़े संभवतः समान हैं!

— मार्टिन बेकेट

अकेले चलो कि "एक बग" का गठन अत्यधिक व्यक्तिपरक है, और यह कि कीड़े गंभीरता, प्रभाव और महत्व में बेतहाशा भिन्न हैं।

— tdammers

@ दोस्त और वह महत्व नकारात्मक हो सकता है। हमारे पास कुछ मुट्ठी भर कीड़े हैं जिनका उपयोग ग्राहक /

— अपेक्षाओं

@ इज़काता: एक बग की आपकी परिभाषा पर निर्भर करता है ...

— tdammers

Answer 3

यह अवलोकन बहुत पुराना है, और एक बहुत आदरणीय स्रोत से आता है, अर्थात् फ्रेड ब्रूक्स ने अपनी पुस्तक "द मिथिकल मैन मंथ" में। वह आईबीएम में एक शीर्ष प्रबंधक था, और कई प्रोग्रामिंग परियोजनाओं को प्रबंधित करता था, जिसमें माइलेज-ऑफ-लाइन ऑपरेटिंग सिस्टम ओएस / 360 भी शामिल था। वास्तव में उन्होंने बताया कि किसी प्रोग्राम में बग्स की संख्या कोड की लंबाई के आनुपातिक नहीं है, लेकिन द्विघात है ! उनके शोध के अनुसार, बग्स की संख्या कार्यक्रम की लंबाई शक्ति 1.5 के अनुपात में थी। दूसरे शब्दों में, एक कार्यक्रम जो दस गुना लंबा है, उसमें 30 गुना अधिक कीड़े हैं। और उन्होंने बताया कि यह सभी प्रोग्रामिंग भाषाओं और प्रोग्रामिंग भाषाओं के स्तर पर आयोजित किया गया।

Answer 4

मुझे किसी भी भाषा के लिए Bugs प्रति LOC स्थिर नहीं लगती है। एलओसी के बग्स एक मीट्रिक की तरह लगते हैं जो कुछ प्रबंधक डेवलपर्स की गुणवत्ता निर्धारित करने के लिए उपयोग करते हैं जब यह समय की समीक्षा करने के लिए आता है।

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

केवल एक ही बात का जवाब मैं दे सकता हूं कि इसका संबंध यह हो सकता है कि जितने अधिक एलओसी हों, वहां दोष होने की संभावनाएं उतनी ही अधिक होती हैं और अधिक दोष मौजूद होते हैं।

Comments

मेरा प्रश्न भाषा के स्वतंत्र कोड की प्रति पंक्ति दोषों की औसत संख्या के बारे में है।

— क्रिस्टियन

@ क्रिस्टियन ऐसी कोई संख्या नहीं है। यह प्रति व्यक्ति डेवलपर और भाषा की नौकरी और विशेषज्ञता के सापेक्ष बदलता है जिसमें वे कोडिंग कर रहे हैं। मुझे नहीं लगता कि एक सार्वभौमिक औसत है।

— अकीरा 71१

@ अकीरा71 "ऐसी कोई संख्या नहीं है" ठीक है, निश्चित रूप से। लेकिन संभावना वितरण हैं, जिनसे आप संख्या निकाल सकते हैं। अमेज़न वर्षावन में सालाना कितने इंच बारिश होती है, इसके लिए भी कोई संख्या नहीं है, लेकिन आप औसत ले सकते हैं।

— पार्थियन ने

Answer 5

कोड की लाइन प्रति कीड़े

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

कीड़े आपकी नौकरी के लिए सापेक्ष हैं

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

वो कैसे संभव है?

वरिष्ठ डेवलपर अक्सर उच्च जोखिम वाले विकास कार्यों में लगे रहते हैं। एक उदाहरण के रूप में कोड का फिर से निर्माण और नई प्रणालियों का निर्माण। जूनियर डेवलपर्स को अक्सर ज्ञात मुद्दों को ठीक करने के लिए सौंपा जाता है जो किसी वरिष्ठ डेवलपर के समय के लायक नहीं हैं।

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

भाषा सिंटेक्स महत्वपूर्ण है

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

कम्पाइलर कीड़े को कम करता है

पायथन / पीएचपी में कितने बग ने इसे उत्पादन सर्वर में बदल दिया है, क्योंकि डेवलपर को चेतावनी देने के लिए कोई संकलक नहीं था कि कुछ गलत था। जब आप एलओसी के बग्स को मापते हैं, तो संकलक से पहले या बाद में स्रोत कोड को संसाधित किया जाता है?

अपडेट 2019:

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

Comments

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

— विंस्टन ईवर्ट

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

— केन स्मिथ

@KenSmith स्थिर प्रकार मुक्त नहीं हैं। Courses.cs.washington.edu/courses/cse590n/10au/…

— ह्यूगो वुड

Answer 6

एफडब्ल्यूआईडब्ल्यू, मेरे अनुभव में

1. दो प्रकार के बग हैं: ए) जहां कार्यक्रम अपेक्षाओं को पूरा नहीं करता है, और बी) जहां कार्यक्रम किसी भी उचित अपेक्षाओं को पूरा नहीं कर सकता है, क्योंकि यह क्रैश / हैंग / संकलन नहीं करेगा।

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

ये बातें (फिर से, मेरे अनुभव में) वास्तव में भाषा का कार्य नहीं हैं, बल्कि प्रोग्रामर के कौशल / परिपक्वता का है। प्रोग्राम जो बहुत कम बग-प्रवण हैं, एलओसी के संदर्भ में, कार्यक्षमता के दिए गए सेट के लिए बहुत कम हैं।

मैंने ऐसी प्रणालियाँ देखी हैं जहाँ कुछ लोग प्रोग्राम लिखते हैं, जबकि अन्य निर्देशिका लिखते हैं, और पूर्व में उत्तरार्ध की तुलना में "बस काम" करते हैं।

Answer 7

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

Comments

यह कैसे अस्वीकृत हो गया? एसओ

— मसखरों

Answer 8

कोड की लाइनों के बारे में बात करने के बजाय - जो वास्तव में एक बेकार मीट्रिक हैं - मैं आपके प्रश्न के इस हिस्से को संबोधित करना चाहूंगा:

क्या उच्च-स्तरीय भाषाओं में कम कीड़े होते हैं?

यह बग / एलओसी से अलग है, क्योंकि उच्च-स्तरीय भाषाएं कम कोड के साथ अधिक करती हैं। कुछ सुविधा की आवश्यकता को लागू करने से एलआईएसपी की 500 लाइनें बनाम x86 विधानसभा की 15000 लाइनें लग सकती हैं।

इसलिए, भले ही बग / एलओसी सभी भाषाओं के बीच स्थिर हो, उच्च-स्तरीय भाषा अभी भी कम बग पैदा करेगी।

Comments

एक "बेकार मीट्रिक" कोड की पंक्तियाँ? नहीं, यह कार्यक्रम की जटिलता का एक मोटा अनुमान है। यह उपयोगी हो सकता है क्योंकि यह मापने में आसान है और विकास के समय से भी निकटता से संबंधित है।