रिच कोड अधिक सामान्य स्वरूपण क्यों नहीं है?


29

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

Procedure ResolveCollisions
{ Performs a posteriori collision resolution through spatial partitioning algoritm }
(
  CurrentMap : SpriteContext,
  PotentialColliders: SpriteList
)
var Collider  : Sprite, 
    Collidee  : Sprite, 
    Collision : SpriteCollision
begin
  DoStuff();
end.

यह कुछ इस तरह दिख सकता है:

प्रक्रिया ResolveCollisions

स्थानिक विभाजन एल्गोरिथ्म के माध्यम से पोस्टीरियर टकराव संकल्प करता है

पैरामीटर

  • CurrentMap : SpriteContext
  • PotentialColliders : SpriteList

स्थानीय चर

  • Collider : Sprite
  • Collidee : Sprite
  • Collision : SpriteCollision
    DoStuff();

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

क्या आप में से किसी ने पहले कभी इस तरह समृद्ध प्रारूपित कोड देखा है, या पता है कि क्या विचार पर कभी विचार किया गया था और अंततः खारिज कर दिया गया था?


8
क्या आपने नथ का cweb देखा है? www-cs-staff.stanford.edu/~uno/cweb.html
greyfade



12
तो अब आप वर्ड को अपने आईडीई संपादक के रूप में चाहते हैं?

5
जब आप अजीब फॉर्मेटिंग करते हैं तो आपने वर्ड से कभी लड़ाई नहीं की है जिससे छुटकारा पाना असंभव है। आप उदाहरण देते हैं कि संपादक वास्तविक स्रोत कोड के कुछ हिस्सों को छुपाता है। एक दर्शक के रूप में, यकीन है कि यह अच्छा होगा मुझे लगता है, एक संपादक के रूप में, कृपया .. मेरी गरीब आत्मा पर दया करो!
न्यूटोपियन

जवाबों:


38

ऐसा कोई तकनीकी कारण नहीं है जो आप नहीं कर सकते। यदि टेक्स्ट एडिटर सिंटैक्स हाइलाइटिंग कर सकते हैं, तो वे कोड को हाइलाइट करने के लिए डिस्प्ले के अन्य पहलुओं को आसानी से बदल सकते हैं।

हालाँकि, यह एक बात है कि जो कुछ भी टाइप किया जा रहा है, वह रंग बदल रहा है क्योंकि संपादक ने बताया कि आप क्या टाइप कर रहे हैं। पाठ को अचानक आकार बदलने और टाइप करते समय कूदने से आप वास्तव में अप्रिय हो जाएंगे।

हालाँकि, 'स्थिर' कोड प्रदर्शन के लिए, आप आसानी से स्रोत कोड को सुशोभित कर सकते हैं। उदाहरण के लिए किसी भी आधे रास्ते के सभ्य स्रोत-> html कन्वर्टर को लें, और जो भी फॉन्ट साइज़ और स्टाइल आपको पसंद हैं उन्हें स्टाइलशीट में शामिल करें, और आपके पास रिच फॉर्मेटेड कोड होगा।


14

सरल कारण: संपादक / उपकरण स्वतंत्रता।

एक बार जब आप कोड को "अमीर" बना लेते हैं - यह आपके द्वारा उपयोग किए जाने वाले संपादक से जुड़ा होगा - या उन लोगों के लिए जो समृद्ध कोड को समझ सकते हैं। अन्य सभी संपादक जो समृद्धि को संभाल नहीं सकते हैं, वे अस्पष्ट दिखाएंगे।

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

और संस्करण नियंत्रण के बारे में क्या? आप यह कैसे कहेंगे कि स्वरूपण में सभी परिवर्तनों को अनदेखा करें और फ़ाइलों को केवल तभी संशोधित करें जब कुछ "वास्तविक" परिवर्तन हो।

अंत में मुझे लगता है, समृद्ध कोड का पूरा बिंदु पठनीयता है - और उसके लिए, मुझे लगता है कि बेहतर (और अधिक) टिप्पणियां, तार्किक पहचानकर्ता नाम, और निरंतर इंडेंटेशन पर्याप्त होगा।

संक्षेप में, प्रोग्रामिंग पाठ को एक सादे पाठ के रूप में सबसे अच्छा नियंत्रित किया जाता है - आप जो देख रहे हैं वह वास्तविकता है। ( जो निहितार्थ से बेहतर स्पष्ट पाइथोनिक विचार के अनुरूप है )


28
यह जरूरी नहीं कि सच हो। यदि संपादक सिंटैक्स हाइलाइटिंग कर सकते हैं, तो यह सुनिश्चित करें कि सिंटैक्स "बोल्डिंग" या सिंटैक्स "फॉन्ट-साइजिंग", आदि कर सकते हैं
whatsisname

4
इसे करने के लिए Emacs को कॉन्फ़िगर किया जा सकता है, लेकिन फ़ॉन्ट आकार बदलने वाला IMO स्क्रीन स्पेस की बर्बादी होगी।
केविन क्लाइन

4
यदि लेखक को प्रारूपण स्वयं करना है, तो यह समय की बर्बादी होगी। स्पष्ट रूप से, पाठ संपादक स्वचालित रूप से ऐसा करेगा, या हो सकता है कि आप किसी प्रकार की स्टाइलशीट का उपयोग कर सकें।
पीटर ओल्सन

7
@greegit: संपादकों ने स्रोत फ़ाइलों में रंग जानकारी नहीं छोड़ी है जब उनके साथ किया जाता है, तो उन्हें अन्य प्रारूपण चिह्न छोड़ने की ज़रूरत नहीं है, वे उन्हें मांग पर पुन: प्राप्त कर सकते हैं। सिंटैक्स हाइलाइटिंग और सिंटैक्स स्वरूपण के बीच कोई मूलभूत अंतर नहीं है। यदि उपकरण स्पिफि क्लास डायग्राम और यूएमएल आरेख को स्रोत कोड से स्वचालित रूप से बना सकते हैं, तो एक उपकरण निश्चित रूप से समय-समय पर बोल्ड सामान दे सकता है।
whatsisname

9
यह उत्तर सुनिश्चित है कि गलत होने के लिए बहुत सारे upvotes हैं।
जॉर्डन

11

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


11

इसका अस्तित्व क्यों नहीं है? इसके लिए मांग / आवश्यकता नहीं है।

वर्तमान संपादक प्रोग्रामर की जरूरतों को वाक्य रचना हाइलाइटिंग और कुछ अन्य लघु शैलीगत विकल्पों के साथ संतुष्ट करने में सक्षम हैं। क्या वह "समृद्ध पाठ" पहले से नहीं है?


7
+1 बिना किसी मांग के। मुझे उस तरह के कोड से नफरत होगी। लगता है कि मैं वर्ड में टीपीएस रिपोर्ट टाइप कर रहा हूं, कोड नहीं लिख रहा हूं।

1
@ ग्लेन नेल्सन: मैं सहमत हूं। मैं सामान्य दस्तावेजों को टाइप करने के लिए भी वर्ड से बचता हूं अगर मैं कर सकता हूं (मैं इसके बजाय लाटेक्स का उपयोग करता हूं)। मुझे सिंटैक्स हाइलाइटिंग पसंद है लेकिन रिच कोड फॉर्मेटिंग वास्तव में मेरे लिए दखलंदाज़ी होगी।
जियोर्जियो

5

यह पहले से ही Emacs के लिए AucTeX मोड में LaTeX के लिए मौजूद है। अनुभाग के शीर्षक आकार में बड़े होते हैं, उप और सुपरस्क्रिप्ट को उचित रूप से आकार दिया जाता है और आपके पास गणित (और संभवतः एल्गोरिथम जैसे अन्य वातावरण) के बहुत कम पूर्वावलोकन हो सकते हैं।

यह LaTeX के लिए ठीक है क्योंकि कोड से आउटपुट तक की मैपिंग आमतौर पर अन्य कार्यक्रमों की तुलना में बहुत अधिक सीधी होती है; मुझे लगता है कि मैं और अधिक सामान्य प्रयोजन वाली भाषाओं के लिए ऐसा बिल्कुल नहीं चाहूंगा।

एक और बात Emacs कर सकते हैं जैसे प्रतीकों की जगह है ->और forallसाथ और क्रमशः हास्केल में। इस कारण से इस तरह की चीज़ों को कम करने का कोई कारण नहीं हो सकता है, जैसे कि आप यह सुझाव दे रहे हैं कि सिवाय इसके कि आप हास्केल में यह आवश्यक नहीं है।


2

कुछ समय पहले, मैंने कोड स्वरूपण पर यह प्रश्न पूछा था, क्या प्रोग्रामर चाहते हैं कि उनका कोड टाइप होने के साथ ही उनका कोड स्वरूपित हो जाए।

मेरे प्रश्न ने केवल स्वरूपण के इंडेंटेशन पहलू को संबोधित किया, लेकिन कुछ उत्तर सामान्य रूप से कोड स्वरूपण पर लागू हो सकते हैं। जवाबों में समग्र भावना यह बताती है कि प्रोग्रामर अपने कोड का प्रतिनिधित्व करने के तरीके पर पूर्ण नियंत्रण खोने का विरोध करते हैं।

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

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

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


2

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

ज्यादातर इसकी परंपरा है। मैं लगभग 20 वर्षों से पेशेवर रूप से प्रोग्रामिंग कर रहा हूं और मुझे संदेह है कि यह मुझे पागल कर देगा। मैं डॉकबुक के साथ Emacs या VI में किताबें लिखता हूं, इसलिए मैं WYSIWIG प्रशंसक नहीं हूं


2

नुथ का CWEB ऐसा करता है, लेकिन यह केवल C / C ++ और पास्कल के लिए काम करता है। - आप इसे देख लेना चाहिए, हालांकि ... यह काफी साफ है। दो कार्यक्रम हैं: ctangleऔर cweaveजो क्रमशः TeX और C में CWEB फ़ाइलों को मिलाते हैं / अलग करते हैं।


1
nowebलगभग किसी भी संभव भाषा के साथ काम करता है। और कई विशिष्ट साक्षर प्रोग्रामिंग सिस्टम कई अन्य भाषाओं के लिए भी उपलब्ध हैं (lhs और alike)। कुछ भाषाओं में 1960 के दशक की शुरुआत से एक टाइपसेटिंग क्षमता थी - en.wikipedia.org/wiki/Stropping_(programming)
SK-Logic

3
@ एसके-तर्क - अर्घ, कृपया मुझे डरावनी याद दिलाएं जो कि साक्षर प्रोग्रामिंग है । हर त्वरित कोड समीक्षा को एक थकाऊ और लंबी दस्तावेज़ समीक्षा में बदलना, वाक्यांश के हर अंतिम मोड़ और गलत अल्पविराम की आलोचना करना। क्यों रक्षा उद्योग के कुछ हिस्सों ने सोचा कि यह एक अच्छा विचार था जो मुझे कभी पता नहीं चलेगा। मुझे नहीं लगता कि WYSIWYG के संपादकों ने इसे बेहतर बनाया होगा।
मार्क बूथ

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

2

क्या आप में से किसी ने पहले कभी इस तरह समृद्ध प्रारूपित कोड देखा है, या पता है कि क्या विचार पर कभी विचार किया गया था और अंततः खारिज कर दिया गया था?

ज़रूर। Xcode विभिन्न सिंटैक्स के लिए सरल रंग से परे शैलियों का समर्थन करता है:

स्टाइल पाठ के साथ स्रोत कोड

मुझे इसका इस्तेमाल करते हुए एक लंबा समय हो गया है, लेकिन मुझे लगता है कि Metrowerks CodeWarrior ने स्टाइल किए गए टेक्स्ट का भी समर्थन किया, और वह 10+ साल पहले था।

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

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


1

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

WYSIWYG संपादकों (जैसे MS Word) और TeX (LaTeX) जैसी प्रणालियों के बीच पसंद करने वालों के बीच टाइपसेटिंग की दुनिया में एक ही विषय के बारे में लौ युद्ध कभी खत्म नहीं होते हैं।

सामान्य तौर पर, कोई निश्चित उत्तर नहीं है। यह सब उपकरण, मामलों और व्यक्तिगत प्राथमिकताओं पर निर्भर करता है।


1

Doxygen या JavaDoc जैसे उपकरण पहले से ही समृद्ध पाठ कोड फ़ॉर्मेटिंग करते हैं। वे ब्राउज़िंग उद्देश्य के लिए कोड हाइपरटेक्स्ट भी जोड़ते हैं। आपको मूल स्वरूपण के लिए विशेष टैग सम्मिलित करने की आवश्यकता नहीं है।

हालांकि यह WYSIWYG नहीं है।


0

मुझे यह कहने से डर लगता है कि यह मौजूद है।

अतीत में मैंने कुछ सेंटूरा (जिसे गुप्ता या एसक्यूएल / विंडोज के रूप में भी जाना जाता है - एक पुराना " 4 जीएल ") कोड पर काम किया है। एक मानक संपादक में सेंटुरा कोड को संपादित करना वास्तव में संभव नहीं था जैसे नोटपैड को आवश्यक स्वरूपण के चरम स्तर तक करना।

हालाँकि ऐसा लग सकता है कि एक सोर्स फाइल को इस तरह से फॉर्मेट करना एक अच्छा विचार होगा, मैंने पाया कि यह काफी प्रतिबंधात्मक और दर्दनाक है।

इसके अतिरिक्त, स्रोत नियंत्रण में विलय करते समय प्रारूपण में अक्सर समस्याएं होती हैं।


0

अन्य उत्तरों के अलावा, मैं यह बताना चाहूंगा कि समृद्ध स्वरूपण का उपयोग करने की तकनीकी कठिनाइयों के अलावा, यह व्यक्तिगत प्राथमिकता का भी उद्देश्य है।

यदि आप सादे पाठ को संपादित करते हैं, तो आप अपने पसंद के फोंट और रंग चुन सकते हैं और वे अपने आप सेट हो जाते हैं। यदि आप समृद्ध पाठ संपादित करते हैं, तो क्या होगा यदि आप विशेष रंग और फोंट पसंद नहीं करते हैं जो मैन्युअल रूप से सेट किए गए हैं?


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

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

0

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

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