गैर-प्रोग्रामर के लिए कोड टाइप करने के लिए गाइड


13

पृष्ठभूमि

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

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

सवाल

मैं एक संसाधन की तलाश कर रहा हूँ जो:

  • टाइपसेटिंग कोड की मूल बातें बताते हैं,
  • प्रोग्रामिंग अनुभव के बिना टाइपसेटर्स पर लक्षित है।

इसके साथ कठिनाई यह है कि यह भाषा और उपयोग की जाने वाली परंपराओं पर निर्भर करता है, इसलिए यह प्रश्न बहुत व्यापक है, भले ही उत्तर केवल एक संसाधन को जोड़ रहे हों
Zach Saucier

2
@ कोट अच्छी तरह से, उद्धरण, रिक्त स्थान, वर्णों के बारे में - वास्तव में कोई बहुत अच्छी तरह से सामान्यीकरण कर सकता है: उन्हें संरक्षित किया जाना चाहिए।
मिखाइल वी

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

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

1
@ usr2564301: सबसे पहले, यह प्रश्न अब कुछ खोज इंजनों द्वारा पाया जा रहा है और इसलिए यह अधिक संभावना है कि किसी भी टाइपसेट को मेरी जैसी समस्याएँ हैं, वे संभावित उत्तर पा सकते हैं (और यदि वे नहीं करते हैं, तो मुझे ठीक से स्मगल किया जा सकता है। इसके बारे में)। दूसरा, हां, मैं अपने साक्ष्यों की प्रतिक्रिया में एक लिंक शामिल करूंगा, क्योंकि यह साक्ष्यों के दूसरे दौर में अभी तक प्रतिबद्ध त्रुटियों को नहीं रोक सकता है। यदि टाइपसेट जिद्दी है, तो यह एक संदर्भ के लिए चोट नहीं करता है। अंत में, यह एक पत्रिका / प्रकाशक है जिसे शायद ही कभी कोड से निपटना पड़ता है, इसलिए यह आपके द्वारा दर्शाए गए परिदृश्यों से कुछ अलग है।
Wrzlprmft

जवाबों:


7

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

  • टैब 4 या 8 स्थानों जितना चौड़ा होना चाहिए (चार सबसे आम हैं)
  • फ़ॉन्ट एक निश्चित चौड़ाई वाला फ़ॉन्ट होना चाहिए। और लगभग सार्वभौमिक रूप से होना चाहिए।
  • सुनिश्चित करें कि आपका आवेदन कोई प्रतिस्थापन नहीं करता है!

    इसका मतलब है कि कोई लिगमेंट नहीं।

    इसके अलावा कई प्रोग्राम (जैसे वर्ड और इनडिजाइन) एप्लिकेशन सीधे टाइपर्स जोड़े के लिए सीधे उद्धरण बदलते हैं। अपने दस्तावेज़ में कोड डालने से पहले सुनिश्चित करें कि ऐसे विकल्प अक्षम हैं।

  • कोड को स्वचालित रूप से एक पंक्ति से दूसरी पंक्ति में प्रवाहित न होने दें। कोड को स्पर्श न करें, आप विशेषज्ञ नहीं हैं!

कोड बॉडी टेक्स्ट नहीं है, यह किसी भी टाइपोग्राफिक सम्मेलनों का पालन नहीं करता है। अपने आप से पूछें कि क्या आप चित्रण में पाठ टाइप करेंगे?

यदि आप एक विशेषज्ञ हैं

यदि आप एक विशेषज्ञ हैं और आप प्रश्न में भाषा जानते हैं तो निम्नलिखित लागू होता है।

नोट : अनुमान या अनुमान न करें, जो कहा गया था उसे पढ़ें। बहुत सी भाषाएं समान दिखती हैं और कोड कुछ छद्म भाषा हो सकती है जो वास्तविक कोड की तरह दिखती है। तब आप कर सकते हो:

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

    ध्यान दें यदि आप यह गलत करते हैं तो यह अच्छे से अधिक नुकसान पहुंचाता है।

यदि आप एक डोमेन विशेषज्ञ हैं। जैसा कि भाषा और पुस्तकालय को जानते हैं और प्रश्न में कोड को समझते हैं:

  • तब आप कोड को कई लाइनों में पुनः प्राप्त कर सकते हैं यदि यह आपके लेआउट में फिट नहीं होता है। ऐसा न करें जब तक आप वास्तव में नहीं जानते कि आपका क्या करना है, तो आप अपूरणीय नुकसान कर सकते हैं।

    लिटमस टेस्ट से आप प्रश्न में कोड लिख सकते हैं। अगर नहीं तो आप न्याय नहीं कर सकते। लेखक से पूछें।

    इससे कैसे निपटें? प्रोग्रामर कोड स्टाइल मानकों को समझते हैं। बस सबमिशन गाइडलाइन में लिखें कि आप केवल X अक्षर प्रति पंक्ति में फिट कर सकते हैं। प्रोग्रामर इसके बाद खुद ऐसा कर सकते हैं। कोड संपादकों के पास अक्सर इसके लिए उपकरण होते हैं। फिर भी मोनो स्पॉन्टेड फॉन्ट का उपयोग करने का एक और कारण।

लेकिन तब आप यह सब जानते थे, आप एक विशेषज्ञ थे। बेहतर है कि लेखक कोड को संपादित करे।

पंक्ति संख्याएँ?

कुछ प्रोग्रामिंग लैंग्वेज और उपयोग के मामले लाइन नंबरों से लाभान्वित हो सकते हैं। हालांकि यहां सावधान रहें, क्योंकि यह कुछ भाषाओं में एक फॉक्स पेस है।

समस्या।

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

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


@ usr2564301 आह हां इतना सच है
joojaa

1
@ usr2564301 किया, वैसे भी मुझे लगता है कि एक पठनीय फ़ॉन्ट विकल्प एक टाइपोग्राफर को समझना चाहिए। वैसे भी एक कम मामले को मैं बिना डॉट के अलग करता हूं (हाँ, हमने एक महीने के लिए एक टुकड़े के लिए एक कोड डिबग किया क्योंकि हमें नहीं पता था कि एक लोअरकेस 'i' एक अलग रूप है जो एक तुर्की लोकेल में 'आई' है) 1 भी
joojaa

"सिद्धांत को एक पंक्ति से दूसरी पंक्ति में प्रवाहित न होने दें" सिद्धांत में अच्छी सलाह है। लेकिन अगर आप एक मानक 6x9 प्रिंट प्रारूप के लिए टाइप कर रहे हैं और आपको 600 वर्णों के साथ कोड की एक पंक्ति मिल गई है, तो आपको इसे देखने में मुश्किल होगी।
Janus Bahs Jacquet

1
@JanusBahsJacquet कोड आमतौर पर प्रति पंक्ति 80 से कम अक्षरों में लिखा जाता है। तो अगर आपको ऐसा कुछ मिलता है तो हो सकता है कि आपका सबमिशन गाइडलाइंस सोख लें। प्रोग्रामर सभी दिशानिर्देशों के बारे में जानते हैं कि आखिरकार कोडबेस क्या हैं। बात लाइनों को तोड़कर आप कोड के अर्थ को बदल सकते हैं।
पूजा

1
@JanusBahsJacquet यही कारण है कि आप लेखक से पूछते हैं, आप दिशानिर्देशों को अपडेट करते हैं इसलिए आपको ऐसा करने की आवश्यकता नहीं है। अच्छी तरह से या तो मामले में अगर कोड कैंट को लंबी लाइनों के रूप में विभाजित किया जाता है तो टाइपसेट कैंटर इसके बारे में कुछ भी नहीं करता है। वैसे एक टाइपिस्ट बहुत विस्तृत चित्र का क्या करेगा जो आकार या क्रॉप नहीं कर सकता है? वैसे भी मैं भविष्य में कोड सबमिशन अधिक सामान्य होने की भविष्यवाणी करूंगा
17

4

पाठ्यक्रम का उत्तर कई कारकों पर निर्भर हो सकता है, लेकिन अगर हम सही, अच्छे स्वरूपित सादे पाठ कोड के साथ शुरू करते हैं , तो कोई व्यक्ति यहां चीजों को कम या ज्यादा कर सकता है।

स्रोत पाठ में प्रारंभिक 'फ़ॉर्मेटिंग' होगी: न्यूलाइन , स्पेस और टैब वर्ण। ध्यान दें कि नई लाइन और मैनुअल लाइन ब्रेक (डीटीपी सॉफ्टवेयर में) एक ही चीज नहीं है, और इसके विपरीत, कुछ दुर्लभ भाषाएं अन्य स्वरूपण वर्णों की अनुमति दे सकती हैं , हालांकि मैंने ऐसा कभी नहीं सुना है।

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

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

इस प्रकार, पहला सिद्धांत यह होगा: स्रोत पाठ को न बदलें। मैं एक चेकलिस्ट से गुजरूंगा - सुनिश्चित करें कि:

  • कोई भी चरित्र ऑटोरप्लसिंग किसी भी अवस्था में नहीं होता है।
  • पाठ का कोई संपादन नहीं किया जाता है (जब तक कि आप 100% सुनिश्चित नहीं हो जाते कि उन्हें किया जाना चाहिए)।
  • कोई रेखा नहीं दिखाई देती है।
  • इंडेंटेशन नेत्रहीन संरक्षित होते हैं और सुसंगत होते हैं (ca. चार x  चौड़ाई प्रति स्तर इंडेंटेशन)।
  • प्रारंभिक (शून्य) इंडेंट स्तर दिखाई देना चाहिए।
  • परिभाषित शैली सिंटैक्स के स्वरूपण को नष्ट नहीं करती है (यदि सिंटैक्स हाइलाइटिंग का उपयोग किया जाता है)।
  • सादे पाठ में स्रोत का बैकअप रखें, ताकि मूल स्वरूपण को पुन: जाँचने या नए सिरे से शुरू करने में सक्षम हो सकें।
  • पंक्ति संख्या, यदि मौजूद है, तो विशेष रूप से बरकरार होनी चाहिए, यदि उन्हें स्पष्टीकरण में संदर्भित किया गया हो।

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

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

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

मोनोस्पॉन्टेड फ़ॉन्ट + स्थान

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

सामान्य तौर पर, गाढ़ा (जैसे एरियल संकीर्ण) या छोटे फोंट बेहतर काम कर सकते हैं: यह शरीर के पाठ के विपरीत अधिक जोर देता है, यह कोड को अधिक कॉम्पैक्ट बना देगा, और इस तरह कम संभावना है कि अवांछित लाइन रैपिंग दिखाई देगी।

मुझे लगता है कि यहां कोई एक रेखा खींच सकता है, और यदि ऊपर किया गया है, तो 99% संभावना है कि सब कुछ ठीक होना चाहिए, कम से कम रंगों के बिना एक सादे एकल-फ़ॉन्ट कोड ब्लॉक के लिए।


उपकरण और उन्नत स्वरूपण

इसके अलावा, सिंटैक्स हाइलाइटिंग का उपयोग करके लुक को काफी बेहतर बनाया जा सकता है।

  • रंग प्रिंट या स्क्रीन देखना: एक पूर्ण-रंग लेआउट में हाइलाइटिंग की प्रत्येक सुविधा का उपयोग किया जा सकता है, इसलिए यह सबसे अच्छा मामला है, लेकिन मुद्रण कुछ रंग परिवर्तन दे सकता है।

  • ग्रेस्केल या बी / डब्ल्यू प्रिंट: यहाँ निश्चित रूप से बोल्ड (जैसे कीवर्ड) या इटैलिक (उदाहरण टिप्पणियाँ) का उपयोग किया जा सकता है, लेकिन ध्यान दें कि रंग सभी परिणामों के साथ ग्रे में परिवर्तित हो जाएंगे। उदाहरण के लिए धूसर-बाहर की टिप्पणियां एक प्रदर्शन पर बहुत अच्छी लग सकती हैं, लेकिन कागज पर बहुत अधिक पीला हो सकती हैं।

सबसे महत्वपूर्ण प्रश्न यह है कि क्या लेआउट निर्माता के पास ऐसे उपकरण हैं जो पठनीय रूप में कोड का प्रतिनिधित्व कर सकते हैं। सौभाग्य से, कोड संपादन के लिए बहुत सारे मुफ्त टूल हैं, जिनमें से सबसे प्रमुख (विंडोज के लिए) हैं: नोटपैड ++, वीएसकोड, विजुअल स्टूडियो । लेकिन यद्यपि स्थानों पर टैब के संभावित निहित ऑटो-रूपांतरणों से अवगत रहें।

नोटपैड ++ में आरटीएफ के रूप में कोड को निर्यात करने का एक विकल्प है , जो स्रोत के सभी स्वरूपण और वाक्यविन्यास हाइलाइटिंग को संरक्षित करेगा।

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

उदाहरण के लिए, नोटपैड ++ में पायथन कोड के लिए मेरा सेटअप इस तरह दिखता है:
यहाँ छवि विवरण दर्ज करें

यह केवल उदाहरण के लिए है, कि कोई सीधे स्क्रीनशॉट का उपयोग कर सकता है और यह वास्तव में सबसे आसान तरीका हो सकता है। विभिन्न उपकरण हैं जो स्क्रीन कैप्चरिंग में मदद कर सकते हैं - उच्च रिज़ॉल्यूशन छवियों के लिए स्क्रीन को 'सिलाई' करने की आवश्यकता हो सकती है।

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

कस्टम भाषा परिभाषाओं के लिए अतिरिक्त उपकरण / प्लगइन्स भी आम हैं, लेकिन उन्हें वाक्यविन्यास ज्ञान की आवश्यकता होती है।


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

1
@JeremyCarlson Np ++ में फ़ॉन्ट आकार / लाइन रिक्ति को समायोजित किया जा सकता है - इसलिए सिद्धांत रूप में स्क्रीनशॉट रिज़ॉल्यूशन के लिए कोई सीमा नहीं है, लेकिन यह विशेष रूप से एक छोटे डिस्प्ले पर बनाने के लिए कठिन होगा। वर्चुअल डिस्प्ले का उपयोग करने और खिड़की के बहुत बड़े आकार को सेट करने के लिए कुछ तरकीबें भी हो सकती हैं
मिखाइल V

क्योंकि कम और कम नए लोग आज कोडिंग के लिए मोनोसेप्ड का चयन करते हैं - यह हो सकता है, लेकिन अभी भी विशाल बहुमत द्वारा उपयोग किया जाता है। आप बस कोड करने के लिए सामान्य टाइपिंग सम्मेलनों का अनुवाद नहीं कर सकते। उदाहरण के लिए विराम चिह्न सामान्य ग्रंथों की तुलना में अधिक महत्वपूर्ण होते हैं ( मेरे इस अनुवाद के उत्तर से अधिकांश तर्क )। एक गैर-मोनोस्पेस कोड टाइपफेस नियमित पाठ के लिए एक से काफी भिन्न होगा। इसके अलावा, आप अक्सर कुछ समान संरचनाओं को क्षैतिज रूप से संरेखित करना चाहते हैं, जैसे a[i][j] = 1certain a[m][n] = 2
Wrzlprmft

एडिट्स के लिए @rzlprmft धन्यवाद। और हाँ, कोड और गणित के लिए अनुकूलित इतने अच्छे फोंट नहीं हैं (वर्डाना ठीक है)। वास्तव में, टाइम्स में छोटी अवधि और बृहदान्त्र और कुछ अन्य मुद्दे हैं, लेकिन मैं इसे सभी तरह से उपयोग करता हूं - 'लाभ की लागतों को कम कर देना'
मिखाइल V

-5

HTML में, एक टैगसेट होता है <code> ... </ code> जो पाठक / दुभाषिया को सामग्री का अक्षरशः व्यवहार करने के लिए कहता है। भी, <pre> ... </ pre> बहुत कुछ करता है। जैसा कि किसी को अक्सर प्रकाशन के लिए सूत्र, समीकरण और कोड टाइप करना पड़ता था, मैं भी ऐसा करने के लिए IMAGES के उपयोग की वकालत करता हूं ... एक .gif या .jpg या समस्याग्रस्त वस्तु का .png बनाऊं।

एक अन्य कारक यह है कि कोड को पारंपरिक रूप से कूरियर मोनोपेस, या अन्य मोनोस्पोज्ड फॉन्ट में प्रस्तुत किया जाता है, क्योंकि यह पाठक को अर्धविराम या टेलीग्राफ करता है कि यह बॉडी टेक्स्ट नहीं है। मैं इस शैली की पसंद की सदस्यता लेता हूं, मुझे लगता है कि यह बहुत मायने रखता है।

अधिकांश "विरासत" टाइपिंग सिस्टमों में, यथोचित उच्च जटिलता के गणित समीकरण समय-समय पर होने वाले खर्च थे ... और त्रुटि से भरा।


बेशक, छवियों में कटौती नहीं कर रहे हैं 'n पेस्ट-सक्षम!
dwoz

3
मुझे समझ नहीं आ रहा है कि यह सवाल कैसे पूछा जा रहा है
Zach Saucier
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.