क्या मुझे किसी के कोड में वर्तनी / व्याकरण संबंधी गलतियों को इंगित करना चाहिए? [बन्द है]

106

सह-कार्यकर्ता के कोड की समीक्षा करते समय, मुझे फ़ंक्शन नामों में कुछ वर्तनी की गलतियाँ हुईं और फ़ंक्शन और वैरिएबल नामों में 'doUserHavePermission ()' के बजाय 'doUserHasPermission ()' जैसी व्याकरणिक त्रुटियाँ भी थीं।

क्या मुझे इन पर ध्यान देना चाहिए या क्या मुझे इन पर ध्यान नहीं दिया जा रहा है?

code-reviews grammar

— राहुल
स्रोत

3

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

— री मियासका

31

हाँ। गलत वर्तनी के साथ एपीआई होने पर इसकी वास्तव में निराशा होती है। यह जंगल की आग की तरह फैलता है। इसलिए इसका जल्द से जल्द सुधार करना बेहतर है।

9

@ री: चाहे अंग्रेजी उनकी मूल भाषा हो या पेशेवर वातावरण में अप्रासंगिक न हो; यदि यह उनके लिए बहुत बुरा नहीं है, लेकिन यह कोई बहाना नहीं है, तो उन्हें समान मानकों पर रखा जाना चाहिए।

— थॉमस बोनीनी 13

4

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

— स्टीफन फुरलानी

11

HTTP-Refererमुझे अक्सर परेशान करता है। en.wikipedia.org/wiki/HTTP_referrer#Origin_of_the_term_referer

— एक भुगतान किया गया बेवकूफ

205

वर्तनी और व्याकरण त्रुटियों के साथ कोड अचूक है ।

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

इन समस्याओं को ठीक करना पांडित्यपूर्ण नहीं है, न ही यह मुख्य रूप से किसी की बुद्धिमत्ता, साक्षरता आदि के बारे में दूसरों की राय द्वारा आवश्यक है (हालांकि यह एक बड़ा दुष्प्रभाव है); यह गुणवत्ता, रखरखाव कोड लिखने के बारे में है ।

— HedgeMage
स्रोत

7

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

— opello

15

+1 - एक बार वर्तनी और व्याकरण संबंधी त्रुटियां एपीआई में अपना रास्ता बना लेती हैं, फिर से बाहर निकलना असंभव है। मैंने "गतिविधि" के बजाय "एविटिटी" लिखने के लिए तीन साल का बेहतर हिस्सा बिताया, और ऐसा करने के लिए यह हमेशा शारीरिक रूप से आहत होता है।

— जॉन बोडे

7

बेहतर या बदतर के लिए, अच्छा प्रोग्रामिंग अभ्यास अक्सर पैदल सेना की तरह कुछ के लिए नीचे आता है। इसके अलावा, मैं उस व्यक्ति को ढूंढना चाहता हूं जिसने Referrerमूल HTTP कल्पना में गलत वर्तनी की और उसे टखने में मार दिया। बेशक, यह शायद बर्नर्स-ली था और इसलिए मुझे बाद में दोषी महसूस होगा ...

— मालवोलियो

2

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

— जॉन बोडे

2

@ जॉन बोद, मुझे लगता है कि आपको एक रैपर फंक्शन बनाना चाहिए था :) C # के लिए एक साफ-सुथरी ट्रिक है (मैं इसे आज भी भूल गया)।

— जॉब

38

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

— जेसन बेकर
स्रोत

29

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

यदि यह कोड एक ग्राहक को देखने जा रहा है, तो यह बिल्कुल सही होना चाहिए। यह पसंद है या नहीं, यह आपकी कंपनी की प्रतिष्ठा को दर्शाता है।

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

— जॉन आर। स्ट्रॉहम
स्रोत

12

यह कहना कि दूसरों की धारणाओं के बारे में यह महत्वहीन लगता है। सच बताएं - वे कोड को बनाए रखने और बनाने के लिए कठिन बना रहे हैं।

— हेजमैज

5

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

— जॉन आर। स्ट्रोहम

12

@ जॉन मैं निश्चित रूप से देख सकते हैं कि एक बुरा काम स्थिति उस तरह अनावश्यक कार्य पर चलना करने के लिए विवश कर सकते हैं - लेकिन यह है एक बुरी स्थिति है कि अगर पहली जगह में एक समस्या है। इतना नाजुक अहंकार (और एक कार्यस्थल संस्कृति जो उनके शीनिगान को अनुमति देता है) के साथ कोई भी व्यवसाय शुरू करने के लिए अच्छा नहीं है।

— हेजमैज

6

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

— जल्दी_अगले

6

मैं यहाँ हेजमैज से सहमत हूँ, यदि आप एक कोड समीक्षा के दौरान इस तरह की गलतियों को इंगित नहीं कर सकते हैं (विशेषकर जब वे निष्पक्ष रूप से गलत हैं, उदाहरण के लिए प्रश्न में) तो आपको बड़ी समस्याएँ आई हैं ...

— डीन हार्डिंग

10

इसे खुद बदलें।

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

— मार्सी
स्रोत

5

और तब आपको पता चलता है कि आपने तीसरे आदमी का कोड तोड़ा है। आपको इस प्रकार की चीजों को एएसएपी तय करने की आवश्यकता है, न कि तब जब आप इसे पहले आदमी के सब कुछ

— जांचने के

यदि आप चिंतित हैं कि किसी भी कोड का एक टुकड़ा "किसी और के" कोड को तोड़ सकता है, और आपके पास बताने का कोई तरीका नहीं है, तो आपको वर्तनी से बड़ी समस्याएं हैं।

— कॉर्नेल मैसन

@CornelMasson: वास्तव में नहीं। यह एपीआई डिजाइन करने का एक महत्वपूर्ण हिस्सा है।

— ऑर्बिट

6

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

तो मैं निश्चित रूप से व्याकरण या वर्तनी की गलतियों को किसी और के कोड में इंगित करूंगा, लेकिन केवल अगर मैं पूरी तरह से आश्वस्त हूं कि यह सही है जो मैं कह रहा हूं।

6

मुझे यहाँ यह ध्यान देने योग्य है कि HTTP प्रोटोकॉल में HTTP रेफर हेडर को "रेफर" के रूप में गलत किया गया था (और हमें इसके साथ रहना होगा / हमने इसके साथ रहना सीख लिया है।) :)

— बनी खरगोश
स्रोत

10

और हम उस तरह की चीज को दोबारा कभी नहीं देखना चाहते हैं।

— डेविड थॉर्नले 20

4

मैं अन्य उत्तरों से यह कहते हुए सहमत हूं कि व्याकरण की गलतियों वाला कोड अप्राप्य है।

मैं कुछ चीजें जोड़ना चाहता हूं:

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

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

11

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

— टिन मैन

3

मैं 100% सहमत हूं कि पेशेवरों के रूप में, हमें वयस्कों के रूप में व्यवहार करना चाहिए, और इसे व्यक्तिगत रूप से नहीं लेना चाहिए। लेकिन इसे पूरी तरह से इंगित करने और सुधारने की आवश्यकता है। हां, चातुर्य का उपयोग किया जाना चाहिए, और इसे व्यक्ति के आधार पर आवश्यकतानुसार संपर्क किया जाना चाहिए। लेकिन अगर आप एक ऐसे माहौल में हैं जहाँ इस मुद्दे को पूरी तरह से टालने के लिए प्रोत्साहित किया जाता है, तो शायद यह समय निकल जाए। यह एक विषैले वातावरण की ओर इशारा करता है।

— मार्क फ्रीडमैन

किसी भी वर्तनी की त्रुटि को एक साधारण Google खोज द्वारा देखा जा सकता है

— JoelFan

2

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

— रोमन ज़ेंका
स्रोत

0

मैं इसे तभी करता हूं

यह कार्यक्रम के उपयोग को प्रभावित करता है
यह कार्यक्रम की सटीकता को प्रभावित करता है
मैं स्पष्ट रूप से जानता हूं कि लेखक सही होना चाहता है।

साइड नोट के रूप में, यदि आपके फ़ंक्शन नाम व्याकरण के लिए लंबे समय से पर्याप्त हैं, तो वे संभवतः बहुत लंबे हैं। दिए गए उदाहरण में, मैं फ़ंक्शन userHasPermission को कॉल करूंगा और "व्याकरण" को आपके कोड में स्थानांतरित करूंगा , कुछ इस तरह से:

if userHasPermission() ...

— मार्क हैरिसन
स्रोत

1

व्याकरण की गलतियों के लिए अभी भी वही क्षमता है, हालांकि, चूंकि इस मामले userHavePermission()में गलत होगा।

— डीन हार्डिंग

लेकिन ठीक यही बात है !! userHasPermission()तात्पर्य यह है कि यह व्याकरण की वजह से एक bool रिटर्न ~ या ~ यह अर्थ हो सकता है कि यह सेट उपयोगकर्ता की अनुमति। (अधिकारी के पास पुल है: उपयोगकर्ता की अनुमति है)। यह अभी भी अस्पष्ट है।

— स्टीफन फुरलानी

जबकि मैं सहमत हूं कि क्यू में उदाहरण के नाम अनावश्यक रूप से लंबे हैं, मैं "बहुत लंबे" सामान्यीकरण के बारे में चेतावनी देता हूं। इस मामले में, अवधारणा को कम शब्दों में व्यक्त किया जा सकता है, इसलिए इसे छोटा होना चाहिए। हालांकि, "बहुत लंबा" क्या है? क्या कोई वर्ण या शब्द सीमा है?

— LS

0

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

व्यक्तिगत रूप से, जब ऐसा अक्सर होता है और इतने सारे टीम के सदस्यों द्वारा कि मैं प्रोजेक्ट में शामिल होने से पहले भी कोड लिख सकता था, तो मैं इसे अनदेखा कर देता हूं, क्योंकि यह सिर्फ मायने नहीं रखेगा।

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

— डैनियल हर्शकोविच
स्रोत

0

स्वर्ण नियम लागू

दूसरों के साथ वैसा ही करो जैसा तुम उनसे करोगे।

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

— kevpie
स्रोत

2

अस्पष्टता के लिए -1 - मुझे नहीं पता कि आप प्रश्नकर्ता को क्या करने की सलाह दे रहे हैं।

— हेजमैज

@ हेजमैज, मैं ओपी को en.wikipedia.org/wiki/The_Golden_Rule

— kevpie

2

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

— हेजमैज

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

— पलकविहीनता

सलाह का मतलब है कि ओपी संचालित करता है कि वह कैसे इलाज करना चाहता है। बॉब का इलाज करने के लिए नहीं कि बॉब कैसे इलाज करना चाहते हैं। मैं ओपी को बॉब को सही करने के लिए प्रोत्साहित कर रहा था क्योंकि वह (ओपी) उसी त्रुटियों के लिए सही होना चाहेगा, विशेष रूप से ओपी द्वारा साझा किए गए संदर्भ में।

— केवपी

0

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

— Apalala
स्रोत

3

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

— मैथ्यू फ़्लेशेन

उस तरह का स्वचालन इन समस्याओं को हल नहीं करता है, यह सिर्फ कुछ गलतियों को पकड़ता है जो लोग करते हैं।

— 22

स्वतः सुधार ??? इंटरनेट पर स्वतः पूर्ण "विफल" के बहुत सारे उदाहरण हैं। यह निश्चित रूप से अच्छा नहीं है।

— फ्लोरियन एफ

0

यह कोड में एक छोटी सी गलती है, लेकिन एक गलती है। इसे किसी अन्य गलती की तरह समझें जो आपको मिलती है। मेरी नीति हमेशा यह मानने की है कि मेरे सहकर्मी सक्षम हैं और जब तक वे अन्यथा साबित नहीं होते हैं, तब तक उनके साथ ऐसा व्यवहार करें।

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

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

— overstood
स्रोत

-1

userPermission () शायद? -

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

— mplungjan
स्रोत

बिना टिप्पणी के अपमान करना अपमानजनक है।

— मपलुंगजन

-1

सुनिश्चित करें कि यह इंगित करता है, लेकिन वर्तनी की गलतियों के लिए अपना समय बर्बाद न करें। अपने CI पर इसे स्वचालित करने के लिए एक उपकरण का उपयोग करें। .Net fxCop पर ऐसा कर सकते हैं ...

— khebbie
स्रोत

-2

यह काफी हद तक इस बात पर निर्भर करता है कि गलतियाँ क्या हैं, वे कितनी सामान्य और कितनी बुरी हैं, और क्या यह वास्तव में एक गलती वाली गलती है या सिर्फ यह नहीं कि आप इसे कैसे कहेंगे।

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

/ शेख़ी :)

— JohnL
स्रोत

2

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

— डेविड थॉर्नले 20

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

— जॉनएल