कैसे पता करें कि स्रोत कोड में वर्तनी की गलतियाँ एक गंभीर मुद्दा है या नहीं? [बन्द है]

Question

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

ArgumnetCount
Timeount
Gor message from queue 

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

ईमेल, प्रेजेंटेशन, डॉक्यूमेंट, सॉफ्टवेयर डेवलपमेंट कंपनी में जो भी लिखित जानकारी हमारे पास होती है, उस पर भी ये पाया जाना है।

मैं जानना चाहता हूं कि यह कैसे पता लगाया जाए कि यह एक गंभीर मुद्दा है या नहीं?

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

Comments

संबंधित: मैं उन डेवलपर्स से कैसे निपट सकता हूं जो कोड में अंग्रेजी का उपयोग नहीं करते हैं?

— यानिस

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

— आर्सेनी मूरज़ेंको

@ मेनमा: प्रोग्रामिंग भाषा में लिखना मानव भाषा में लिखने से पर्याप्त भिन्न होता है। जब आप YouTube टिप्पणियों के लिए लिखते हैं, तो यह पूरी तरह से स्पष्ट है कि आप मानव पाठकों के लिए लिखते हैं, लेकिन स्रोत कोड के साथ, एक सामान्य रवैया यह है कि जब तक यह संकलन और काम करता है, तब तक सब कुछ ठीक है।

— tdammers

@tdammers: जब आप स्रोत कोड लिखते हैं, या स्टैक एक्सचेंज पर एक प्रश्न, या एक पुस्तक, या एक YouTube टिप्पणी, या आपकी ई-कॉमर्स वेबसाइट के मुख पृष्ठ की एक सामग्री, हर मामले में आप उन लोगों के लिए करते हैं जो पढ़ेंगे यह। प्रोग्रामिंग अलग नहीं है, और आपका कंपाइलर परवाह नहीं करता है यदि आप अपने चर का नाम देते हैं ArgumentCountया ArgumnetCount।

— आर्सेनी मूरज़ेंको

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

— टॉम स्क्वायर्स

Answer 1

वर्तनी की गलतियाँ दो चीजों में से एक हो सकती हैं:

• जो व्यक्ति उन्हें बनाता है, वह अंग्रेजी में कुशल नहीं है, और उचित साधनों (शब्दकोशों, वर्तनी चेकर्स, आदि) का उपयोग करके क्षतिपूर्ति करने के लिए समय नहीं लेता है।
• उन्हें बनाने वाला व्यक्ति अंग्रेजी में पारंगत है, लेकिन उसे वर्तनी की कोई परवाह नहीं है।

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

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

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

Comments

मैं जोड़ना होगा कि वर्तनी की गलतियां डिबग समस्याओं जहां के लिए कठिन पैदा कर सकता है thisVaraibleऔर thisVariable'तकनीकी रूप से' सही नज़र लगभग एक ही है और कर रहे हैं।

— स्पेंसर रथबुन

+1, लेकिन कथन: "यदि आप अपने विचारों को स्पष्ट रूप से अंग्रेजी में व्यक्त नहीं कर सकते हैं, तो संभावना है कि आप उन्हें प्रोग्रामिंग भाषा में अच्छी तरह से व्यक्त नहीं कर सकते हैं" या तो बिल्कुल बकवास है!

— मार्टिन बा

@ मर्टिन: मुझे अभी तक एक अत्याचारी लेखन शैली के साथ एक विश्वस्तरीय प्रोग्रामर ढूंढना है। मुझे पता है कि सभी शीर्ष प्रोग्रामर स्पष्ट रूप से लिखित अंग्रेजी, संक्षिप्त लेखन में सक्षम हैं; उनमें से कुछ (नुथ, दिज्क्स्त्र) कुछ हद तक अपनी लेखन शैली के लिए भी प्रसिद्ध हैं।

— तदमर्स

@tdammers: यदि वे अंग्रेजी मूल वक्ता हैं, तो मैं सहमत हूँ। लेकिन अगर आपके पास एक अलग मातृभाषा है, तो आपके पास अंग्रेजी का एक भयानक भयानक समझ हो सकता है और फिर भी एक अच्छा प्रोग्रामर हो सकता है। यही मेरा मतलब बकवास से था। मैं मानता हूं कि अच्छे प्रोग्रामर भी अच्छी तरह से लिखने में सक्षम हैं - वे जिस भी प्राकृतिक भाषा में धाराप्रवाह हैं। थोड़ी सी अंग्रेजी स्पष्ट रूप से नेट के आसपास अपना रास्ता खोजने में मदद करती है, लेकिन आपको किसी भी तरह से धाराप्रवाह होने की आवश्यकता नहीं है एक अच्छा लेखक या अंग्रेजी में किसी भी व्याकरण या शैली की समझ है :-)

— मार्टिन बा

ध्यान दें कि दिज्क्स्त्र एक देशी वक्ता नहीं है ...

— tdammers

Answer 2

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

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

एक प्रोग्रामर होने के बारे में टाइपो, कॉमा, अर्धविराम, डॉट्स के साथ सटीक और सावधान रहना है, जो कि ज्यादातर समय मानव-भाषा-अज्ञेय है।

Answer 3

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

Answer 4

यदि यह समस्या आपको परेशान करती है, तो अधिकांश IDE अब टिप्पणियों में वर्तनी जाँच की अनुमति देते हैं ताकि डिस्लेक्सिक्स कम से कम ऐसे दिख सकें जैसे वे जानते हैं कि वर्तनी कैसे जानी जाती है। यह निश्चित रूप से मेरी मदद करता है! इसलिए अच्छी वर्तनी के लिए यह एक तुच्छ "फिक्स" है।

Comments

यदि आप वोट डाउन करते हैं तो क्या आप यह बताने में समय लगा सकते हैं कि मैं अपने उत्तर को बेहतर क्यों बना सकता हूं?

— सारथ्रियन - एसई के खिलाफ

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

— कोनराड मोरावस्की

Answer 5

सार्वजनिक वर्ग के नामों और विधियों में वर्तनी की त्रुटियां केवल अव्यवसायिक हैं। वे समय और पैसा खर्च करते हैं। वे जावा जैसी वैधानिक रूप से टाइप की जाने वाली भाषाओं में दर्दनाक हैं, जहाँ IDE क्लास और मेथड नामों का मेन्यू तैयार कर सकता है। वे गतिशील रूप से टाइप की गई भाषाओं में असहनीय हैं।

इससे भी बदतर डेटाबेस तालिका के नाम और स्तंभ नामों में वर्तनी की त्रुटियां हैं।

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

Answer 6

स्रोत कोड में, आंतरिक प्रस्तुतियाँ और दस्तावेज़ आदि छोटे टाइपो जो अर्थ में परिवर्तन नहीं करते हैं या बाधा समझ एक छिद्र नहीं हैं। यदि आप उन्हें परेशान करते हैं तो बस उन्हें स्वयं स्रोत में ठीक करें।

इसके अलावा, विशेष रूप से टिप्पणियों में, पदार्थ रूप से अधिक महत्वपूर्ण है। यहाँ नहीं

स्ट्रिंग s = "विकिपीडिया"; / * वैरिएबल s के लिए "विकिपीडिया" मान निर्दिष्ट करता है। * /

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

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

सार्वजनिक रूप से दिखाई देने वाला सामान निश्चित रूप से सावधानीपूर्वक प्रूफ-रीड होना चाहिए।

Comments

कृपया मुझे बताएं कि आपने जानबूझकर "पोरबलम" टाइप किया है। :)

— pdr

बेशक मैंने किया। यदि आप इसे परेशान कर रहे हैं, तो आप इसे ठीक कर सकते हैं;)

— जूनस पुलकका

अरे नहीं। मैंने इसे अपमानजनक रूप से मनोरंजक पाया।

— पीडीआर

"कुछ लोग अधिक सावधान लेखक हैं ..." हाँ, और बहुत ही लोग अधिक सावधान प्रोग्रामर हैं। मुझे एक अच्छे प्रोग्रामर से मिलना बाकी है, जो लिखित संचार में भी सावधान नहीं था।

— केविन क्लाइन

Answer 7

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

उदाहरण के लिए, यह पहली नज़र से स्पष्ट नहीं है यदि Gor message from queueइसका अर्थ है "कतार से एक संदेश मिला" या "कतार से GOR संदेश"। आपको टिप्पणी का अर्थ समझने के लिए कोड को पढ़ना होगा (इस प्रकार टिप्पणी की वस्तु को पराजित करना)।

आपको अपनी कंपनी में कोड समीक्षा लागू करने के लिए कहना चाहिए। तब आप रचनात्मक तरीके से लोगों की "आलोचना" कर सकते हैं जबकि वे आपके साथ भी ऐसा ही करते हैं।

Answer 8

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

एकमात्र तरीका मैं ऐसा कर सकता हूं जो रखरखाव करने वाले लोगों से बात करना होगा, और आप यह पूछकर शुरू कर सकते हैं कि किसी के पास कोड के बाद कठिन समय था जिसमें गलत वर्तनी थी।

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

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

Comments

माइक, उत्तर की विसंगति और सवाल हाल ही में बड़े पैमाने पर संपादित किया गया है। Rev 3 तक, सवाल का शीर्षक आप सोर्स कोड के बारे में क्या सोचते हैं? और पाठ इसके अनुरूप था

— gnat

यह समझ में आता है @gnat; मैंने अपने उत्तर से अतिरिक्त पैराग्राफ हटा दिया है।

— माइक पार्टरिज

Answer 9

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

मैं सिस्टम के लिए स्पेक्स को डबल-चेक करूँगा (यदि वे मौजूद हैं) और समग्र डिज़ाइन की जांच करेंगे; अगर आपको कुछ छेद मिले तो मुझे आश्चर्य नहीं होगा।

Answer 10

यह वास्तव में दो अलग-अलग, लेकिन संबंधित मुद्दे हैं। यह इस बात पर निर्भर करता है कि गलतियाँ कहाँ हैं:

1) सोर्स कोड में। यदि आपके पास एक पहचानकर्ता है ArgumnetCount, जो किसी के साथ आने पर सही समस्याएं पैदा कर सकता है और सही वर्तनी का उपयोग कर सकता है । इसलिए आपको जब भी संभव हो उन गलतियों को ठीक करना चाहिए। यदि आपको बैकवर्ड एपीआई संगतता को संरक्षित करने की आवश्यकता है, तो आप कुछ ऐसा कर सकते हैं:

/**
 * @deprecated - use setArgumentCount()
 */
public void setArgumnetCount(int c) {
    setArgumentCount(c);
}

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

Answer 11

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

इसे हाथ से निकलने न दें। सभी को शिक्षित करने का प्रयास करें कि कोड मेंटेनर माइंड रीडर नहीं हैं।

Comments

"हर किसी को शिक्षित करने की कोशिश करें" - मैंने किया और अब वे मुझे गलत करने के लिए गलत वर्तनी / गलत बातें करते हैं। यह प्यार करता हूँ ...

— MetalMikester

@MetalMikester: अधिक पेशेवर दुकान देखने का समय हो सकता है।

— केविन क्लाइन

Answer 12

खैर, यह एक कई-पक्षीय सांस्कृतिक समस्या है।

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

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

Answer 13

यह रंग है या रंग? आप अंग्रेजी के किस संस्करण को सही मानते हैं? एक आदमी सही वर्तनी है एक और आदमी एक जंगी युद्ध शुरू करने के लिए बहाना है।

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

Answer 14

मेरे पास एक अधिकतम है: साफ कोड का मतलब यह नहीं है कि एक साफ दिमाग है, लेकिन आपत्ति निश्चित रूप से सच है: साफ कोड, बेकार दिमाग।

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

हां, यह उत्पाद के लिए, टीम के लिए और व्यक्तियों के लिए एक गंभीर मुद्दा है।

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

Comments

इससे पहले के 14 उत्तरों में बताए गए और स्पष्ट किए गए बिंदुओं पर कुछ भी नहीं दिया गया। शायद ही इस तरह की सामग्री के साथ 3 साल पुराना सवाल टकराने लायक है

— Gnat