जबरन कोड सुधार के लाभ और नुकसान

19

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

java formatting coding-standards

— Nerdfest
स्रोत

JSP ऑटो रिफॉर्मैट? इसमें HTML / XML कोड और सुधार शामिल हैं जो बहुत आसानी से परिणामी आउटपुट को तोड़ / बदल सकते हैं।

— eda-qa मोर्ट-ओरा-वाई

23

मुझे लगता है कि ऐसा करना बहुत जरूरी है। यहाँ पर क्यों:

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

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

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

— बोहेनिया का
स्रोत

1

वैश्विक परिवर्तन पर बुलेट को बांधना वास्तव में सबसे अच्छा तरीका है, मैं सहमत हूं; इसे पूरा कर लें और किसी को भी इसके बारे में फिर से चिंता करने की ज़रूरत नहीं है।

— पैट्रिक ह्यूजेस

... जब तक आप अपना स्टाइल कन्वेंशन नहीं बदलते।

— Nerdfest

1

@Nerdfest तब आप एक ही कमिट में अपने सभी प्रोजेक्ट पर अपना नया कन्वेंशन लागू करते हैं। यह कोई बड़ी बात नहीं है।

— gizmo

2

अगर आपके व्हाट्सएप में बदलाव ठीक से नहीं हो रहा है तो आपका "डिफरेंट" टूल किस तरह का बेकार है।

— 14:33 पर eda-qa मोर्ट-ओर-वाई

2

हमेशा ऐसे अपवाद होने जा रहे हैं जहां निर्धारित शैली की तुलना में थोड़ा अलग प्रारूप संभावित क्लीनर है। ऑटो-कनवर्टिंग इस प्रकार अक्सर कुछ कोड ब्लॉक के इरादे को छिपा सकता है, जो प्रभावी रूप से कोड के दोष को जोड़ने के रूप में अच्छा है।

— 14:42 बजे eda-qa मोर्ट-ओर-वाई

10

मैं यहां अपना जवाब देने जा रहा हूं क्योंकि लोग केवल फायदे जोड़ रहे हैं। नुकसान के रूप में मैं क्या देखता हूं:

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

सीधे शब्दों में कहें, तो सम्मेलनों का एक गैर-स्वचालित सेट न्यूनतम शैली / पठनीयता आवश्यकताओं को निर्धारित करता है, जहां स्वचालित सम्मेलन न्यूनतम और अधिकतम सेट करते हैं।

मुझे याद है कि वीबी (संस्करण 5 शायद) को देखकर और इसके बारे में सबसे अधिक कष्टप्रद चीजों में से एक को खोजने के लिए यह था कि यह मेरे कोड को जबरन सुधार देगा और इसके मूल स्वरूपण से ऊपर और परे की चीजों को हटा देगा।

— Nerdfest
स्रोत

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

— जेफ

3

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

— कार्ल बेज़ेलफेल्ट

1

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

— मत्तनाज

3

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

— Woot4Moo
स्रोत

3

प्राथमिक नुकसान कस्टम स्वरूपण खो रहा है जहां यह वास्तव में मायने रखता है।

एक विशिष्ट पवित्रता की जाँच करें कि अगर () विफल हो जाएगी यदि कोई विशिष्ट स्थिति मौजूद है लेकिन पूरी नहीं हुई है ...

  if(
      (user.id == TEST_ID)
    ||(
         (user.id == UserID)
       &&( 
             ( user.type == HUMAN_USER && user.name.size() >= MIN_NAME )
           ||( user.type == EMULATION && input.source != SOURCE_INTERNAL ))
       && ( user.email == NULL || emailValidator.isValid(user.email))
       && ( (user.phone == NULL) == (user.type == EMULATION) )

       // several more lines like this.)
    ){ /* handle results */ }

यह शर्तों की तार्किक संरचना के बाद उचित इंडेंटिंग के लिए पठनीय धन्यवाद है।

अब आपके स्वचालित टूल के पास संबंधित लाइनों में विभिन्न स्थितियों के तार्किक पृथक्करण के बारे में कोई सुराग नहीं है। यह बिना किसी कारण के देखता है कि प्रत्येक पंक्ति में 3-4 स्थितियां क्यों हैं और अगली स्थिति को आधे में विभाजित करें। या यह इसे विभाजित करेगा, प्रति पंक्ति एक तुलना अभिव्यक्ति। यह स्क्रीन पर भी सुंदर लग सकता है लेकिन तर्क खो जाएगा।

— एस एफ।
स्रोत

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

— एतेफान ओरवेक

@ ThistefanOravec: इसे एक ऑटोफ़ॉर्मर के माध्यम से चलाएं और इन टिप्पणियों को लागू करें। देखें कि क्या यह अधिक पठनीय है। परीक्षण उपयोगकर्ता - हमेशा। मान्य उपयोगकर्ता नाम के साथ मानव उपयोगकर्ता। उत्सर्जित उपयोगकर्ता - केवल बाहरी स्रोत। ईमेल, यदि मौजूद है, तो मान्य होना चाहिए। मानव उपयोगकर्ताओं के पास एक फ़ोन नंबर होना चाहिए; अनुकरण - नहीं करना चाहिए। देखें कि कैसे आपकी एकल-पंक्ति टिप्पणियाँ ऑटोफ़ॉर्मैटेड कोड के साथ संरेखित होती हैं।

— एसएफ।

2

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

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

यह मेरे लिए कन्वेंशन आधारित कोडिंग का लगभग पवित्र कंघी बनानेवाले की रेती है ... आपको एक सामान्य कोड प्रारूप के फायदे मिलते हैं, लेकिन फिर भी व्यक्तिगत प्राथमिकताओं को बिना संघर्ष के समर्थन करने की अनुमति मिलती है।

— Nerdfest
स्रोत

0

यह आपकी आवश्यकताओं पर निर्भर करता है लेकिन कुछ विरोधाभास काफी मददगार होते हैं, जैसे कि हर (अगर) घुंघराले ब्रेसिज़ का पालन किया जाना चाहिए, क्योंकि अगर आप रिफैक्टरिंग कर रहे हैं तो ऐसा करना बहुत आसान है।

उस मामले पर विचार करें:

if( x == 0 ) 
   return foo;
//do something else
return bar;

यदि आप अब कुछ लॉगिंग जोड़ना चाहते हैं तो यदि आप गलती से लिख सकते हैं तो:

if( x == 0 ) 
  log.info("x was 0");
  return foo;
//do something else
return bar;

और सहजता से आपकी विधि हमेशा लौटती है foo।

संपादित करें: यह स्वचालित स्वरूपण पर नहीं, बल्कि शैली जाँच है। क्षमा करें यदि वह उत्तर विषय के रूप में अच्छी तरह से बंद था। :)

— थॉमस
स्रोत

यह एक कोड स्टाइल चीज़ अधिक है, प्रारूपण चीज़ नहीं। उसके लिए निर्मित उपकरण हैं।

@ बोहेमियन, आप सही कह रहे हैं, मैंने सवाल को गलत बताया। हमारी पसंद का बिल्ड टूल चेकस्टाइल btw है। :)

— थॉमस

0

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

— talnicolas
स्रोत

0

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

— bluefoot
स्रोत

0

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