स्रोत पाठ में सही सीमा

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

इस तरह के एक दस्तावेज़ के निर्माण में उठने वाले प्रश्नों में से एक स्रोत पाठ में सही सीमा है। पहले, यह 80 (या 76) वर्णों की सही सीमा का उपयोग करने के लिए प्रथागत था। लेकिन अब मॉनिटर विस्तृत हैं। शायद आप इसे सीमित नहीं कर सकते? या यह वैसे भी सीमित होना चाहिए? यहाँ, उदाहरण के लिए, और हाल ही में, इस लेख में, इस मुद्दे ने काफी विवाद पैदा किया। कट के तहत, इस प्रश्न के मेरे दृष्टिकोण + पोल।

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

मॉनिटर के अलावा, प्रिंटर में यह चौड़ाई थी। बेशक, वहाँ भी व्यापक प्रिंटर थे। लेकिन ए 4 पेपर या उसी (210 मिमी) की चौड़ाई के रोल के लिए डिज़ाइन किए गए सबसे सस्ती प्रिंटर ने बड़े करीने से 80 अक्षरों को कागज पर मुद्रित किया।

इसके अलावा, छिद्रित कार्ड में 80 अक्षर भी होते हैं।

यह है, रेखा की चौड़ाई के 80 वर्ण, वास्तव में, आईबीएम द्वारा, मेरी राय में, पेश किया गया उद्योग मानक था।

हमने कहानी को सुलझा लिया।

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

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

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

लेकिन आधुनिक मॉनिटर इस मानक से दूर क्यों नहीं होते हैं? दरअसल, अपेक्षाकृत उच्च रिज़ॉल्यूशन वाली ग्राफिक स्क्रीन पर संक्रमण के साथ 80 वर्णों का महत्व कम होने लगा। यदि, 640x480 वीजीए एडाप्टर के एक संकल्प पर, स्क्रीन पर समान 80 वर्णों (प्रत्येक वर्ण की 8 पिक्सेल प्रति चौड़ाई) से अधिक फिट करना मुश्किल होगा (हालांकि मैंने चौड़ाई में प्रत्येक वर्ण के लिए 5 और 6 पिक्सेल के साथ अपेक्षाकृत अच्छा पठनीय फोंट देखा)। 1024x768 के रिज़ॉल्यूशन पर भी, वर्ण प्रदान करने की गुणवत्ता में सुधार करना संभव था या प्रति पंक्ति उनकी संख्या बढ़ाना। या बस स्रोत पाठ के बाईं और दाईं ओर कुछ अतिरिक्त फ़ंक्शन जोड़ें - प्रोजेक्ट ट्री, किसी अन्य डेवलपर के साथ चैट करें, और इसी तरह।

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

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

तीसरा विकल्प । आधुनिक 1920 और चौड़ाई में अधिक पिक्सेल के साथ, बड़ी संख्या में वर्ण प्रदर्शित करना कोई समस्या नहीं है। शायद हम सही सीमा को ऐसे ही छोड़ देंगे, लेकिन एक ही समय में, इसे पुराने 80 से बढ़ाकर 160 कर सकते हैं? या कम से कम 120 अक्षर?

वैसे यह विकल्प पिछले वाले से भी बेहतर है। और अभी तक। बेशक, मॉनिटर अब व्यापक हैं। 9:16 या 10x16 के एक पहलू अनुपात के साथ और व्यापक पक्ष पर एक संकल्प होने पर, 1920 या 2560 पिक्सल के पाठ का कहना है, यह बहुत कुछ समायोजित कर सकता है। इसके अलावा, उच्च-गुणवत्ता वाले फ़ॉन्ट रेंडरिंग के साथ।

और सब कुछ ठीक हो जाएगा ... ठीक है, अगर आपको स्रोत पाठ की कई शाखाओं को संयोजित (फ्रीज) करना है? उदाहरण के लिए, तीन-बिंदु मर्ज कैसा दिखेगा?

उदाहरण के लिए, यहां केडीडी 3 के स्क्रीनशॉट हैं । विशेष रूप से यह एक:



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

1920 पिक्सेल की स्क्रीन चौड़ाई के साथ, मुझे स्रोत पाठ के सभी 3 संस्करणों के लिए चौड़ाई में प्रत्येक वर्ण के लिए 8 पिक्सेल के 80 अक्षर मिलते हैं। और वह लाइन नंबर, बॉर्डर और इतने पर डिस्प्ले करने के ओवरहेड की गिनती नहीं कर रहा है।

इसलिए, मैं 76 पात्रों में विदेश में हूं!

खैर, 3-बिंदु मर्ज हर दिन नहीं होता है। सीमा को 100 वर्ण होने दें। लेकिन और नहीं :)