गो के गोफेट और diff/VCS मुद्दे?

Question

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

अगले पेज पर:

http://golang.org/doc/effective_go.html 

"स्वरूपण" पैरा के तहत, यह लिखा है कि:

एक उदाहरण के रूप में, वहाँ पर टिप्पणी अस्तर समय बिताने की आवश्यकता नहीं है एक संरचना के क्षेत्र। गोफमेट आपके लिए ऐसा करेगा।

type T struct { 
    name string // name of the object 
    value int // its value 
} 

हालांकि मुझे समझ नहीं आता कि यह कैसे संभवतः diff और VCSes साथ अच्छा खेल सकते हैं: घोषणा

type T struct { 
    name string // name of the object 
    value int // its value 
} 

gofmt कॉलम लाइन अप होगा देखते हुए।

उदाहरण के लिए, अगर मैं एक नई लाइन था:

confuzzabler int // doo doo be doo 

और एक diff चलाने के लिए, मैं इस मिलना चाहिए:

2d1 
<  confuzzabler int // doo doo be doo 
7d5 
< 

और जीवन सब अच्छा होगा: भिन्नता से पता चलता है एकमात्र पंक्ति जो बदल गई।

लेकिन अगर मैं gofmt मैं यह मिल गया फिर से चलाएँ:

type T struct { 
    confuzzabler int // doo doo be doo 
    name   string // name of the object 
    value  int // its value 
} 

और अब मैं फिर से चलाने के अंतर और मैं इस:

2,4c2,3 
<  confuzzabler int // doo doo be doo 
<  name   string // name of the object 
<  value  int // its value 
--- 
>  name string // name of the object 
>  value int // its value 
7d5 
< 

जो एक अत्यधिक भ्रामक है और भ्रामक diff आउटपुट क्योंकि केवल एक पंक्ति बदल गई।

आप इसे एक डेवलपर के रूप में कैसे सौदा करते हैं?

Answer 1

diff आउटपुट की तुलना में, यह स्पष्ट है कि क्या हुआ। यह न तो भ्रमित और न ही भ्रामक है।

Answer 2

$ diff --help|grep -i white 
    -b --ignore-space-change Ignore changes in the amount of white space. 
    -w --ignore-all-space Ignore all white space. 

VCS में समस्या होने के रूप में, यदि आप कोड अपने आप स्वरूपण रहे थे कुछ स्थापित सम्मेलन निम्नलिखित (यहाँ यह मान सम्मेलन है क्या gofmt इस प्रकार हैं) आप मैन्युअल रूप से यह है कि कोड ब्लॉक वास्तव में रास्ते में खाली स्थान के पुन: स्वरूपित होगा gofmt ने किया था, और इस परिवर्तन को किसी भी वीसीएस द्वारा बदलाव के रूप में गिना जाएगा। तो मुझे वास्तव में इस मामले में अर्थशास्त्र के साथ कोई समस्या नहीं दिख रही है। यदि आप इसके बजाए वीसीएसई द्वारा प्रदान किए गए अलग-अलग उपकरणों के बारे में परवाह करते हैं तो आपको शायद यह देखना चाहिए कि वे उल्लिखित जीएनयू diff के रूप में व्हाइटस्पेस परिवर्तनों को अनदेखा करने का समर्थन करते हैं या नहीं। FWIW git diff उसी -b कमांड लाइन विकल्प के साथ इसका समर्थन करता है।

Answer 3

आपका जाओ आधारित परियोजना मानकों की तरह कुछ हुक्म चलाना चाहिए: इससे पहले कि किसी भी जाओ कोड VCS के लिए प्रतिबद्ध है

, यह gofmt साथ स्वरूपित है। यह एकमात्र स्वीकार्य प्रारूप है।

तब कोई तर्क नहीं है; अगर कोड gofmt के माध्यम से अपरिवर्तित हो जाता है, तो सब ठीक है। gofmt के माध्यम से पारित होने पर यह बदलता है, तो gofmt से आउटपुट का उपयोग करें। संपादन करते समय आप क्या करते हैं (अन्य कोडिंग मानकों के अधीन), लेकिन यह आपके वीसीएस में चेक किए गए किसी भी कोड के लिए एक आवश्यकता है।

Answer 4

यदि यह वास्तव में आपको परेशान करता है, तो दो चेकइन करें।

पहला चेक confuzzabler जोड़ता है। एक उचित टिप्पणी है "टी में नया चर जोड़ना"। आपका अंतर उस कोड से अलग हो जाएगा जिसे आपने वास्तव में बदला है।

फिर, gofmt प्रदर्शन करें।

दूसरी प्रतिबद्धता सिर्फ परिवर्तन स्वरूपण कर रही है और एक उचित प्रतिबद्धता संदेश "gofmt" होगा। यहां अंतर केवल कोड होगा जो gofmt बदल गया है।