लिस्प कोड प्रारूपण

Question

क्लोजर/एलआईएसपी सिंटैक्स के बारे में my other question पर टिप्पणी करने के लिए समय लेने वाले लोगों में से एक ने इंगित किया कि मैंने मानक नमूना कोड में अपना नमूना कोड नहीं लिखा था। तो वह कोड स्निपेट को फिर से लिखने के लिए काफी दयालु था और यह एक बड़ी मदद है। लेकिन यह मेरे दिमाग में एक और सवाल उठाया। क्यों होता यह:

(if (= a something) 
    (if (= b otherthing) 
    (foo))) 

जो मानक लिस्प स्वरूपण इस फार्म को preferrable होना है:

(if (= a something) 
    (if (= b otherthing) 
    (foo) 
) 
) 

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

Answer 1

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

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

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

Answer 2

जब आपके पास बंद करने के लिए 10 कोष्ठक होते हैं, तो यह वास्तव में घबरा जाता है।

जब मैं लिस्प कार्यक्रम के लिए इस्तेमाल किया मैं एक ही पंक्ति और बाकी पर कोष्ठकों खोलने, उनकी गिनती सरल करने के लिए इस तरह, के लिए बंद कोष्ठकों के बीच एक रिक्ति छोड़ दिया:

 
(if (= a something) 
    (if (= b otherthing) 
    (foo))) 

मैं इन दिनों है कि कोई अनुमान अब आवश्यक है, क्योंकि संपादक अधिक सहायक हैं।

Answer 3

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

(a (b (c (d e) 
     (f g)) 
     (h i j)) 
    (k l m n)) 

भी कोष्ठक को देख के बिना, आप कि (d e) और (f g)c, (c (d e) (f g)) और (h i j) के लिए मानकों b के लिए कर रहे हैं मानकों देख सकते हैं, और (b (c (d e) (f g)) (h i j)) और (k l m n)a के लिए मानकों हैं।

(if (= a something) 
    (if (= b otherthing) 
     (foo))) 

    ^^
    notice how they line up 

अब जब कि मांगपत्र के स्तर सार्थक हो जाता है, तो आप अब कोष्टक संतुलन कि जानकारी पाने के लिए पर भरोसा करने की है, और यह है के बाद से:

अपने उदाहरण के साथ

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

Answer 4

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

बेशक

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

Answer 5

आप पैकेज के साथ लिस्प कोड को दोबारा सुधार सकते हैं Sreafctor: Homepage।

कुछ क़ौम:

• Clojure में Formatting whole buffer demo। मैंने क्लोजर फ़ाइल पर 10k लाइनों के साथ परीक्षण किया और सभी को प्रारूपित करने में लगभग 10 सेकंड लग गए (इंडेंटिंग पर महत्वपूर्ण समय, कोड पुनर्संरचना नहीं)।
• Emacs लिस्प में Formatting whole buffer demo
• Transform between one line <--> Multiline demo

उपलब्ध आदेश:

• srefactor-lisp-format-buffer: प्रारूप पूरे बफर
• srefactor-lisp-format-defun: प्रारूप वर्तमान defun कर्सर
• srefactor-lisp-format-sexp में है: वर्तमान स्वरूप sexp कर्सर में है
• srefactor-lisp-one-line: एक ही स्तर के वर्तमान लिंग को एक पंक्ति में बदल दें; उपसर्ग तर्क के साथ, सभी आंतरिक सेक्सप्स को एक पंक्ति में दोबारा बदल दें।

स्वरूपण आदेश सामान्य लिस्प और योजना पर भी प्रयोग योग्य हैं।

यदि कोई समस्या है, तो कृपया एक समस्या रिपोर्ट सबमिट करें और मुझे इसे ठीक करने में खुशी होगी।