निम्न-स्तरीय प्रोग्रामिंग में गुप्त संक्षिप्त पहचानकर्ता अभी भी इतने सामान्य क्यों हैं?

Question

वहाँ हुआ करता था बहुत अनुदेश रखने के लिए अच्छे कारणों / रजिस्टर लघु नाम। वे कारण अब लागू नहीं होते हैं, लेकिन निम्न स्तर की प्रोग्रामिंग में अभी भी छोटे गूढ़ नाम बहुत आम हैं।

ऐसा क्यों है? क्या सिर्फ इसलिए कि पुरानी आदतों को तोड़ना मुश्किल है, या बेहतर कारण हैं?

उदाहरण के लिए:

• Atmel ATMEGA32U2 (2010?): TIFR1(के बजाय TimerCounter1InterruptFlag), ICR1H(के बजाय InputCapture1High), DDRB(के बजाय DataDirectionPortB), आदि।
• .NET CLR निर्देश सेट (2002): bge.s(के बजाय branch-if-greater-or-equal.short), आदि।

लंबे समय तक, गैर-गुप्त नामों के साथ काम करना आसान नहीं है?

---

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

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

वह कौन सी मुख्य बात है जो निम्न-स्तरीय प्रोग्रामिंग के बारे में अलग-अलग होती है, जो उच्च-स्तरीय भाषाओं के विपरीत होती है, जो निम्न-स्तर की प्रोग्रामिंग को उच्च स्तरीय प्रोग्रामिंग में वांछनीय बनाती है, लेकिन उच्च-स्तरीय प्रोग्रामिंग के लिए वांछनीय है?

Comments

उत्तर: यह महसूस करने के लिए कि आप निम्न स्तर की भाषा में प्रोग्रामिंग कर रहे हैं।

— थॉमस ईडिंग

क्रिप्टोकरंसी सापेक्ष है। JSRयह $20एक ( 6502 पर) का प्रतिनिधित्व करता है और एक नज़र में समझने के लिए काफी आसान है की तुलना में तीन गुना अधिक लंबा है ।

— १२:३३

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

— जेफ लैंगमेयर

@ नागट: कोशिश set Accumulator32 to BaseIndex32? बस पारंपरिक संक्षिप्तीकरण का विस्तार कुछ और पठनीय बनाने का एकमात्र तरीका नहीं है।

— तिमवी

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

— एपीग्रामग्राम

Answer 1

सॉफ़्टवेयर उन नामों का उपयोग करता है क्योंकि डेटाशीट उन नामों का उपयोग करता है। चूँकि उस स्तर पर कोड को वैसे भी डेटशीट के बिना समझना बहुत मुश्किल है, ऐसे परिवर्तनशील नाम जिन्हें आप खोज नहीं सकते हैं, बेहद अकल्पनीय हैं।

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

इसके अलावा, योजनाबद्ध, पिन आरेख, और पीसीबी साइलस्क्रीन्स जैसी चीजें अक्सर अंतरिक्ष के लिए बहुत तंग होती हैं।

Comments

इसके अलावा, यह उत्तर वास्तव में शुद्ध-सॉफ्टवेयर पक्ष को संबोधित नहीं करता है, जैसे सीएलआर, जेवीएम, x86, आदि :)

— टिमवी

@romkyns: यह थोड़ा अधिक स्पष्ट है कि जब आप वास्तव में इन डेटाशीट्स के माध्यम से पढ़ते हैं तो उन्होंने इन छोटे नामों का उपयोग क्यों किया। मेरे पास एक माइक्रोकंट्रोलर के लिए डेटशीट पूरे छोटे नाम का उपयोग करते हुए भी लगभग 500 पृष्ठ हैं । यदि हम एक संदर्भ का उपयोग करने के लिए बहुत असुविधाजनक बना रहे हैं, तो तालिकाओं की चौड़ाई कई पृष्ठों / स्क्रीन का उपयोग करेगी।

— सिलिको

@romkyns: लंबे नाम समान रूप से खोजे जाने योग्य हैं, लेकिन वे "गैर-देशी" हैं। यदि आप एम्बेडेड इंजीनियरों को सुनते हैं, तो वे वास्तव में "टिफ़र शून्य" कहते हैं, न कि "टाइमर शून्य के बाधा ध्वज"। मुझे संदेह है कि वेब डेवलपर HTTP, HTML, या JSON को उनके विधि नामों में विस्तारित करते हैं, या तो।

— TMN

@KarlBielefeldt एर, क्या? :) जाहिर है कि मैं इसे वर्तमान डेटाशीट में नहीं पाऊंगा क्योंकि वे इसके बजाय संक्षिप्त नाम के लिए गए थे। यह इस दावे का समर्थन नहीं करता है कि थोड़े नाम थोड़े से अधिक खोज योग्य हैं ...

— रोमन स्टार्कोव

यह केवल स्पेसशीट नहीं है जो अंतरिक्ष-विवश है, यह योजनाबद्ध है। उन सभी तार्किक घटकों में लीड होते हैं जिन्हें अन्य घटकों से जोड़ने की आवश्यकता होती है। "TimerCounter1InteruptFlag.clear" लगभग एक छोटे से तार के प्रतिनिधित्व के साथ-साथ "TCIF.C" के ऊपर फिट नहीं होता है

— AShelly

Answer 2

जिपफ का नियम

आप स्वयं इस बहुत ही पाठ को देखकर देख सकते हैं कि शब्द की लंबाई और उपयोग की आवृत्ति सामान्य रूप से, विपरीत रूप से संबंधित है। शब्द जो बहुत बार उपयोग किया जाता है, जैसे it, a, but, you, और and, बहुत ही कम हैं, जबकि शब्द है कि कम अक्सर इस्तेमाल किया जाता तरह observe, comprehensionहै, और verbosityलंबे समय तक कर रहे हैं। आवृत्ति और लंबाई के बीच इस मनाया संबंध को जिपफ लॉ कहा जाता है ।

किसी दिए गए माइक्रोप्रोसेसर के लिए सेट किए गए निर्देशों की संख्या आमतौर पर दर्जनों या सैकड़ों में होती है। उदाहरण के लिए, Atmel AVR अनुदेश सेट में लगभग सौ अलग-अलग निर्देश (मेरी गिनती नहीं थी) शामिल हैं, लेकिन उनमें से कई एक सामान्य विषय पर भिन्नताएं हैं और बहुत समान mnemonics हैं। उदाहरण के लिए, गुणन निर्देशों में MUL, MULS, MULSU, FMUL, FMULS और FMULDU शामिल हैं। आपको सामान्य विचार प्राप्त करने से पहले बहुत लंबे समय तक निर्देशों की सूची को देखने की ज़रूरत नहीं है कि "बीआर" से शुरू होने वाले निर्देश शाखाएं हैं, "एलडी" से शुरू होने वाले निर्देश लोड हैं, आदि वही हैं जो चर पर लागू होते हैं: यहां तक ​​कि जटिल प्रोसेसर मूल्यों को संग्रहीत करने के लिए केवल सीमित संख्या में स्थान प्रदान करते हैं: हालत रजिस्टर, सामान्य उद्देश्य रजिस्टर, आदि।

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

इसके अतिरिक्त, विभिन्न प्रोसेसर के लिए निर्देश सेट अक्सर समान संचालन के लिए समान नामों का उपयोग करते हैं। अधिकांश निर्देश सेट में ADD, MUL, SUB, LD, ST, BR, NOP, और यदि वे उन सटीक नामों का उपयोग नहीं करते हैं, तो वे आमतौर पर ऐसे नामों का उपयोग करते हैं जो बहुत करीब हैं। एक बार जब आप एक निर्देश सेट के लिए वर्णक्रमीयता सीख गए हैं, तो अन्य उपकरणों के लिए निर्देश सेट के अनुकूल होने में देर नहीं लगती है। तो ऐसे नाम जो आपको "गूढ़" लग सकते हैं and, जैसे शब्दों के बारे में परिचित हैं or, और notउन प्रोग्रामरों के लिए जो निम्न स्तर की प्रोग्रामिंग की कला में कुशल हैं। मुझे लगता है कि विधानसभा स्तर पर काम करने वाले अधिकांश लोग आपको बताएंगे कि कोड पढ़ना सीखना निम्न स्तर की प्रोग्रामिंग में अधिक चुनौतियों में से एक नहीं है।

Comments

धन्यवाद कालेब! मेरे लिए, इस उत्कृष्ट उत्तर ने एक प्रश्न को हल कर दिया कि किसी तरह एक शीर्षक में चार मूल्य निर्णय लेने में कामयाब रहे : "गुप्त", "लघु", "अभी भी", "इतना आम"

— gnat

धन्यवाद, @gnat, आपकी टिप्पणी और आपके उदार बोनस दोनों के लिए।

— कालेब

Answer 3

सामान्य रूप में

नामकरण की गुणवत्ता केवल वर्णनात्मक नामों के बारे में नहीं है, इसके लिए अन्य पहलुओं पर भी विचार करना होगा, और यह इस तरह की सिफारिशों की ओर जाता है:

• जितना अधिक वैश्विक दायरा होगा, उतना अधिक वर्णनात्मक नाम होना चाहिए
• जितना अधिक बार इसका उपयोग किया जाता है, उतना कम नाम होना चाहिए
• एक ही नाम का उपयोग सभी संदर्भों में एक ही चीज़ के लिए किया जाना चाहिए
• यदि संदर्भ अलग है तो भी अलग-अलग चीजों के अलग-अलग नाम होने चाहिए
• विविधताओं का आसानी से पता लगाया जाना चाहिए
• ...

ध्यान दें कि ये सिफारिशें परस्पर विरोधी हैं।

निर्देश mnemonics

एक विधानसभा भाषा प्रोग्रामर के रूप में, का उपयोग कर short-branch-if-greater-or-equalके लिए bge.sमुझे जब मैं देख रहा हूँ की तुलना में एक ही प्रभाव देता है, एक अल्गोल प्रोग्रामर कम्प्यूटेशनल ज्यामिति कर रही है, के रूप में SUBSTRACT THE-HORIZONTAL-COORDINATE-OF-THE-FIRST-POINT TO THE-HORIZONTAL-COORDINATE-OF-THE-SECOND-POINT GIVING THE-DIFFERENCES-OF-THE-COORDINATE-OF-THE-TWO-POINTSके बजाय dx := p2.x - p1.x। मैं सिर्फ इस बात से सहमत नहीं हो सकता कि पहले मैं जिन संदर्भों का ध्यान रखता हूं उनमें अधिक पठनीय हैं।

नाम पंजीकृत करें

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

Comments

क्या TIFR1वास्तव में एक बेहतर नामकरण योजना है InterruptFlag1, या IptFlag1यदि आपको वास्तव में छोटा होना है?

— तिमवी

@Timwi, InterruptFlagऔर IptFlagकी तुलना में बेहतर कर रहे हैं IFएक ही रास्ता है कि में EnumerableInterfaceऔर ItfcEnumerableसे बेहतर हैं IEnumerable।

— एपीग्रामग्राम

@AProgrammer: मैं आपके जवाब और आपकी टिप्पणी को सबसे अच्छा मानता हूं और अगर मुझे लगता है तो मैं इसे स्वीकार करूंगा। जो लोग मानते हैं कि केवल भौतिक सीमाएं छोटे नामों को निर्धारित करती हैं, वे गलत हैं। यह चर्चा आपके लिए दिलचस्प होगी: 37signals.com/svn/posts/…

— alpav

@alpav क्या आपको पता है कि आपका लिंक इस जवाब के विपरीत तर्क देता है? यदि कुछ भी है, तो यह पूरी तरह InterruptFlag1से बेहतर स्पष्टता के कारणों का समर्थन करता है ।

— रोमन स्टार्कोव

Answer 4

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

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

जहाँ तक bge.s, यह कोडांतरक के समान है - कुछ लोगों के लिए जिन्हें यह जानने की आवश्यकता है कि यह नाम कम पठनीय हैं। यदि आप आपको इधर bge.s- उधर नहीं कर सकते हैं और सोचेंगे कि branch-if-greater-or-equal.shortफर्क पड़ेगा - आप केवल सीएलआर के साथ खेल रहे हैं और इसे नहीं जानते हैं।

दूसरा कारण जो आपको लघु चर नाम दिखाई देगा, वह यह है कि सॉफ्टवेयर जिस डोमेन को लक्षित कर रहा है, उसके भीतर संक्षिप्त रूप से फैला हुआ है।

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

Comments

अगर मैं "bge.s" की रक्षा के लिए आपके द्वारा उपयोग किए जाने वाले तर्क को समझ गया , तो क्या TIFR1यह उन लोगों के लिए अधिक पठनीय है, जिन्हें इसे जानने की आवश्यकता है TimerCounter1InterruptFlag, सही?

— रोमन स्टार्कोव

@romkyns: बिल्कुल - इस मामले में कम अधिक है .... सीएनटीआर के विपरीत जिसका अर्थ "काउंटर", "कंट्रोल", "कैन नॉट ट्रेस रूट" आदि हो सकता है, टी 1 एफआर 1 सटीक अर्थ में परिभाषित है।

— मटनज़

"यदि आप bge.s के आस-पास सिर नहीं जमा सकते हैं और सोचें कि शाखा-अगर-अधिक-या-सम-विषम हो तो फर्क पड़ेगा - आप केवल CLR के साथ खेल रहे हैं और इसे नहीं जानते हैं।" मैं उस बारे में नहीं जानता। मैं x86 असेंबली को अच्छी तरह से समझता हूं, लेकिन हर बार जब मैं एक लूप लिखता हूं, तो मुझे देखना होगा कि सभी j?निर्देशों का क्या मतलब है। अधिक स्पष्ट रूप से नामित निर्देश होने से निश्चित रूप से मुझे मदद मिलेगी। लेकिन शायद मैं नियम के बजाय अपवाद हूं। मुझे तुच्छ विवरण याद रखने में परेशानी होती है।

— कोड़ी ग्रे

Answer 5

यहां बहुत सारे अलग-अलग विचार हैं। मैं किसी भी मौजूदा उत्तर को उत्तर के रूप में स्वीकार नहीं कर सकता : सबसे पहले, इसमें योगदान करने वाले कई कारक होने की संभावना है, और दूसरी बात, मैं संभवतः यह नहीं जान सकता कि कौन सा सबसे महत्वपूर्ण है।

तो यहां अन्य लोगों द्वारा पोस्ट किए गए उत्तरों का सारांश है। मैं इसे सीडब्ल्यू के रूप में पोस्ट कर रहा हूं और मेरा इरादा अंततः इसे स्वीकार करने के लिए है। कृपया संपादित करें अगर मैं कुछ याद किया। मैंने इसे स्पष्ट रूप से स्पष्ट रूप से व्यक्त करने के लिए प्रत्येक विचार को फिर से समझने की कोशिश की।

तो निम्न-स्तरीय प्रोग्रामिंग में क्रिप्टिक लघु पहचानकर्ता इतने सामान्य क्यों हैं?

• क्योंकि उनमें से बहुत से संबंधित डोमेन में बहुत कम नाम के लिए वारंट कर रहे हैं। इससे सीखने की अवस्था बिगड़ जाती है, लेकिन उपयोग की आवृत्ति को देखते हुए एक सार्थक ट्रेडऑफ़ है।
• क्योंकि आमतौर पर संभावनाओं का एक छोटा सा सेट होता है जो तय किया जाता है (प्रोग्रामर सेट में नहीं जोड़ सकता है)।
• क्योंकि पठनीयता आदत और अभ्यास का विषय है। branch-if-greater-than-or-equal.shortकी तुलना में शुरू में अधिक पठनीय है bge.s, लेकिन कुछ अभ्यास के साथ स्थिति उलट हो जाती है।
• क्योंकि उन्हें अक्सर पूर्ण, हाथ से टाइप करना पड़ता है, क्योंकि निम्न स्तर की भाषाएं अक्सर शक्तिशाली आईडीई के साथ नहीं आती हैं जिनके पास अच्छा स्वत: पूर्णता है, या ए / सी विश्वसनीय नहीं है।
• क्योंकि कभी-कभी पहचानकर्ता में बहुत सारी जानकारी पैक करना वांछनीय होता है, और एक पठनीय नाम उच्च-स्तरीय मानकों द्वारा भी अस्वीकार्य रूप से लंबा होगा।
• क्योंकि यही निम्न-स्तरीय वातावरण ऐतिहासिक रूप से देखा गया है। ब्रेकिंग की आदत के लिए सचेत प्रयास की आवश्यकता होती है, जो पुराने तरीकों को पसंद करने वालों को परेशान करने का जोखिम उठाता है, और इसे उचित रूप में उचित ठहराया जाना चाहिए। स्थापित तरीके से चिपकना "डिफ़ॉल्ट" है।
• क्योंकि उनमें से कई की उत्पत्ति कहीं और होती है, जैसे योजनाबद्ध और डेटशीट। बदले में, वे अंतरिक्ष की कमी से प्रभावित होते हैं।
• क्योंकि चीजों के नामकरण के प्रभारी लोगों ने कभी भी पठनीयता पर विचार नहीं किया है, या उन्हें एहसास नहीं है कि वे एक समस्या पैदा कर रहे हैं, या आलसी हैं।
• क्योंकि कुछ मामलों में नाम डेटा के इंटरचेंज के लिए एक प्रोटोकॉल का हिस्सा बन गए हैं , जैसे कि कुछ संकलक द्वारा मध्यवर्ती प्रतिनिधित्व के रूप में विधानसभा भाषा का उपयोग।
• क्योंकि यह शैली निम्न-स्तर के रूप में तुरंत पहचानने योग्य है और इस प्रकार गीक्स को शांत लगती है।

मुझे व्यक्तिगत रूप से लगता है कि इनमें से कुछ वास्तव में उन कारणों में योगदान नहीं करते हैं कि एक नई विकसित प्रणाली इस नामकरण शैली का चयन क्यों करेगी, लेकिन मुझे लगा कि इस प्रकार के उत्तर में कुछ विचारों को फ़िल्टर करना गलत होगा।

Answer 6

मैं इस झमेले में अपनी टोपी फेंकने जा रहा हूँ।

उच्च स्तरीय कोडिंग कन्वेंशन और मानक निम्न स्तर के कोडिंग मानकों और प्रथाओं के समान नहीं हैं। दुर्भाग्य से, उनमें से ज्यादातर विरासत कोड और पुराने विचार प्रक्रियाओं से होल्डओवर हैं।

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

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

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

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

Comments

मुझे लगता है कि "हम क्रिप्टिक नामों का उपयोग करेंगे, क्योंकि यही निम्न-स्तरीय प्रोग्रामिंग को इस तरह महसूस करता है" और "हम क्रिप्टिक नामों का उपयोग करेंगे क्योंकि यह निम्न-स्तरीय प्रोग्रामिंग के लिए कन्वेंशन" बहुत समान हैं, इसलिए +1 मैं और मैं इसे शुरू में स्वीकार किए गए एक कम भड़काऊ संस्करण के रूप में स्वीकार करने के बारे में सोचेंगे ।

— रोमन स्टार्कोव

केमिस्ट के संदर्भ में +1 प्रोग्रामिंग के विभिन्न क्षेत्रों के लिए एक अच्छा सादृश्य उत्पन्न करता है।

+1 मुझे यह भी समझ में नहीं आया कि लोग "पानी" जैसे छोटे, गूढ़ नामों का उपयोग क्यों करते हैं यदि बहुत अधिक पठनीय "DiHydrogenOxyde" है

— Ingo

Answer 7

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

यदि एक नया डेवलपर टीम में आता है तो उसे डेटशीट (जैसा कि @KarlBielefeldt द्वारा समझाया गया है) पढ़ना होगा, ताकि वे उन लोगों के साथ सहज हो जाएं।

मेरा मानना ​​है कि आपके प्रश्न ने एक खराब उदाहरण का उपयोग किया है क्योंकि वास्तव में इस तरह के स्रोत कोड पर आपको आमतौर पर गैर-डोमेन सामान के लिए अनावश्यक क्रिप्ट पहचानकर्ता दिखाई देते हैं।

मैं कहूंगा कि ज्यादातर वे बुरी आदतों के कारण होते हैं जो कंपाइलर्स ने आपके द्वारा टाइप की गई हर चीज को ऑटो-कम्प्लीट नहीं किया था।

Answer 8

सारांश

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

गुप्त नामों के कारण:

1. निम्न-स्तरीय निर्देश दृढ़ता से टाइप किए गए हैं
2. निम्न-स्तरीय निर्देश के नाम पर कई प्रकार की जानकारी पैक करने की आवश्यकता है
3. ऐतिहासिक रूप से, एकल-वर्ण कोड प्रकार की जानकारी पैक करने के पक्षधर हैं।

समाधान और उनकी कमियां:

1. आधुनिक निम्न-स्तरीय नामकरण योजनाएं हैं जो ऐतिहासिक लोगों की तुलना में अधिक सुसंगत हैं।
   • LLVM
2. हालाँकि, कई प्रकार की जानकारी पैक करने की आवश्यकता अभी भी मौजूद है।
   • इस प्रकार, सभी जगह अभी भी गुप्त संक्षिप्त जानकारी पाई जा सकती है।
3. बेहतर लाइन-टू-लाइन पठनीयता एक नौसिखिया निम्न-स्तरीय प्रोग्रामर को तेजी से भाषा चुनने में मदद करेगी, लेकिन निम्न-स्तरीय कोड के बड़े टुकड़ों को समझने में मदद नहीं करेगी।

---

पूरा जवाब

(ए) लंबे नाम संभव हैं। उदाहरण के लिए, असेंबली mnemonic में 7 वर्णों की तुलना में C ++ SSE2 इंट्रिनिक्स औसत 12 वर्णों के नाम। http://msdn.microsoft.com/en-us/library/c8c5hx3b(v=vs.80).aspx

(बी) सवाल तब आगे बढ़ता है: निम्न-स्तरीय निर्देशों से किसी को कब तक / गैर-क्रिप्टोकरंसी प्राप्त करने की आवश्यकता होती है?

(ग) अब हम ऐसी नामकरण योजनाओं की संरचना का विश्लेषण करते हैं। निम्नलिखित के लिए दो नामकरण योजनाओं रहे हैं एक ही निम्न स्तर के निर्देश:

• नामकरण योजना # 1: CVTSI2SD
• नामकरण योजना # 2: __m128d _mm_cvtsi32_sd (__m128d a, int b);

(C.1) निम्न-स्तरीय निर्देश हमेशा दृढ़ता से टाइप किए जाते हैं। इसमें अस्पष्टता, प्रकार का अनुमान, स्वचालित प्रकार रूपांतरण, या ओवरलोडिंग (समान नाम का गैर-समकक्ष संचालन के लिए निर्देश नाम का पुन: उपयोग) नहीं हो सकता है।

(C.2) प्रत्येक निम्न-स्तरीय अनुदेश को अपने नाम में बहुत प्रकार का संकेत देना चाहिए। जानकारी के उदाहरण:

• वास्तुकला परिवार
• ऑपरेशन
• तर्क (इनपुट्स) और आउटपुट
• प्रकार (हस्ताक्षर किए गए पूर्णांक, बिना हस्ताक्षर किए पूर्णांक, फ्लोट)
• परिशुद्धता (बिट चौड़ाई)

(C.3) यदि जानकारी के प्रत्येक टुकड़े को वर्तनी दी जाती है, तो कार्यक्रम अधिक क्रियात्मक होगा।

(C.4) विभिन्न विक्रेताओं द्वारा उपयोग की जाने वाली प्रकार-एन्कोडिंग योजनाएँ लंबे समय से ऐतिहासिक थीं। एक उदाहरण के रूप में, x86 निर्देश सेट में:

• बी का अर्थ है बाइट (8-बिट)
• डब्ल्यू का अर्थ है शब्द (16-बिट)
• D का अर्थ है "डबल-वर्ड" (32-बिट)
• Q का अर्थ है क़वर्ड "क्वाड-वर्ड" (64-बिट)
• DQ का अर्थ है dqword "डबल-क्वाड-वर्ड" (128-बिट)

इन ऐतिहासिक संदर्भों का कोई भी आधुनिक अर्थ नहीं था, लेकिन फिर भी यह चारों ओर चिपक जाता है। एक अधिक सुसंगत योजना ने बिट-चौड़ाई मूल्य (8, 16, 32, 64, 128) को नाम में रखा होगा।

इसके विपरीत, एलएलवीएम निम्न-स्तरीय निर्देशों में स्थिरता की दिशा में एक सही कदम है: http://llvm.org/docs/LangRef.html#functions

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

Comments

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

— रोमन स्टार्कोव

इसके अलावा, एक तरह से विषय से हटकर है, लेकिन CVTSI2SDकिसी भी अधिक जानकारी नहीं होता ConvertDword2Doubleया ConvInt32ToFloat64, लेकिन बाद, अब जबकि,, तुरंत पहचानने हैं पूर्व मतलब निकाला जाना चाहिए जबकि ...

— रोमन Starkov

Answer 9

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

Opcodes और रजिस्टर नाम के मामले में, लंबे नाम वास्तव में पठनीयता को नुकसान पहुंचाते हैं। लघु संचार शब्द संचार प्रोटोकॉल (कंपाइलर और असेंबली के बीच) के लिए बेहतर होते हैं, और असेंबली भाषा अधिकांश समय एक संचार प्रोटोकॉल होती है। कंपार्टर कोड पढ़ने के लिए आसान है, क्योंकि प्रोग्रामर के लिए लघु निमोनिक्स बेहतर हैं।

Comments

यदि आपको स्थान बचाने की आवश्यकता है, तो बस इसे gzip करें! ... यदि आपको कोई ओवरहेड की आवश्यकता नहीं है, तो इसके बजाय एक बाइनरी प्रारूप का उपयोग करें! यदि आप पाठ का उपयोग कर रहे हैं, तो आप पठनीयता के लिए लक्ष्य बना रहे हैं - तो क्यों नहीं सभी तरह से जाएं और इसे ठीक से पठनीय बनाएं?

— रोमन स्टार्कोव

@romkyns, दो स्थानीय प्रक्रियाओं के बीच एक पाठ-आधारित संचार प्रोटोकॉल को संपीड़ित करता है? वह कुछ नया है। बाइनरी प्रोटोकॉल बहुत कम मजबूत हैं। यह एक यूनिक्स तरीका है - पाठ-आधारित प्रोटोकॉल कभी-कभार पठनीयता के लिए होते हैं । वे सिर्फ पढ़ने योग्य हैं।

— एसके-लॉजिक

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

— रोमन स्टार्कोव

मैं आपके अधिकार का सम्मान करता हूं कि अलग-अलग नामों में एक अलग स्वाद होना चाहिए, लेकिन क्या आप वास्तव में अपने कंपाइलरों में ऐसी विधियों और स्थानीय लोगों का नाम TIFRलेते हैं, जैसे कि वे पूर्ण शब्दों को शामिल करते हैं?

— रोमन स्टार्कोव

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

— रोमन स्टार्कोव

Answer 10

अधिकतर यह मुहावरेदार है। जैसा कि @TMN अन्यत्र कहता है, जैसे आप लिखते नहीं हैं import JavaScriptObjectNotationया import HypertextTransferProtocolLibraryपाइथन में, आप Timer1LowerHalf = 0xFFFFसी में नहीं लिखते हैं। यह संदर्भ में भी उतना ही हास्यास्पद लगता है। जिसे हर किसी को पहले से ही जानने की जरूरत है।

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

उदाहरण के लिए, हाईटेक के सी कंपाइलर में चर के लिए एक विशेष सिंटैक्स शामिल था जो कि मेमोरी में उपयोगकर्ता द्वारा निर्दिष्ट स्थिति के लिए आवश्यक था। आप घोषणा कर सकते हैं:

volatile char MAGIC_REGISTER @ 0x7FFFABCD;

अब अस्तित्व में एकमात्र IDE जो यह पार्स करेगा वह है HiTech का अपना IDE ( HiTide )। किसी भी अन्य संपादक में, आपको इसे हर बार मेमोरी से, मैन्युअल रूप से टाइप करना होगा। यह बहुत जल्दी बूढ़ा हो जाता है।

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

ये मूर्खतापूर्ण छोटी क़ुबूलों की तरह लग सकते हैं, लेकिन क्या हर कोडिंग कन्वेंशन को आँख के तनाव को कम करने, शानदार टाइपिंग में कमी या एक लाख अन्य छोटी शिकायतों में से किसी एक को संबोधित करने के लिए डिज़ाइन नहीं किया गया है?

Comments

आपके सभी तर्क समझ में आते हैं। मैं उन सभी बिंदुओं को पूरी तरह से समझता हूं। हालाँकि, आपको नहीं लगता कि उच्च-स्तरीय कोड पर सटीक वही बात लागू होती है? आपको C # फ़ंक्शन में स्थानीय लोगों की तालिका देखने की भी आवश्यकता है। प्रसंग व्यक्तिपरक है और File.ReadAllBytesकिसी को इस्तेमाल करने के लिए हास्यास्पद रूप से लंबा भी लग सकता है fread। तो ... उच्च-स्तरीय और निम्न-स्तरीय कोड को अलग तरह से क्यों माना जाता है ?

— रोमन स्टार्कोव

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

— detly

@romkyns - इसके अलावा, एक विशुद्ध रूप से व्यावहारिक अर्थ में, मुझे लगता है कि सी # में कुछ माइक्रोप्रोसेसर के आईडीई और अनुप्रयोग विकास में रजिस्टरों की मेज के बीच अंतर है इस: ऊपर रजिस्टरों की एक तालिका दिखाई देंगे: Timer1InterruptFlag, Timer2InterruptFlag, ..., Timer9InterruptFlag, IOPortAToggleMask, IOPortBToggleMask, आदि x100। उच्च स्तर की भाषा में आप उन चर का उपयोग करेंगे जो बहुत अधिक भिन्न होते हैं ... या आप अधिक संरचना का उपयोग करेंगे। Timer1InterruptFlagकी तुलना में 75% irrelevent शोर है T1IF। मुझे नहीं लगता कि आप C # में वैरिएबल की एक बड़ी सूची बनाएंगे, जो मुश्किल से अलग होंगे।

— detly

@romkyns - क्या आप के बारे में पता नहीं हो सकता है तथ्य यह है कि वहाँ है कि तुम क्या वर्णन की दिशा में एक बदलाव आया। माइक्रोचिप के हालिया संकलक पुस्तकालयों के साथ आते हैं जो कि केवल रजिस्टरों की तुलना में कहीं अधिक क्रियात्मक और वर्णनात्मक हैं। UARTEnable(UART1, BITS_8, PARITY_N, STOP_1, BAUD_115200)। लेकिन वे अभी भी अविश्वसनीय रूप से भद्दे हैं, और अप्रत्यक्ष और अक्षमता को शामिल करते हैं। मैं जहां संभव हो, उनका उपयोग करने की कोशिश करता हूं, लेकिन ज्यादातर समय, मैं रजिस्टर हेरफेर को अपने स्वयं के कार्यों में लपेटता हूं और इसे उच्च-स्तरीय तर्क से कहता हूं।

— 20

@detly: CCS संकलक के पास ऐसे तरीके थे, और कुछ अन्य प्रोसेसर करते हैं। मैं आमतौर पर उन्हें नापसंद करता हूं। रजिस्टर कल्पना रजिस्टर लिखने के लिए पर्याप्त है जो रजिस्टरों का उपयोग करता है और यह किसी रीडिंग कोड को बताने के लिए पर्याप्त है जो रजिस्टरों का उपयोग करता है यह देखने के लिए कि वे रजिस्टर क्या करते हैं। यदि एक हार्डवेयर प्रिस्क्लर में N का मान लिखने का कार्य N + 1 (काफी सामान्य) की अवधि निर्धारित करता है, तो इसका सही अर्थ set_prescalar(TMR4,13);IMHO से बहुत कम स्पष्ट है TMR4->PSREG=12;। यहां तक ​​कि अगर कोई कंपाइलर मैनुअल को देखता है, तो यह पता लगाने के लिए कि पहला कोड क्या करता है, एक की संभावना अभी भी होगी ...

— 18

Answer 11

मुझे आश्चर्य है कि किसी ने भी आलस्य का उल्लेख नहीं किया है और अन्य विज्ञानों पर चर्चा नहीं की गई है। प्रोग्रामर के रूप में मेरा दैनिक कार्य मुझे दिखाता है कि एक कार्यक्रम में किसी भी प्रकार के चर के लिए नामकरण परंपराएं तीन अलग-अलग पहलुओं से प्रभावित होती हैं:

1. प्रोग्रामर की वैज्ञानिक पृष्ठभूमि।
2. प्रोग्रामर के प्रोग्रामिंग कौशल।
3. प्रोग्रामर का वातावरण।

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

---

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

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

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

Comments

किसी ने भी आलस्य का उल्लेख नहीं किया है - शायद इसलिए क्योंकि यह यहां प्रासंगिक नहीं है। और यह कि अन्य विज्ञान पर चर्चा नहीं की जाती है, ओह यह आसान है: यह साइट चर्चा के लिए नहीं है । यह सवाल और जवाब

— gnat

आलस्य एक वैध कारण है। लगभग सभी प्रोग्रामर आलसी लोग हैं (अन्यथा हम मैन्युअल रूप से सब कुछ करेंगे!)।

— थॉमस ईडिंग जूल