ClangFormat स्रोत कोड लिनक्स में स्वरूपण: समस्याएं और समाधान

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

समस्याओं का प्रारूपण और उन्हें हल करने के तरीके

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

फ़ॉर्मेटर्स के साथ मुख्य समस्या यह है कि वे पूरी फ़ाइलों को बदलते हैं, न कि केवल परिवर्तित लाइनों को। हम आपको बताएंगे कि हमने इलेक्ट्रॉनिक्स के लिए फर्मवेयर विकसित करने की एक परियोजना के एक भाग के रूप में ClangFormat का उपयोग करते हुए इसे कैसे निपटाया, जहां C ++ मुख्य भाषा थी। कई लोगों ने टीम में काम किया, इसलिए हमारे लिए एक समान कोड शैली प्रदान करना महत्वपूर्ण था। हमारा समाधान न केवल C ++ प्रोग्रामर के लिए, बल्कि C, ऑब्जेक्टिव-सी, जावास्क्रिप्ट, जावा, प्रोटोबॉफ़ में कोड लिखने वालों के लिए भी उपयुक्त हो सकता है।

स्वरूपण के लिए, हमने क्लैंग-फॉर्मेट-डिफरेंस-6.0 का उपयोग किया। शुरुआत में, उन्होंने टीम शुरू की

git diff -U0 - कोई-रंग नहीं | clang-format-diff-6.0 -i -p1 , लेकिन इसके साथ समस्याएं थीं:

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

निर्णय

परिणाम निम्नलिखित श-लिपि था, प्री-कमिट के रूप में चला - हुक फॉर गिट

#!/bin/sh CLANG_FORMAT="clang-format-diff-6.0 -p1 -v -sort-includes -style=Chromium -iregex '.*\.(cxx|cpp|hpp|h)$' " GIT_DIFF="git diff -U0 --no-color " GIT_APPLY="git apply -v -p0 - " FORMATTER_DIFF=$(eval ${GIT_DIFF} --staged | eval ${CLANG_FORMAT}) echo "\n------Format code hook is called-------" if [ -z "${FORMATTER_DIFF}" ]; then echo "Nothing to be formatted" else echo "${FORMATTER_DIFF}" echo "${FORMATTER_DIFF}" | eval ${GIT_APPLY} --cached echo " ---Format of staged area completed. Begin format unstaged files---" eval ${GIT_DIFF} | eval ${CLANG_FORMAT} | eval ${GIT_APPLY} fi echo "------Format code hook is completed----\n" exit 0 

स्क्रिप्ट क्या करती है:
GIT_DIFF = "git diff -U0 --no-color" - कोड में परिवर्तन जो क्लैंग-फॉर्मेट-डिफरेंस-6.0 पर इनपुट होगा ।

• -U0 : आमतौर पर गिट भिन्न तथाकथित "संदर्भ" को प्रदर्शित करता है: कोड की कुछ अपरिवर्तित रेखाएं उनके आसपास होती हैं जिन्हें बदल दिया गया है। लेकिन क्लैंग-फॉर्मेट-डिफरेंट-6.0 उन्हें भी फॉरमेट करता है! इसलिए, इस मामले में संदर्भ की आवश्यकता नहीं है।

CLANG_FORMAT = "clang-format-diff-6.0 -p1 -v -sort -style = Chromium -iregex '*। * (Cxx | cpp | hpp | h) $'" - मानक के माध्यम से स्वरूपण के लिए एक कमांड प्राप्त हुई है। इनपुट।

• clang-format-diff-6.0 - एक स्क्रिप्ट clang-format-6.0 पैकेज से। अन्य संस्करण हैं, लेकिन सभी परीक्षण केवल इस एक पर थे।
• -p1 डॉक्यूमेंटेशन में उदाहरणों से लिया गया है , git diff आउटपुट के साथ अनुकूलता प्रदान करता है।
• -स्टाइल = क्रोमियम - रेडी-मेड कोड स्वरूप शैली प्रीसेट। अन्य संभावित मान: LLVM, Google, Mozilla, WebKit ।
  
• -sort- शामिल है - वर्णानुक्रम में #include निर्देशों (वैकल्पिक) को सॉर्ट करने का विकल्प।
• -iregex '। *। \ _ (cxx | cpp | hpp | h) $' एक नियमित अभिव्यक्ति है जो एक्सटेंशन के साथ फ़ाइल नामों को फ़िल्टर करती है। केवल उन एक्सटेंशनों को प्रारूपित करने की आवश्यकता है जो यहां सूचीबद्ध हैं। यह प्रोग्राम को गिरने और अनपेक्षित ग्लिच से बचाएगा। सबसे अधिक संभावना है कि सूची को नई परियोजनाओं में पूरक होने की आवश्यकता होगी। C ++ के अलावा, आप C / ऑब्जेक्टिव-सी / जावास्क्रिप्ट / जावा / प्रोटोबॉफ़ को प्रारूपित कर सकते हैं। हालांकि हमने इस प्रकार की फाइलों का परीक्षण नहीं किया है।

GIT_APPLY = "git apply -v -p0 -" - पिछले कमांड द्वारा जारी किए गए पैच को कोड पर लागू करें।

• -p0 : डिफ़ॉल्ट रूप से, git फ़ाइल पथ में पहले घटक को लागू करता है, यह उस प्रारूप के अनुकूल नहीं है जो clang-format-diff-6.0 का उत्पादन करता है। यह स्किपिंग यहाँ अक्षम है।

FORMATTER_DIFF = $ (eval $ {GIT_DIFF} --staged। Eval $ {CLANG_FORMAT}) - इंडेक्स के लिए फ़ॉर्मेटर परिवर्तन।

इको "$ {FORMATTER_DIFF}" | eval $ {GIT_APPLY} - अनुक्रमित (कोड जोड़ने के बाद) इंडेक्स में स्रोत कोड को स्वरूपित करता है। दुर्भाग्य से, कोई हुक नहीं है जो फाइलों को सूचकांक में जोड़ने से पहले काम करता है। इसलिए, स्वरूपण को दो भागों में विभाजित किया गया है: प्रारूपण जो सूचकांक में है और अलग से क्या सूचकांक में नहीं जोड़ा जाता है।

eval $ {GIT_DIFF} | eval $ {CLANG_FORMAT} | eval $ {GIT_APPLY} - कोड स्वरूपण सूचकांक में नहीं है (यह केवल तब शुरू होता है जब सूचकांक में कुछ स्वरूपित किया गया हो)। प्रोजेक्ट में सामान्य सभी मौजूदा परिवर्तन (संस्करण नियंत्रण के तहत), और न केवल पिछले चरण से। यह एक विवादास्पद है, पहली नज़र में, निर्णय। लेकिन यह सुविधाजनक निकला, क्योंकि जल्द या बाद में अन्य परिवर्तनों को भी स्वरूपित किया जाना चाहिए। आप -i विकल्प के साथ "| eval $ {GIT_APPLY}" को बदल सकते हैं, जो $ {CLANG_FORMAT} को फाइलों को बदलने के लिए मजबूर करेगा।

कार्य प्रदर्शन

1. Clang-format-6.0 स्थापित करें
   
2. cd / tmp && mkdir temp_project && cd temp_project
   
3. गिट इनिट
   
4. संस्करण नियंत्रण जोड़ें और नाम के तहत किसी भी C ++ फ़ाइल को गलत करें ।pp । अधिमानतः> 50 पंक्तियों के बिना कोड के।
   
5. ऊपर दिखाई गई .it / हुक / पूर्व-प्रतिबद्ध स्क्रिप्ट बनाएं।
   
6. स्क्रिप्ट चलाने के अधिकार को असाइन करें (git के लिए): chmod + x .git / हुक / प्री-कमिट ।
   
7. स्क्रिप्ट .it / हुक / प्री-कमेंट को मैन्युअल रूप से चलाएँ, यह दुभाषिया त्रुटियों के बिना, "कुछ भी नहीं स्वरूपित करने के लिए" संदेश के साथ चलाया जाना चाहिए।
   
8. सामग्री के साथ file.cpp को int main बनाएं () {for (int i = 0; i <100; ++ i) {std :: cout << "पहला मामला" << std :: endl; std :: cout << "दूसरा मामला" << std :: endl; std :: cout << "तीसरा मामला" << std :: endl; }} एक लाइन के साथ या दूसरी खराब फॉर्मेटिंग के साथ। अंत में - लाइन फीड!
   
9. git add file.cpp && git प्रतिबद्ध -m "file.cpp" एक स्क्रिप्ट से संदेश होना चाहिए जैसे "पैच फ़ाइल ।pp बिना त्रुटियों के लागू किया गया । "
   
10. git log -p -1 को एक स्वरूपित फ़ाइल के अतिरिक्त दिखाना चाहिए।
    
11. अगर file.cpp को वास्तव में प्रारूपित किया गया है, तो आप केवल भिन्न रूप में स्वरूपण का परीक्षण कर सकते हैं। गलत.पंप की पंक्तियों को बदलें ताकि फ़ॉर्मेटर उनके प्रति प्रतिक्रिया करे । उदाहरण के लिए, अन्य परिवर्तनों के साथ अपने कोड में अपर्याप्त इंडेंटेशन जोड़ें। git प्रतिबद्ध -a -m "केवल स्वरूप भिन्न होता है" को स्वरूपित परिवर्तनों में भरना चाहिए, लेकिन फ़ाइल के अन्य भागों को प्रभावित नहीं करना चाहिए।
    

नुकसान और समस्याएं

git diff --staged (जो यहाँ $ {GIT_DIFF} --staged ) है केवल उन फाइलों को अलग करता है जिन्हें इंडेक्स में जोड़ा गया था। और क्लैंग-फॉर्मेट-डिफरेंस-6.0 इसके बाहर फाइलों के पूर्ण संस्करणों तक पहुंचता है। इसलिए, यदि आप कोई फ़ाइल बदलते हैं, तो git ऐड करें , और फिर उसी फ़ाइल को बदलें, फिर क्लैंग-फॉर्मेट-डिफरेंस-6.0 एक अलग फाइल के आधार पर कोड (इंडेक्स में) फॉर्मेट करने के लिए एक पैच उत्पन्न करेगा। इस प्रकार, बेहतर होगा कि फाइल को git ऐड के बाद और कमिट करने से पहले संपादित न करें।

इस तरह की त्रुटि का एक उदाहरण है:

1. अतिरिक्त जोड़ें std :: endl to file.cpp , "दूसरा मामला" । (std :: cout << "दूसरा मामला" << std :: endl << std :: endl;) और लाइन के पहले अतिरिक्त इंडेंटेशन के कुछ टैब।
   
2. git add file.cpp
3. "पहले मामले" के साथ लाइन (उसी फ़ाइल में) को साफ़ करें ताकि केवल लाइन ब्रेक अपने स्थान (!) में बना रहे।
4. git कमिट-मी "कमेटी ऑन फॉर्मेट एरर" ।

स्क्रिप्ट को "त्रुटि: खोज करते समय:" रिपोर्ट करना चाहिए, अर्थात। git apply में clang-format-diff-6.0 द्वारा जारी पैच का संदर्भ नहीं मिला। यदि आपको यह समझ में नहीं आ रहा है कि यहाँ क्या समस्या है, तो उन्हें जोड़ने के बाद और git कमिट करने से पहले फ़ाइलों को न बदलें। यदि आपको बदलने की आवश्यकता है, तो आप (बिना धक्का दिए) प्रतिबद्ध कर सकते हैं और फिर नए बदलावों के साथ प्रतिबद्ध कर सकते हैं।

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

बहुत कम ही, क्लैंग-फॉर्मेट-डिफरेंस-6.0 कोड को अनुचित तरीके से प्रारूपित करता है। इस स्थिति में, आप कुछ बेकार तत्वों को कोड में जोड़ सकते हैं, जैसे अर्धविराम। या, टिप्पणियों के साथ समस्याग्रस्त कोड को घेरें , / * / * और / * क्लैंग-स्वरूप पर क्लैंग-स्वरूप को * / ।

इसके अलावा क्लैंग-फॉर्मेट-डिफरेंस 6.0 एक अपर्याप्त पैच का उत्पादन कर सकता है। इसे लागू करने वाले जीआईटी इसे स्वीकार नहीं करता है, और प्रतिबद्ध भाग का कोड अनियंत्रित रहता है। इसका कारण क्लैंग-फॉर्मेट-डिफरेंट है । सभी प्रोग्राम त्रुटियों को समझने का समय नहीं है। इस स्थिति में, आप कमांड git diff -U0 --no-color HEAD ^ का उपयोग करके स्वरूपण पैच को देख सकते हैं clang-format-diff-6.0 -p1 -v -sort -style = Chromium -iregex। *। \ _ (cxx | cpp | hpp | h) $ ' । सबसे आसान उपाय पिछले कमांड में -i विकल्प जोड़ना है। इस स्थिति में, उपयोगिता एक पैच जारी नहीं करेगी, लेकिन कोड को प्रारूपित करेगी। यदि यह मदद नहीं करता है, तो आप व्यक्तिगत फ़ाइलों के लिए पूरी तरह से क्लैंग-प्रारूप-6.0 -i -sort -style = Chromium file.cpp को प्रारूपित करने का प्रयास कर सकते हैं। अगला है git add file.cpp और git कमिट --amend ।

एक धारणा है कि आपका .clang- प्रारूप कॉन्‍फ़िगरेशन किसी एक प्रीसेट के जितना निकट होगा, उतनी कम त्रुटियां आपको दिखाई देंगी। (यहां इसे -स्टाइल = क्रोमियम विकल्प द्वारा बदल दिया गया है)।

डिबगिंग

यदि आप यह देखना चाहते हैं कि स्क्रिप्ट आपके वर्तमान संपादन (सूचकांक में नहीं) पर क्या बदलाव करेगी, तो git diff -U0 --no-color का उपयोग करें। clang-format-diff-6.0 -p1 -v -sort -style = Chromium -iregex '। *। \ _ (cxx | cpp | hpp | h) $' आप यह भी जांच सकते हैं कि स्क्रिप्ट नवीनतम कमिट पर कैसे काम करेगी, उदाहरण के लिए। तीस पर: git फ़िल्टर-शाखा -f-tree- फ़िल्टर "$ {PWD} /। git / हुक / पूर्व-प्रतिबद्ध" --prune-blank HEAD ~ 30..HEAD । इस कमांड को पिछले कमिट्स को फॉर्मेट करना चाहिए था, लेकिन वास्तव में केवल उनकी आईडी बदल जाती है। इसलिए, यह परियोजना की एक अलग प्रतिलिपि में ऐसे प्रयोगों का संचालन करने के लायक है! बाद वह अनुपयोगी हो जाता है।

निष्कर्ष

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

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