Js-beautify: دعم النمط الأول للفاصلة لإعلان المتغير

بالنظر إلى أننا ندعم كل من JS و Python ، فإن التصحيح (الذي أصبح قديمًا بشدة) غير مكتمل ، في أحسن الأحوال.

نحن منفتحون على سحب الطلبات ، لكنني شخصياً أعتبر "الفاصلة أولاً" نمطًا مضادًا. في جوهرها ، فإن js-beautifier لها رأي حول كيف يجب أن تبدو JS ، مع خيارات معقولة تتوافق إلى حد كبير مع JS "الاصطلاحية" المقبولة على نطاق واسع. الفاصلة أولاً ، في رأيي ، ليست جميلة ، كما أنها ليست مقبولة على نطاق واسع. ما هو أكثر من ذلك ، أنه سيعقد بشدة رمز التجميل (وهو بالفعل معقد بشكل لا يصدق) لتحقيق مكاسب قليلة جدًا.

مع تعيين 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 : في أي مستوى من المسافة البادئة (2 أو 4) ، أعتقد أن هذا هو الشكل الذي يجب أن تبدو عليه:

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

أعتقد أن هذا يتوافق أيضًا مع كيفية قيام بعض محرري SQL (حيث تكون الفاصلة أولاً أكثر انتشارًا).

وعلى الرغم من أنني لا أدعو إلى الترويج للتنسيقات السيئة ، أعتقد أن هناك دائمًا خط رفيع بين أن تكون اصطلاحيًا وعقائديًا (فكر في Crockford هنا). قد لا تكون الفاصلة سائدة أولاً لأن العديد من المنسقين لا يدعمونها ، مهما كان سببهم.

أنت أكثر دراية برمز حالة الشؤون لذا أنا أتفق تمامًا مع حجة عائد الاستثمار الخاصة بك. ومع ذلك ، فكرت في السؤال حتى نتمكن من نشر هذه الأشياء في العلن ، ولدينا نصاب قانوني لمناقشة الأمور وإذا كان هناك طلب من المجتمع ، فربما يمكنك إعادة التفكير في الأمر.

ملاحظة: لقد قضيت بضع ساعات في محاولة لمعرفة ما إذا كان بإمكاني فصل شيء ما بسرعة ولم أكن ناجحًا للغاية. ربما سأجربها في وقت آخر.

mrchief اعتذاري لكوني فظًا بالأمس ، كنت آخذ استراحة من جلسة تصحيح أخطاء محبطة. أنت تشير إلى نقاط جيدة ، وأريد أن أوضح أنني أحترم اختيارك أيضًا. أحاول بنفسي الحفاظ على أسلوب مشروع معين إذا كنت أساهم برقعة (فاصلة أولاً ، بلا فاصلة منقوطة ، وغرابة أخرى) ، وأوافق على أن مثل هذه الخيارات يمكن على الأقل أن تساعد في فرض القليل من الاتساق في المشاريع التي تختار توظيفها.

+1. أستخدم نمط الفاصلة أولاً لمزاياه عند الاختلاف والدمج.

بالنسبة لموضع الفاصلة المنقوطة: أضعها في سطر جديد ، بما يتماشى مع الكلمة الرئيسية var ، مثل هذا:

var a
  , b
  , c
;

لقد رأيت العديد من المشاريع التي تستخدم نفس النمط.

أيضًا ، IMHO ، أعتقد أنه سيكون من الجيد أن تكون قادرًا على الاحتفاظ بكل متغير في سطر منفصل ، على الرغم من عدم إعطاء قيمة بجوار الإعلان. في المثال أعلاه ، ستجمع أداة التجميل كل شيء في سطر واحد var a, b, c; والذي يكسر أيضًا الغرض الكامل من استخدام نمط قبضة الفاصلة.

+1 لدعم الفاصلة أولاً.

في المسافة البادئة 2-space ، إنها أصغر طريقة لترتيب المتغيرات:

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

ماذا عن 4 مسافات لكل علامة تبويب؟ علامات التبويب الفعلية؟

يوم الجمعة ، 8 تشرين الثاني (نوفمبر) 2013 ، الساعة 9:36 صباحًا ، Luke Martin [email protected]
كتب:

+1 لدعم الفاصلة أولاً.
عند المسافة البادئة بمسافتين ، تكون هذه هي أصغر طريقة لترتيب المتغيرات
var foo = صحيح
، شريط = "مرحبًا"

، شيئا ما؛

قم بالرد على هذا البريد الإلكتروني مباشرة أو قم بعرضه على GitHub:
https://github.com/einars/js-beautify/issues/245#issuecomment -28081629

أعتقد أن جوهر مشكلة الفاصلة أولاً يأتي في الواقع إلى تفضيل علامة التبويب.

أنا أستخدم علامتي تبويب بمسافتين ، والفاصلة السابقة هي الطريقة الوحيدة لترتيب المتغيرات دون إضافة مسافات غير ضرورية (~ تمثل مسافات إضافية مضافة لجعل الأشياء مصطفة):

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

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

على العكس من ذلك ، إذا كنت تستخدم علامات تبويب من 4 مسافات ، فستبدو الفاصلة قبلها سيئة ، ولن تهتم بطبيعة الحال بدعمها.

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

لذلك هناك نقاش حول الفاصلة قبل أن يصبح التعليق وتصحيح الأخطاء أسهل. لكن بالنسبة لي ، يتعلق الأمر فقط بالجماليات. أستخدم علامتي تبويب بمسافتين ، لذا أحتاج إلى استخدام فاصلة قبل ذلك. حاليًا لا يمكنني استخدام التجميل لأن لدي تفضيلًا لعلامات تبويب ذات مسافتين.

الآن أعلم أنني ربما أنتمي إلى أقلية ، ولا أطالب مطلقًا بدعم تفضيلي الصغير. كنت أضيف 1+ إلى المحادثة. قد أنظر حتى إلى إضافة الدعم بنفسي إذا كان لدي الوقت.

هتافات :)

أود أن أرى هذا لكائنات json.

 var a = ({
 أ: 1
 ، ب: 2
 }) ؛

lukemartin هذا منظور مثير للاهتمام! : +1:

+1 آخر للدعم الأول للفاصلة ، للإعلان عن المتغير وكذلك المصفوفة والكائنات - https://gist.github.com/isaacs/357981

لقد كنت أعمل على تصحيح لدعم هذه الميزة "عند الطلب" (يمكن للمستخدم تمكين أو تعطيل خيار استخدام الفاصلة أولاً مع الإعداد الذي قمت بإنشائه).

لقد حققت التنسيق التالي لإعلان المتغير (باستخدام مسافتين):

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

لكن لدي بعض الشكوك.

كيف يجب أن نتعامل مع إعلانات المصفوفات والأشياء والوسيطات؟ لقد استخدمت التنسيق التالي مؤخرًا:

myArray = [
  item1
, item2
, item3
];

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

والتي ، كما ترى ، لا تتطابق تمامًا مع تنسيق إعلان المتغير: يتضمن هذا الأخير مستوى مسافة بادئة +1 للمتغير الثاني (لاحظ الفراغين قبل الفاصلة غير الموجودين قبل فاصلة لـ "item2" ولا للواحد من أجل "prop2"). تستخدم تعريفات المتغيرات هذه المسافة البادئة الإضافية من أجل محاذاة بداية كل اسم متغير في نفس العمود كما هو مذكور بواسطةlukemartin.

أسباب استخدام التنسيق الموضح في الكود أعلاه هي:

1.- لتجنب أخطاء الفحص التي قد يتم إلقاؤها بواسطة jshint (أخطاء المسافة البادئة). على سبيل المثال:

myArray = [
    item1
  , item2
];

يرمي "يتوقع] أن يكون له مسافة بادئة عند 3 ، بدلاً من 1". إذا اتبعنا الاقتراح ، نحصل على نتيجة قبيحة للغاية.

2.- للحفاظ على ميزة محاذاة بداية كل اسم خاصية ، عنصر مصفوفة ، إلخ. على سبيل المثال:

myArray = [
  item1
  , item2
];

أيضًا لا ينتج عنه خطأ فحص ، ولكنه لا يبدو جيدًا مثل الأمثلة أعلاه.

من خلال فكرة أكثر وضوحًا حول كيفية التعامل مع هذه الحالات ، يمكنني إنهاء تنفيذ هذه الميزة وإصدار طلب سحب.

هل من الممكن دعم كل ما سبق؟ كل ما أدرجته هو تقنيًا "الفاصلة أولاً".

أعتقد أنه يمكن أن يكون ذلك ممكنًا ، ولكن سيكون من الضروري تنفيذ المزيد من الإعدادات التي من شأنها أن تسمح للمستخدم بتحقيق النتيجة المرجوة. على سبيل المثال ، سيكون من الضروري إخبار المنسق إذا كنت تريد استخدام مستويين من المسافة البادئة للمصفوفات والكائنات والوسيطات أو مستوى واحد فقط.

أعتقد أنه سيكون من الأفضل تحقيق الوظيفة الأساسية أولاً ، ثم توسيعها بمزيد من الإعدادات. أعتقد أنه لن يكون لدي أي مشكلة في تنفيذ تلك الموجودة في التصحيح الثاني.

كما تقول ، الوظائف الأساسية جيدة. إنه _ ليس هدف_ من هذا المشروع لدعم _ جميع خيارات التنسيق. :ابتسامة:

// 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
];

يجب أن تحافظ هذه على بساطة الشفرة ، وأن يكون التنسيق متسقًا بغض النظر عن المسافات البادئة المستخدمة ، وتتيح لنا إغلاق هذه المشكلة ، وفتح مشكلة جديدة لـ "عمود المعرفات ذات الفاصلة أولاً" (أو أيًا كان) التي يمكن تحديدها وتنفيذها بشكل منفصل .

أنا أتطلع إلى رؤية طلب السحب الخاص بك!

tgirardi عمل عظيم. لا استطيع الانتظار لتجربة هذا.

رحب جميع التعليقات :-) !!!

فكرتي هي تعديل الكود حتى يتم اعتباره الحل الصحيح ثم المتابعة مع قائمة TODO التالية:

1.- إنشاء اختبارات لهذه الميزة الجديدة
2.- تطبيق الميزة على إصدار Python (إذا تطوع أي شخص لهذا ، فهو أفضل! ... ليس لدي خبرة كبيرة مع Python).
3.- ناقش الاختلافات المحتملة الأخرى لأنماط الفاصلة أولاً

4 مسافات بادئة

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

لا يلزم ترتيب أسماء المتغيرات وأسماء السمات. هذا لا يؤثر على قابلية القراءة على الإطلاق. في رأيي ، السبب الرئيسي لاستخدام العمود أولاً هو تسهيل التعليق وإزالة وإدخال الأسطر. يحدث فقط أن يصطف عند استخدام مسافة بادئة بمسافتين.

يجب أن يكون العمود شبه في السطر الخاص به بعد إعلان المتغيرات المتعددة لتسهيل إلحاق متغير جديد بعد "y". في هذه الحالة في VIM ، 'o' + '، z = c' بدلاً من '$ a ،"+" ض = ج "

lewisdiamond أنا أتفق مع تعليقك

ولكن لوحظ أيضًا أن:

1.- ليس هدف المشروع دعم جميع أنواع التنسيق.
2.- إضافة الكثير من التعقيد دفعة واحدة فكرة سيئة. لذلك قد يكون من الأفضل إبقاء هذه الميزة بسيطة قدر الإمكان أولاً والبدء في تحسينها بعد وصولها إلى حالة الإصدار واختبارها لبعض الوقت

+1 للحصول على الدعم الأول للفاصلة ، وأنا أتفق مع شعور Lewisdiamond بأن ضمان محاذاة علامات التبويب بشكل صحيح لا ينبغي أن يكون الهدف النهائي نظرًا لوجود أسباب عملية لنمط الفاصلة أولاً. أود دعم Json أيضًا. حاليًا ، لديّ اختراق في رمز js-beautify العالمي للقيام بالكثير من بدائل الترقيم أولاً (بالنسبة للمشغلين الثلاثي كان أمرًا ضروريًا).

لكل من أجرى 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 .

سأقضي 30 دقيقة عليه الليلة وأرد بأفكار. شكرا للمتابعة.

حصلت حولها هذا الصباح. كل شيء يبدو جيدًا بالنسبة لي بسبب اختباراتك. لديّ فرع شخصي به الكثير من وظائف المشغل الأولى - لقد أجريت اختبارات الفاصلة أولاً من خلال فرعك ولم يجتازوا جميعًا أي مشكلة وهذا خبر سار.

عندما أنشأت فرعي الشخصي ، قررت أن عامل الفاصلة أولاً سيكون خاملًا ، وهذا يعني ما يلي:

var a,
    b;

لن يتغير. لقد ذكرت بوضوح أن هذا ليس هو الحال في رسالة الالتزام ، أشعر فقط أنه من المفيد مناقشة السلوك الذي يتوقعونه مع الآخرين إذا اختاروا استخدام opt.comma_first.

شيء آخر ، <Output> .previous_line و flags.previous_text هما نفس الشيء الذي أؤمن به ، والذي كان محيرًا بالنسبة لي في البداية ولكنه كان منطقيًا في كيفية استخدامه.

بخلاف ذلك ، يتمثل الاختلاف الرئيسي بين تطبيقاتنا في أنك اخترت تعديل السطر السابق. كنت أحاول عدم "العودة وتعديل الأشياء" لأنني اعتقدت أن التطوير سيكون أكثر إرباكًا. الآن طريقتك أكثر إيجازًا من طريقي - يسهل قراءتها وعلقت على كل شيء. يقوم الكود الحالي أيضًا بتحرير الرموز المميزة السابقة بحيث تكون التعليمات البرمجية الخاصة بك متوافقة تمامًا - بصراحة أنا فقط أعرضها لأنني أرغب في معرفة ما هي أفكارك. باختصار ، رأيي هو أن هذا البرنامج سيكون من الأسهل بكثير تصحيحه إذا كانت الرموز المميزة مسؤولة فقط عن المساحة البيضاء التي تسبقها بناءً على الرموز المميزة التالية.

شكرا لمعالجة هذا!

تحرير: خطأي - <المخرجات> .previous_line و flags.previous_text مختلفة تمامًا.

إلى الأمام فقط هو الأفضل. لقد نظرت إلى كرة الشعر حول كيف وأين نقرر ما يجب فعله بالفواصل / حولها ، هناك بالفعل أماكن نقوم بتقليص الإخراج مرة أخرى لإعادتها إلى المكان الصحيح. قررت أن أفعل شيئًا مبسطًا بعض الشيء ، وأن أجري بعض الاختبارات للتحقق من السلوك المبسط ثم انظر إلى ضبطه وإعادة بنائه لاحقًا.

المثال الذي ذكرته:

var a,
    b;

سيكون مثالاً على الضبط الذي يمكن مناقشته لاحقًا.

يبدو جيدا. أنا أقدر ردود الفعل.

وشكرا جزيلا لك على البحث عنها. إذا كان لديك أي اختبارات تريد إضافتها ، فسيكون ذلك مفيدًا للغاية.