Js-beautify: समर्थन अल्पविराम परिवर्तनीय घोषणा की पहली शैली

यह देखते हुए कि हम जेएस और पायथन दोनों का समर्थन करते हैं, पैच (जो गंभीर रूप से पुराना है) अधूरा है, सबसे अच्छा।

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

indent=4 सेट के साथ, कौन सा इंडेंटेशन उपयुक्त है? एक संगति के दृष्टिकोण से, मैं यह तर्क दूंगा:

var a = 1
    , b = "foo"
    , c = false;

जो स्पष्ट रूप से अपेक्षित आउटपुट नहीं है। और यह टैब इंडेंट के साथ कैसा दिखेगा?

सेमी-कोलन कहाँ रहता है? अंत में? कहीं भी नहीं? (मैंने दोनों, और बहुत कुछ देखा है)

यह सार बिल्कुल पुराना है, लेकिन वांछित परिवर्तन की आसान समझ के लिए बनाता है: https://gist.github.com/nemtsov/2864266/revisions

यह #80 के समान है, इसलिए मैंने सोचा कि इसके कारण समान हो सकते हैं - आसान अंतर और पुन: व्यवस्थित करना।

लेकिन इस परिदृश्य में, #80 के विपरीत, एक व्यवहार्य समाधान है जो उन आवश्यकताओं को पूरा करता है:

var a = 1;
var b = "foo";
var c = false;

यह थोड़ा अधिक क्रियात्मक है, लेकिन भयावह नहीं है।

बेशक, अगर कोई #80 लागू करता है, तो सबसे आसान बदलाव शायद इस परिदृश्य को भी कवर करेगा।
जैसा कि @evocateur ने कहा, पुल अनुरोधों का स्वागत है।

@evocateur : आप अपनी राय के हकदार हैं और मैं इसका सम्मान करता हूं। व्यक्तिगत रूप से मैंने हमेशा कॉमा फर्स्ट स्टाइल को नापसंद किया है, लेकिन पूरे वर्षों में, मैं आसानी से हिलने, बाहर निकालने (टिप्पणी करने, हटाने आदि) की सराहना करता आया हूं और जैसा कि @bitwiseman कहते हैं -

@bitwiseman : इंडेंट के किसी भी स्तर (2 या 4) पर, मुझे लगता है कि यह इस तरह दिखना चाहिए:

var a = 1
  , b = "foo"
  , c = false;

मुझे लगता है कि यह भी संगत है कि कुछ SQL संपादक (जहां अल्पविराम पहले अधिक प्रचलित है) इसे कैसे करते हैं।

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

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

पीएस मैंने यह देखने की कोशिश में कुछ घंटे बिताए कि क्या मैं जल्दी से कुछ स्पिन कर सकता हूं और बहुत सफल नहीं था। शायद मैं इसे किसी और समय एक शॉट दूंगा।

@mrchief कल

+1। भिन्न और विलय करते समय मैं इसके फायदे के लिए अल्पविराम-प्रथम पैटर्न का उपयोग करता हूं।

अर्ध-बृहदान्त्र की स्थिति के लिए: मैंने इसे var कीवर्ड के अनुरूप एक नई पंक्ति में रखा है, जैसे:

var a
  , b
  , c
;

मैंने कई परियोजनाएं देखी हैं जो समान पैटर्न का उपयोग करती हैं।

साथ ही, आईएमएचओ, मुझे लगता है कि प्रत्येक चर को एक अलग पंक्ति में रखने में सक्षम होना अच्छा होगा, भले ही घोषणा के आगे कोई मूल्य न दिया गया हो। ऊपर के उदाहरण में, ब्यूटिफायर सब कुछ एक पंक्ति में समूहित करेगा var a, b, c; जो अल्पविराम शैली का उपयोग करने के पूरे उद्देश्य को भी तोड़ देता है।

अल्पविराम-प्रथम समर्थन के लिए +1।

2-स्पेस इंडेंटेशन पर, यह वेरिएबल को व्यवस्थित करने का सबसे आसान तरीका है:

var foo = true
  , bar = 'hello'
  , something;

प्रति टैब 4 रिक्त स्थान के बारे में क्या? वास्तविक टैब?

शुक्र, 8 नवंबर, 2013 को सुबह 9:36 बजे, ल्यूक मार्टिन सूचनाएं @github.com
लिखा था:

अल्पविराम-प्रथम समर्थन के लिए +1।
2-स्पेस इंडेंटेशन पर, यह वेरिएबल को व्यवस्थित करने का सबसे आसान तरीका है
वर फू = सच
, बार = 'हैलो'

, कुछ;

इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें:
https://github.com/einars/js-beautify/issues/245#issuecomment -28081629

मुझे लगता है कि कॉमा-फर्स्ट इश्यू की जड़ वास्तव में टैब वरीयता के लिए नीचे आती है।

मैं 2-स्पेस टैब का उपयोग करता हूं, और कॉमा-पहले अनावश्यक व्हाइटस्पेस जोड़ने के बिना चर को व्यवस्थित करने का एकमात्र तरीका है (~ चीजों को लाइन अप करने के लिए जोड़े गए अतिरिक्त रिक्त स्थान का प्रतिनिधित्व करें):

// eww
var foo = true,
  ~~bar = 'hello',
  ~~something;

// yum
var foo = true
  , bar = 'hello'
  , something;

इसके विपरीत, यदि आप 4-स्पेस टैब का उपयोग करते हैं, तो अल्पविराम खराब दिखने वाला है, और आप स्वाभाविक रूप से इसके समर्थन की परवाह नहीं करेंगे।

// also eww
var foo = true
    , bar = 'hello'
    , something;

तो कॉमा के बारे में चर्चा है - टिप्पणी करना और डीबग करना आसान होने से पहले और ब्ला ब्ला ब्ला। लेकिन मेरे लिए, यह सिर्फ सौंदर्यशास्त्र के लिए आता है। मैं 2-स्पेस टैब का उपयोग करता हूं, इसलिए मुझे कॉमा-पहले का उपयोग करने की आवश्यकता है। वर्तमान में मैं सुशोभित का उपयोग नहीं कर सकता क्योंकि मुझे 2-स्पेस टैब के लिए प्राथमिकता है।

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

चीयर्स :)

मैं इसे जेसन ऑब्जेक्ट्स के लिए देखना चाहता हूं।

 वर ए = ({
 ए: 1
 ,बी: 2
 });

@lukemartin यह एक दिलचस्प परिप्रेक्ष्य है! :+1:

अल्पविराम के पहले समर्थन के लिए एक और +1, चर घोषणा के साथ-साथ सरणी और वस्तुओं के लिए - https://gist.github.com/isaacs/357981

मैं "मांग पर" इस ​​सुविधा का समर्थन करने के लिए एक पैच पर काम कर रहा हूं (उपयोगकर्ता मेरे द्वारा बनाई गई सेटिंग के साथ पहले अल्पविराम का उपयोग करने के विकल्प को सक्षम या अक्षम कर सकता है)।

मैंने परिवर्तनीय घोषणा (2 रिक्त स्थान का उपयोग करके) के लिए निम्न स्वरूपण प्राप्त किया है:

var firstVar = 1
  , secondVar = 2
  , thirdVar = 3
;

लेकिन मुझे कुछ संदेह है।

हमें सरणियों, वस्तुओं और तर्कों की घोषणाओं के साथ कैसा व्यवहार करना चाहिए? हाल ही में मैं निम्नलिखित प्रारूप का उपयोग कर रहा हूं:

myArray = [
  item1
, item2
, item3
];

myObject = {
  prop1: 1
, prop2: 2
, prop3: 3
}

जैसा कि आप देख सकते हैं, चर घोषणा स्वरूपण के समान नहीं है: इस अंतिम में दूसरे चर के लिए +1 इंडेंटेशन स्तर शामिल है (अल्पविराम से पहले दो रिक्त स्थान देखें जो अल्पविराम से पहले मौजूद नहीं हैं "आइटम 2" न ही "prop2" के लिए)। Var घोषणाएं इस अतिरिक्त इंडेंटेशन का उपयोग उसी कॉलम में संरेखित करने के लिए @lukemartin द्वारा बताए गए प्रत्येक चर नाम की शुरुआत में करती हैं।

उपरोक्त कोड पर दिखाए गए स्वरूपण का उपयोग करने के कारण हैं:

1.- लाइनिंग एरर से बचने के लिए जो jshint (इंडेंटेशन एरर)

myArray = [
    item1
  , item2
];

"अपेक्षित] को 1 के बजाय 3 पर इंडेंटेशन करने के लिए फेंकता है"। अगर हम सुझाव का पालन करते हैं, तो हमें बहुत बदसूरत परिणाम मिलता है।

2.- प्रत्येक संपत्ति के नाम, सरणी आइटम, आदि की शुरुआत को संरेखित करने के लाभ को बनाए रखने के लिए। उदाहरण के लिए:

myArray = [
  item1
  , item2
];

एक लाइनिंग त्रुटि भी उत्पन्न नहीं करता है, लेकिन उपरोक्त उदाहरणों के रूप में उतना अच्छा नहीं दिखता है।

मुझे उन मामलों के साथ कैसे व्यवहार करना चाहिए, इस बारे में अधिक स्पष्ट विचार के साथ मैं इस सुविधा के कार्यान्वयन को समाप्त कर सकता हूं और एक पुल अनुरोध जारी कर सकता हूं।

क्या उपरोक्त सभी का समर्थन करना संभव है? आपके द्वारा सूचीबद्ध सब कुछ तकनीकी रूप से "अल्पविराम पहले" है।

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

मुझे लगता है कि पहले बुनियादी कार्यक्षमता हासिल करना बेहतर होगा, और फिर इसे और सेटिंग्स के साथ विस्तारित करना बेहतर होगा। मेरा मानना ​​​​है कि मुझे दूसरे पैच में उन्हें लागू करने में कोई समस्या नहीं होगी।

जैसा कि आप कहते हैं, बुनियादी कार्यक्षमता ठीक है। यह _all_ स्वरूपण विकल्पों का समर्थन करने के लिए इस परियोजना का एक _गैर-लक्ष्य_ है। :मुस्कुराओ:

// 2-space indents
var itemA = 1
  , itemB: 2
  , itemC: 3;

myObj = {
  itemA: 1
  , itemB: 2
}

myArray = [
  item1
  , item2
];

// 4-space indents
var itemA = 1
    , itemB: 2
    , itemC: 3;

myObj = {
    itemA: 1
    , itemB: 2
}

myArray = [
    item1
    , item2
];

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

मैं आपके पुल अनुरोध को देखने के लिए उत्सुक हूं!

@tgiardi बहुत अच्छा काम। इसे आजमाने के लिए और इंतजार नहीं कर सकता।

सभी फीडबैक का स्वागत :-) !!!

मेरा विचार है कि कोड को तब तक समायोजित किया जाए जब तक कि इसे सही समाधान नहीं माना जाता है और फिर निम्नलिखित TODO सूची के साथ आगे बढ़ें:

1.- इस नई सुविधा के लिए परीक्षण बनाएं
2.- पायथन वर्जन पर फीचर लागू करें (यदि कोई इसके लिए स्वेच्छा से, और भी बेहतर! ... मुझे अजगर के साथ ज्यादा अनुभव नहीं है)।
3.- अल्पविराम-प्रथम शैलियों के अन्य संभावित रूपों पर चर्चा करें

4-स्पेस इंडेंट

var x = a
    , y = b
;
obj = {
    attr1: "value1"
    , attr2: "value2"
    , attr3: "value3"
};

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

कई चरों की घोषणा के बाद सेमी-कॉलम अपनी लाइन पर होना चाहिए ताकि 'y' के बाद एक नया वेरिएबल जोड़ना आसान हो सके। इस मामले में VIM में, '$a' के बजाय 'o' + ', z = c',' + 'जेड = सी'

@lewisdiamond मैं आपकी अर्ध-कोलन टिप्पणी से सहमत हूं। इसे अपनी लाइन में रखने से यह सुनिश्चित होता है कि अंतिम चर को भी आसानी से संपादित किया जा सकता है (हटाएं, बदलें, लाइन के बाद/पहले डालें, आदि)।

लेकिन यह भी नोट किया गया है कि:

1.- यह सभी प्रकार के स्वरूपण का समर्थन करने के लिए परियोजना का लक्ष्य नहीं है।
२.- एक बार में बहुत अधिक जटिलता जोड़ना एक बुरा विचार है। इसलिए यह बेहतर हो सकता है कि पहले इस सुविधा को यथासंभव सरल रखा जाए और रिलीज की स्थिति में पहुंचने और कुछ समय के लिए परीक्षण किए जाने के बाद इसे सुधारना शुरू कर दिया जाए।

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

इसे +1 करने वाले सभी लोगों के लिए: कृपया शाखा https://github.com/beautify-web/js-beautify/tree/feature/comma-first पर एक नज़र डालें।

मुझे बताएं कि क्या आप जो चाहते हैं उसके लिए यह पर्याप्त पहला कदम है कि मैं इसे अगली रिलीज में जोड़ दूं।

@olsonpm , @lewisdiamond , @lukemartin , @mrchief - क्या आप लोग शाखा https://github.com/beautify-web/js-beautify/tree/feature/comma-first पर एक नज़र डाल सकते हैं।

मैं आज रात इस पर ३० मिनट बिताऊंगा और विचारों के साथ जवाब दूंगा। फॉलो अप करने के लिए धन्यवाद।

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

जब मैंने अपनी निजी शाखा बनाई, तो मैंने तय किया कि अल्पविराम-प्रथम ऑपरेटर निष्क्रिय होगा, जिसका अर्थ है:

var a,
    b;

नहीं बदला होगा। आपने स्पष्ट रूप से कहा है कि प्रतिबद्ध संदेश में ऐसा नहीं है, मुझे लगता है कि यह दूसरों के साथ चर्चा करने लायक है कि अगर वे opt.comma_first का उपयोग करना चुनते हैं तो वे किस व्यवहार की अपेक्षा करेंगे।

एक और बात, <Output>.previous_line और flags.previous_text एक ही चीज है जो मुझे विश्वास है, जो पहले मुझे भ्रमित कर रही थी लेकिन समझ में आया कि आपने इसका उपयोग कैसे किया।

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

इसे संबोधित करने के लिए धन्यवाद!

संपादित करें: मेरी गलती - <Output>.previous_line और flags.previous_text पूरी तरह से अलग हैं।

फॉरवर्ड-ओनली बेहतर है। मैंने हेयरबॉल को देखा कि कैसे और कहाँ हम तय करते हैं कि कॉमा के साथ क्या करना है/के बारे में, पहले से ही ऐसे स्थान हैं जहां हम आउटपुट को सही जगह पर लाने के लिए वापस ट्रिम कर देते हैं। मैंने कुछ सरल करने का फैसला किया, उसमें कुछ परीक्षण प्राप्त करें जो सरल व्यवहार को सत्यापित करें और फिर ट्यूनिंग के बारे में देखें और बाद में इसे दोबारा दोहराएं।

आप जिस उदाहरण का उल्लेख करते हैं:

var a,
    b;

ट्यूनिंग का एक उदाहरण होगा जिस पर बाद में चर्चा की जा सकती है।

बढ़िया है। मैं प्रतिक्रिया की सराहना करता हूं।

और इसे देखने के लिए आपका बहुत-बहुत धन्यवाद। यदि आपके पास कोई परीक्षण है जिसे आप जोड़ना चाहते हैं तो यह एक बड़ी मदद होगी।