क्या मुझे अन्य लोगों के कोड को साफ करने के लिए रिशेर्पर का उपयोग करना चाहिए?

Question

मैं काम पर Resharper का उपयोग करें। मेरे कुछ सहयोगी नहीं करते हैं।

जब मैं कुछ कोड खोलता हूं जो किसी को लिखा नहीं गया है, तो यह मेरी स्क्रीन पर नारंगी की मात्रा से तुरंत स्पष्ट है।

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

मुझे लगता है कि मैं अपने विकल्पों को देखने के मोटे तौर पर

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

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

3) ऑरेंज सिर्फ लाल लेकिन हल्का है। एफ 12 फिर Alt + हरे रंग तक दर्ज करें।

4) नारंगी भूल जाओ, उस राक्षस 700 लाइन फ़ंक्शन को देखें। यह 1 99 7 क्या है? व्यस्त होने का समय ... और यदि आपके पास समय है, तो अपने सहयोगी को हमारे अच्छे दोस्त और सलाहकार श्री फाउलर से परिचय दें।

मैं इस बात के बीच विकल्पों में फंस जाता हूं कि मुझे कितना समय मिला है, इस कोड के लिए अब मैं कितना हद तक जिम्मेदार हूं, और कोड कितना जटिल दिखता है (जो मुझे आमतौर पर 1 या 4 के लिए जा सकता है)।

ऐसा लगता है 4 विकल्पों में से एक की तरह एक मैं हालांकि के लिए प्रयास कर रहा हूँ होना चाहिए, लेकिन मुझे नहीं पता कि जो एक

Answer 1

"Leave the campsite cleaner than you found it." 

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

Answer 2

मैं एक "पुनः स्वरूपित" वास्तविक तर्क किसी को भी बदलने से पहले चेक-करते हैं यह, जिस तरह से आप देख सकते हैं कि क्या बदल गया है।

Answer 3

आपकी टीम को मानक पर सहमत होना चाहिए। अगर कोई अन्य उपकरण का उपयोग करता है, तो आप खुद को एक अनजान संपादन युद्ध में पा सकते हैं।

लेकिन यदि आप सभी सहमत हैं, तो हाँ। जैसे ही आप जाते हैं कोड को साफ़ करें।

Answer 4

यदि आपकी टीम में विकास उपकरण समान नहीं हैं तो अंततः और भी परेशानी होगी। ऊपर दिए गए "reformat" चेक-इन का पालन करें और अपने सहयोगियों के साथ टूलसेट को मानकीकृत करें, या तो resharper ड्रॉप करें या सभी को स्वरूपण जादू छड़ी दें।

Answer 5

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

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

Answer 6

अनावश्यक रिफैक्टरिंग केवल यही है - अनावश्यक। यह भंडार इतिहास लॉग को बंद कर देता है और आप बग पेश कर सकते हैं।

यदि "अर्थहीन" सामान (दस्तावेज़ीकरण, टिप्पणियां इत्यादि) को एक निश्चित तरीके से स्वरूपित किया जाना चाहिए, और यह आपके विकास मानकों पर निर्भर नहीं है, तो मैं इसे एक बार में जितनी संभव हो सके चेकइन में करूँगा ।

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

Answer 7

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

Answer 8

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

Answer 9

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

Answer 10

चूंकि अधिकांश लोगों ने पहले ही कहा है, हाँ, रिफैक्टर करने के लिए बेहतर और इसे साफ छोड़ दें।

रिफैक्टरिंग हर किसी को बेहतर होने में मदद करता है, और हर किसी को रिफैक्टरिंग टूल्स (मेरे लिए कोडरश) तक पहुंच प्राप्त करनी चाहिए।

हालांकि, अपने सहयोगियों रिफैक्टरिंग प्यार साझा नहीं कर रहे हैं, तो यह एक अच्छा अवसर आप उन्हें स्पष्ट करने के लिए है :)