यह कोड में टैब का उपयोग करने के लिए टाई करने का समय है

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

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

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

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

1) सोर्स कोड वाली फाइलों की मात्रा कम होती है।

2) सभी स्थानों को बदलने के परिणामस्वरूप संशोधन इतिहास का नुकसान हो सकता है। पुराने और नए की तुलना करना संभव नहीं होगा।

3) टैब की लंबाई को बदलकर, मैं प्रोग्राम में इंडेंटेशन को अपनी प्राथमिकता में आसानी से समायोजित कर सकता हूं।

आइए हम शुद्ध कारण की आलोचना करें।

1) सोर्स कोड वाली फाइलों की मात्रा कम होती है

जहां तक ​​यह सच है, तो बेवकूफ तर्क है। आजकल, किलोबाइट पर बचत बस व्यर्थ है। इस तर्क ने 10 साल पहले सभी अर्थ खो दिए हैं।

2) सभी स्थानों को बदलने के परिणामस्वरूप संशोधन इतिहास का नुकसान हो सकता है। पुराने और नए की तुलना करना संभव नहीं होगा।

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

यदि आपको अक्सर और गहराई से फाइलों की तुलना करने की आवश्यकता होती है, तो यह रूढ़िवादी में कुछ है । और यहाँ यह अब रिक्त स्थान / टैब तक नहीं है। और अगर एक सामान्य प्रोजेक्ट में एक सामान्य प्रोग्रामर को अभी भी साल में एक बार 10 वीं घुटने तक की एक फाइल के इतिहास का अध्ययन करना है, तो WinMerge उसकी मदद करेगा। वह जानता है कि अंतर को गिनने के लिए जगह के साथ टैब को कैसे बदलना है। मुझे लगता है कि अन्य तुलना प्रणाली बदतर नहीं हैं।

सामान्य तौर पर, एक तर्क भी नहीं। और अगर कोई तर्क है, तो वह बहुत कमजोर है।

3) टैब की लंबाई को बदलकर, मैं प्रोग्राम में इंडेंटेशन को अपनी प्राथमिकता में आसानी से समायोजित कर सकता हूं।

व्यवहार में कभी काम नहीं करता।

जो कोई भी इस तरह का दावा करता है वह यह नहीं समझ पाता है कि वह किस बारे में बात कर रहा है। और उसने खुद कभी ऐसा काम करने की कोशिश नहीं की, अन्यथा वह बकवास नहीं कहती।

मैं एक छोटा सा विषयांतर करूंगा। वास्तव में, कथन में अर्थ का एक दाना है। यह सिर्फ संदर्भ से बाहर है, यह बेवकूफी है। यह तभी काम कर सकता है जब कोड केवल टैब के साथ संरेखित हो। संरेखण के लिए रिक्त स्थान सभी पर उपयोग नहीं किए जाते हैं। इस स्थिति में, हां, टैब का आकार, हम डिस्प्ले कोड बदल सकते हैं। उदाहरण के लिए, कोई ऐसे कोड को देखना पसंद करता है (एक टैब = 2 स्थान):

  अगर (ए == बी)
     x = y; 

दूसरा एक अलग आकार का उपयोग करता है और अपनी पसंदीदा शैली में एक ही कोड की प्रशंसा करता है (एक टैब = 4 स्थान):

  अगर (ए == बी)
         x = y; 

यह कोई नहीं करता है। अपने कोड का पालन करें और आप कुछ अधिक यथार्थवादी (एक टैब = 2 स्थान) देखेंगे:

  A = Aaaaaaaaaaaa &&
     Bbbbbbbbb; 

यदि अब टैब दो रिक्त स्थान के बराबर नहीं हो जाता है, तो डिजाइन की सभी सुंदरता को तुरंत उल्लंघन किया जाएगा।

  A = Aaaaaaaaaaaa &&
         Bbbbbbbbb; 

या यहाँ, मैंने इसे लिया और किसी की फ़ाइल को देखा। किसी ने कोशिश की, गठबंधन किया:

  wcex.cbSize = sizeof (WNDCLASSEX);
 wcex.style = WS_OVERLAPPED;
 wcex.lpfnWndProc = (WNDPROC) ClipBoardWndProc;
 wcex.cbClsExtra = 0;
 wcex.cbWndExtra = 0;
 wcex.hInstance = theApp.m_hInstance;
 wcex.hIcon = 0;
 wcex.hCursor = :: LoadCursor (NULL, IDC_ARROW);
 wcex.hbrBackground = (HBRUSH) (COLOR_WINDOW + 1); 

यह सिर्फ एक अलग टैब आकार के साथ एक एफएआर में है, यह इस तरह दिखता है:

  wcex.cbSize = sizeof (WNDCLASSEX);
 wcex.style = WS_OVERLAPPED;
 wcex.lpfnWndProc = (WNDPROC) ClipBoardWndProc;
 wcex.cbClsExtra = 0;
 wcex.cbWndExtra = 0;
 wcex.hInstance = theApp.m_hInstance;
 wcex.hIcon = 0;
 wcex.hCursor = :: LoadCursor (NULL, IDC_ARROW);
 wcex.hbrBackground = (HBRUSH) (COLOR_WINDOW + 1); 

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

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

परिणामस्वरूप, हम प्राप्त करते हैं कि अमूर्त विचारों से सारणीकरण का उपयोग समझ में नहीं आता है। मेरा दावा है कि अपना या किसी और का कोड लेना और टैब का आकार बदलना, 99% मामलों में हमें एक बदसूरत, आंशिक कोड मिलता है। और यदि ऐसा है, तो बचाव में तर्क केवल 1% से मान्य है, या इससे भी कम है। मैंने कभी अन्य टैब के साथ एक कोड को अच्छा नहीं देखा है। और मैं बहुत सारे कोड देखता हूं।

सारणीकरण के पक्ष में तर्क के साथ, मैं कर रहा हूँ। अब मैं उनके उपयोग के नुकसानों की सूची दूंगा।

1) उन परियोजनाओं के साथ काम करना मुश्किल है जो पाठ में टैब वाले पुस्तकालयों का उपयोग करते हैं। मान लीजिए कि एक पुस्तकालय में टैब 3 वर्ण है, अन्य 4 वर्णों में। और आप परियोजना में 2 वर्णों का उपयोग करते हैं। नतीजतन, कोड का कुछ हिस्सा संपादक में स्वरूपण अक्षम के साथ प्रदर्शित किया जाएगा।

ठीक है, एक चर टैब आकार का उपयोग कहां होता है? क्या आकार नहीं चुनते हैं, कहीं न कहीं यह टेढ़ा होगा। यदि हर जगह अंतराल हैं, तो सब कुछ सुंदर दिखेगा। हां, अलग-अलग संकेत होंगे, लेकिन यह प्रारूपित करना कि सुंदर हर जगह रहेगा!

2) बकरी को बगीचे में जाने देना आसान है। कहें कि आपके पास 4 स्थानों के बराबर एक टैब है। किसी ने कुछ को थोड़ा ठीक किया, एक अलग टैब आकार का उपयोग करके या स्पष्ट रूप से रिक्त स्थान डालने के द्वारा। उसके लिए सबकुछ ठीक लग रहा था, लेकिन आपका कोड ऑफ लाइन कहीं छोड़ जाएगा।

3) विभिन्न संपादकों को वांछित टैब आकार में लगातार कॉन्फ़िगर करना आवश्यक है। यहां तक ​​कि अगर आपको सही के बिना कोड को देखने की जरूरत है। अन्यथा, सब कुछ छोड़ देता है। यह विशेष रूप से सुविधाजनक नहीं है जब आपको थर्ड-पार्टी मशीन पर अपने कोड के साथ कुछ करना है। या इसके विपरीत, किसी और के कोड में देखें। यहां सारी घमंड को समझाना मुश्किल है। यह महसूस किया जाना चाहिए। प्रोग्रामर शायद उन लोगों में विभाजित हैं जो इस असुविधा के बारे में जानते हैं और समझते हैं, और जो नहीं करते हैं। लेकिन कृपया, जो लोग नहीं समझते हैं, मेरा विश्वास है - ये असुविधाएं हैं! और अगर आप, सामान्य रूप से, परवाह नहीं करते हैं, तो रिक्त स्थान का उपयोग करें! किसी को थोड़ा समय और प्रयास बचाओ।

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

और अंत में, मैं इसका उत्तर दूंगा: "हमने हमेशा ऐसा ही लिखा है, इसलिए यह उस तरह जारी है।" अक्सर, इसके अलावा, यह प्रोग्रामर द्वारा उपयोग किए जाने वाले कुछ दाढ़ी वाले कोडिंग मानक द्वारा प्रबलित है। भगवान का शुक्र है पेशेवर डेवलपर्स अभी भी खड़े नहीं हैं। और वे पुरानी नींव को तोड़ने से डरते नहीं हैं। इसका एक उदाहरण Google C ++ स्टाइल गाइड है । यहाँ रिक्त स्थान और टैब के बारे में एक उद्धरण है।

रिक्त स्थान बनाम टैब्स

एक समय में केवल रिक्त स्थान और इंडेंट 2 रिक्त स्थान का उपयोग करें।

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

भगवान का शुक्र है! कम से कम किसी के पास एक उचित दृष्टिकोण है!

मैं आपको अपने कोडिंग मानकों में ताजगी की कामना करता हूं!

अद्यतन:

इस नोट के लिए नोट बैंक में हैं

सजावट के लिए रिक्त स्थान का उपयोग करने के लिए, स्पेसबार 4 या अधिक बार दबाना आवश्यक नहीं है। सभी संपादकों में एक टैब पर क्लिक करते समय कितने स्थान सम्मिलित करने की क्षमता होती है।

मैंने कभी नहीं सोचा होगा कि इस वजह से, वे हाँ करेंगे। “यह कमीने है! एक सुंदर टैब के बजाय नीले रंग तक प्रेस करने के लिए अनुशंसित स्थान! "