क्या आप मूल प्रोग्रामर के नामकरण सम्मेलन का पालन करते हैं?

Question

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

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

मैं अपने नामकरण सम्मेलन के साथ जारी रखने के लिए केवल पढ़ने के लिए इच्छुक हूं।

Answer 1

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

Answer 2

अक्सर, शैली मार्गदर्शिका के अनुरूप एक कोडबेस में थोक परिवर्तन करना थोड़ा अतिरिक्त मूल्य के साथ नई बग पेश करने का एक तरीका है।

इसका मतलब यह है कि या तो आप चाहिए:

1. अद्यतन कोड आप पर काम कर रहे दिशानिर्देश के अनुरूप के रूप में आप इस पर काम करते हैं।

2. भविष्य में रखरखाव प्रयासों को सहयोग करने के लिए कोड में सम्मेलनों का उपयोग करें।

मैं 2 की सिफारिश करता हूं, लेकिन हंगेरियन नोटेशन मेरी आंखें खून बहता है: पी।

Answer 3

आम तौर पर, हाँ, मैं इस परिदृश्य में मानकों पर सम्मेलन और पठनीयता के लिए जाऊंगा। कोई भी उस उत्तर को पसंद नहीं करता है, लेकिन कोड को लंबे समय तक बनाए रखने के लिए सही काम करना सही है।

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

Answer 4

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

बेशक, यदि मूल कोड वास्तव में बेकार है, तो सभी दांव बंद हैं।

Answer 5

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

यही कहा, मैं हंगेरी संकेतन के कुछ ही लेकिन कुछ भी कर रहा हूँ, लेकिन क्या आप के साथ काम करने के लिए मिल गया है है कि यदि ...

Answer 6

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

Answer 7

अगर मैं कोड पढ़ सकते हैं, मैं (कोशिश) एक ही सम्मेलनों लेने के लिए अगर यह पठनीय नहीं है वैसे भी मैं refactor करने के लिए की जरूरत है और इस तरह यह बदल रहा है काफी

Answer 8

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

Answer 9

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

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

Answer 10

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

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

Answer 11

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

Answer 12

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

Answer 13

रोम में रोम के रूप में करते समय।

(सूचकांक चर नाम, उदाहरण के लिए "iArrayIndex ++" को छोड़कर। कि मूर्खता condoning बंद करो।)

Answer 14

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

Answer 15

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

आप पता लगाना एक समारोह है, क्योंकि यह खराब नामित चरों का उपयोग करता है क्या करता है, आदि 40 घंटे खर्च करते हैं, तो आप refactor/स्पष्टता के लिए नाम बदलने चाहिए/कमेंट्री जोड़ने/जो कुछ भी स्थिति के लिए उपयुक्त है।

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

Answer 16

मैं करता हूं, लेकिन दुर्भाग्यवश, वहां मेरे सामने कई डेवलपर इस नियम में नहीं रहते थे, इसलिए मेरे पास से चुनने के लिए कई नामकरण सम्मेलन हैं।

लेकिन कभी-कभी हमें अंत में चीजों को सीधे सेट करने का समय मिलता है, यह अच्छा और साफ होगा।

Answer 17

यदि कोड में पहले से ही एक सतत शैली है, जिसमें नामकरण शामिल है, तो मैं इसका पालन करने का प्रयास करता हूं। यदि पिछले प्रोग्रामर सुसंगत नहीं थे, तो यदि कोई कंपनी मानक नहीं है तो मैं कंपनी मानक, या मेरे व्यक्तिगत मानकों को लागू करने के लिए स्वतंत्र महसूस करता हूं।

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

Answer 18

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

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

Answer 19

हां। मैंने वास्तव में इसे एक मानक दस्तावेज़ में लिखा था। मैंने अपनी वर्तमान कंपनी में बनाया:

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

1. एकाधिक, अलग शैलियों/एक एकल मॉड्यूल/फ़ाइल के भीतर पैटर्न (जिनमें से उद्देश्य खंडन होने से बचाने के मानकों और बाधा रखरखाव)।
2. मौजूदा कोड को दोबारा करने का प्रयास अनावश्यक रूप से अधिक महंगा (समय लेने वाली और नई बगों के परिचय के लिए अनुकूल) होने का अनुमान है।

Answer 20

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

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