Js-beautify: Mendukung gaya koma pertama dari deklarasi variabel

Dibuat pada 23 Apr 2013  ·  27Komentar  ·  Sumber: beautify-web/js-beautify

Izinkan kode diformat seperti ini:

var a = 1
  , b = "somethign else"
  , isAwesome = true;

Dan tampaknya, kami memiliki tambalan yang agak siap tersedia. Akan lebih bagus jika ini bisa dimasukkan di sini!

enhancement

Semua 27 komentar

Mengingat kami mendukung JS dan Python, tambalan (yang sangat ketinggalan zaman) tidak lengkap, paling banter.

Kami terbuka untuk menarik permintaan, tetapi saya pribadi menganggap "koma-pertama" sebagai anti-pola. Pada intinya, js-beautifier berpendapat tentang bagaimana seharusnya JS terlihat, dengan opsi yang masuk akal yang sebagian besar sesuai dengan JS "idiomatik" yang diterima secara luas. Koma-pertama, menurut saya, tidak indah, juga tidak diterima secara luas. Terlebih lagi, ini akan sangat memperumit kode kecantikan (yang sudah sangat rumit) untuk keuntungan yang sangat kecil.

Dengan set indent=4 , lekukan mana yang sesuai? Dari sudut pandang konsistensi, saya berpendapat ini:

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

Yang jelas bukan output yang diharapkan. Dan bagaimana tampilannya dengan indentasi tab?

Di mana titik koma tinggal? Pada akhirnya? Tidak ada tempat? (Saya telah melihat keduanya, dan banyak lagi)

Intisari ini sama kedaluwarsanya, tetapi memudahkan pemahaman tentang perubahan yang diinginkan: https://Gist.github.com/nemtsov/2864266/revisions

Ini mirip dengan #80, jadi saya pikir alasannya mungkin sama - pembedaan dan penataan ulang yang lebih mudah.

Namun dalam skenario ini, tidak seperti #80, ada solusi yang layak yang memenuhi persyaratan tersebut:

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

Ini sedikit lebih bertele-tele, tapi tidak menghebohkan.

Tentu saja, jika seseorang menerapkan #80, perubahan paling sederhana mungkin akan mencakup skenario ini juga.
Seperti yang dikatakan @evocateur ,

@evocateur : Anda berhak atas pendapat Anda dan saya menghormati itu. Secara pribadi saya selalu tidak menyukai gaya koma pertama tetapi selama bertahun-tahun, saya mulai menghargai kemudahan memindahkan, mengeluarkan (mengomentari, menghapus, dll.) Dan seperti yang dikatakan @bitwiseman - diffing. Jadi saya bersedia meninggalkan ini sebagai opsi dan membiarkan pengguna melakukan apa pun yang dia suka. Terkadang, itu tidak ada di tangannya dan dia harus mengikuti standar yang sudah ditetapkan. Ya, jelek tapi kenyataan!

@bitwiseman : Pada tingkat indentasi apa pun (2 atau 4), saya kira seperti inilah tampilannya:

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

Saya pikir ini juga konsisten dengan bagaimana beberapa editor SQL (di mana koma lebih dulu lebih lazim) melakukannya.

Dan sementara saya tidak menganjurkan mempromosikan tata letak yang buruk, saya kira selalu ada garis tipis antara menjadi idiomatik dan dogmatis (pikirkan Crockford di sini). Koma pertama mungkin tidak lazim karena banyak pemformat tidak mendukungnya, apa pun alasannya.

Anda lebih akrab dengan keadaan dari segi kode, jadi saya sangat setuju dengan argumen ROI Anda. Namun demikian, saya berpikir untuk meminta agar kita bisa mengeluarkan hal-hal ini secara terbuka, memiliki kuorum untuk membahas berbagai hal dan jika ada permintaan dari komunitas, mungkin kalian bisa memikirkannya kembali.

PS Saya menghabiskan beberapa jam mencoba untuk melihat apakah saya dapat dengan cepat memutar sesuatu dan tidak terlalu berhasil. Mungkin saya akan mencobanya lain kali.

@mrchief Saya minta maaf karena kasar kemarin, saya sedang istirahat dari sesi debugging yang membuat frustrasi. Anda membuat poin yang bagus, dan saya ingin menjelaskan bahwa saya menghormati pilihan Anda juga. Saya sendiri berusaha mempertahankan gaya proyek yang diberikan jika saya menyumbangkan tambalan (pertama koma, tanpa titik koma, keanehan lainnya), dan saya setuju bahwa opsi seperti ini setidaknya dapat membantu menegakkan sedikit konsistensi dalam proyek yang memilih untuk mempekerjakan mereka.

+1. Saya menggunakan pola koma-pertama untuk keuntungannya saat melakukan diffing dan merging.

Adapun posisi titik koma: Saya meletakkannya di baris baru, sesuai dengan kata kunci var , seperti ini:

var a
  , b
  , c
;

Saya telah melihat beberapa proyek yang menggunakan pola yang sama.

Juga, IMHO, saya pikir akan menyenangkan untuk dapat menyimpan setiap variabel dalam baris yang terpisah, meskipun nilai tidak diberikan di sebelah deklarasi. Pada contoh di atas, beautifier akan mengelompokkan semuanya dalam satu baris var a, b, c; yang juga mematahkan seluruh tujuan penggunaan gaya tinju koma.

+1 untuk dukungan koma-pertama.

Pada lekukan 2-ruang, ini adalah cara paling rapi untuk mengatur variabel:

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

Bagaimana dengan 4 spasi per tab? Tab sebenarnya?

Pada Jumat, 8 November 2013 pukul 09:36, Luke Martin [email protected]
menulis:

+1 untuk dukungan koma-pertama.
Pada lekukan 2 spasi, ini adalah cara paling rapi untuk mengatur variabel
var foo = benar
, bar = 'halo'

, sesuatu;

Balas email ini secara langsung atau lihat di GitHub:
https://github.com/einars/js-beautify/issues/245#issuecomment -28081629

Saya kira inti dari masalah koma-pertama sebenarnya bermuara pada preferensi tab.

Saya menggunakan tab 2 spasi, dan koma-sebelumnya adalah satu-satunya cara untuk mengatur variabel tanpa menambahkan spasi yang tidak perlu (~ mewakili spasi tambahan yang ditambahkan untuk membuat semuanya berbaris):

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

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

Sebaliknya, jika Anda menggunakan tab 4 spasi, koma-sebelumnya akan terlihat buruk, dan Anda tentu tidak akan peduli dengan dukungan untuk itu.

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

Jadi ada diskusi tentang koma-sebelum lebih mudah untuk berkomentar dan debug dan bla bla bla. Tapi bagi saya, itu hanya bermuara pada estetika. Saya menggunakan tab 2 spasi, jadi saya harus menggunakan koma-sebelumnya. Saat ini saya tidak dapat menggunakan beautify karena saya memiliki preferensi untuk tab 2 spasi.

Sekarang saya tahu saya mungkin minoritas, dan saya sama sekali tidak menuntut dukungan untuk preferensi kecil saya. Saya baru saja menambahkan +1 saya ke percakapan. Saya bahkan mungkin mempertimbangkan untuk menambahkan dukungan sendiri jika saya punya waktu.

Bersulang :)

Saya ingin melihat ini untuk objek json.

 var a = ({
 sebuah: 1
 ,b: 2
 });

@lukemartin Itu perspektif yang menarik! :+1:

+1 lainnya untuk dukungan koma pertama, untuk deklarasi variabel serta array dan objek - https://Gist.github.com/isaacs/357981

Saya telah mengerjakan tambalan untuk mendukung fitur ini "sesuai permintaan" (pengguna dapat mengaktifkan atau menonaktifkan opsi menggunakan koma terlebih dahulu dengan pengaturan yang saya buat).

Saya telah mencapai format berikut untuk deklarasi variabel (menggunakan 2 spasi):

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

Tapi aku punya beberapa keraguan.

Bagaimana seharusnya kita memperlakukan deklarasi array, objek, dan argumen? Akhir-akhir ini saya telah menggunakan format berikut:

myArray = [
  item1
, item2
, item3
];

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

Yang, seperti yang Anda lihat, tidak persis sama dengan pemformatan deklarasi variabel: yang terakhir ini menyertakan level indentasi +1 untuk variabel kedua (perhatikan dua spasi sebelum koma yang tidak ada sebelum koma untuk "item2" atau untuk satu untuk "prop2"). Deklarasi var menggunakan lekukan tambahan ini untuk menyelaraskan di kolom yang sama awal setiap nama variabel seperti yang dinyatakan oleh @lukemartin.

Alasan menggunakan format yang ditunjukkan pada kode di atas adalah:

1.- Untuk menghindari kesalahan linting yang akan dilontarkan oleh jshint (kesalahan indentasi). Sebagai contoh:

myArray = [
    item1
  , item2
];

Melempar "Diharapkan ] memiliki lekukan pada 3, bukan pada 1". Jika kita mengikuti saran, kita mendapatkan hasil yang sangat jelek.

2.- Untuk mempertahankan keuntungan dari menyelaraskan awal setiap nama properti, item array, dll. Misalnya:

myArray = [
  item1
  , item2
];

Juga tidak menghasilkan kesalahan linting, tetapi tidak terlihat sebagus contoh di atas.

Dengan gagasan yang lebih jelas tentang bagaimana saya harus menangani kasus-kasus itu, saya dapat menyelesaikan implementasi fitur ini dan mengeluarkan Permintaan Tarik.

Apakah mungkin untuk mendukung semua hal di atas? Semua yang Anda daftarkan secara teknis "koma dulu".

Saya percaya itu mungkin, tetapi perlu menerapkan lebih banyak pengaturan yang memungkinkan pengguna mencapai hasil yang diinginkan. Misalnya, Anda perlu memberi tahu formatter jika Anda ingin menggunakan 2 level indentasi untuk array, objek, dan argumen atau hanya satu.

Saya pikir akan lebih baik untuk mencapai fungsionalitas dasar terlebih dahulu, dan kemudian memperluasnya dengan lebih banyak pengaturan. Saya yakin saya tidak akan kesulitan mengimplementasikannya di tambalan kedua.

Seperti yang Anda katakan, fungsionalitas dasar baik-baik saja. Ini adalah _non-tujuan_ dari proyek ini untuk mendukung _semua_ opsi pemformatan. :senyum:

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

Ini harus menjaga kode Anda tetap sederhana, pemformatan yang konsisten tidak peduli indentasi apa yang digunakan, dan memungkinkan kami menutup masalah ini, dan membuka masalah baru untuk "Columnize comma-first identifiers" (atau apa pun) yang dapat ditentukan dan diimplementasikan secara terpisah .

Saya berharap dapat melihat permintaan tarik Anda!

@tgirardi Kerja bagus. Tidak sabar untuk mencoba ini.

Semua Umpan Balik disambut :-) !!!

Ide saya adalah menyesuaikan kode hingga dianggap sebagai solusi yang benar dan kemudian melanjutkan dengan daftar TODO berikut:

1.- Buat tes untuk fitur baru ini
2.- Terapkan fitur pada versi Python (Jika ada yang menjadi sukarelawan untuk ini, lebih baik lagi! ... Saya tidak punya banyak pengalaman dengan python).
3.- Diskusikan kemungkinan variasi gaya koma-pertama lainnya

4-spasi indent

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

Nama variabel dan nama atribut tidak perlu disejajarkan. Ini tidak mempengaruhi keterbacaan sama sekali. Menurut pendapat saya, alasan utama menggunakan kolom-pertama adalah untuk membuat komentar, menghapus, dan menyisipkan baris lebih mudah. Kebetulan berbaris saat menggunakan indentasi 2 spasi.

Semi-kolom harus berada pada barisnya sendiri setelah deklarasi beberapa variabel untuk memudahkan penambahan variabel baru setelah 'y'. Dalam hal ini di VIM, 'o' + ', z = c' bukan '$a,' + 'z = c'

@lewisdiamond Saya setuju dengan komentar titik koma Anda. Memilikinya di barisnya sendiri memastikan bahwa variabel terakhir juga dapat dengan mudah diedit (hapus, ganti, sisipkan baris setelah/sebelum, dll).

Tetapi juga dicatat bahwa:

1.- Ini bukan tujuan proyek untuk mendukung semua jenis pemformatan.
2.- Menambahkan terlalu banyak kerumitan sekaligus adalah ide yang buruk. Jadi akan lebih baik untuk menjaga fitur ini sesederhana mungkin terlebih dahulu dan mulai meningkatkannya setelah mencapai status rilis dan telah diuji selama beberapa waktu

+1 untuk dukungan koma pertama, dan saya setuju dengan sentimen lewisdiamond bahwa memastikan tab berbaris dengan benar tidak boleh menjadi tujuan akhir karena ada alasan pragmatis untuk gaya koma-pertama. Saya juga akan menyukai dukungan untuk json. Saat ini saya memiliki peretasan dalam kode js-beautify global untuk melakukan banyak alternatif tanda baca pertama (untuk operator ternary adalah suatu keharusan).

Untuk semua orang yang memberi ini +1: silakan lihat cabang https://github.com/beautify-web/js-beautify/tree/feature/comma-first .

Beri tahu saya jika ini adalah langkah pertama yang cukup untuk mencapai apa yang Anda inginkan sehingga saya harus menambahkannya ke rilis berikutnya.

@olsonpm , @lewisdiamond , @lukemartin , @mrchief - bisa kalian lihat cabang https://github.com/beautify-web/js-beautify/tree/feature/comma-first .

Saya akan menghabiskan 30 menit untuk malam ini dan menanggapinya dengan pikiran. Terima kasih telah menindaklanjuti.

Sudah sampai pagi ini. Semuanya terlihat baik bagi saya karena tes Anda. Saya memiliki cabang pribadi dengan banyak fungsi operator pertama - saya melakukan tes koma-pertama melalui cabang Anda dan semuanya lulus tanpa masalah yang merupakan berita bagus.

Ketika saya membuat cabang pribadi saya, saya memutuskan operator koma-pertama akan pasif, artinya sebagai berikut:

var a,
    b;

tidak akan diubah. Anda dengan jelas menyatakan bahwa ini tidak terjadi dalam pesan komit, saya hanya merasa perlu mendiskusikan dengan orang lain perilaku apa yang mereka harapkan jika mereka memilih untuk menggunakan opt.comma_first.

Hal lain, <Output>.previous_line dan flags.previous_text adalah hal yang sama yang saya yakini, yang awalnya membingungkan saya tetapi masuk akal dalam cara Anda menggunakannya.

Selain itu, perbedaan utama antara implementasi kami adalah Anda memilih untuk mengubah baris sebelumnya. Saya mencoba untuk tidak "kembali dan mengedit sesuatu" karena saya pikir itu lebih membingungkan untuk dikembangkan. Sekarang cara Anda lebih ringkas daripada cara saya - mudah dibaca dan Anda mengomentari semuanya. Kode yang ada juga mengedit token sebelumnya sehingga kode Anda benar-benar sejalan - sejujurnya saya hanya mengemukakannya karena saya ingin tahu apa pendapat Anda. Singkatnya, pendapat saya adalah bahwa program ini akan jauh lebih mudah untuk di-debug jika token hanya bertanggung jawab atas ruang putih di depannya berdasarkan token berikutnya.

Terima kasih telah menangani ini!

Sunting: Kesalahan saya - <Output>.previous_line dan flags.previous_text benar-benar berbeda.

Forward-only lebih disukai. Saya melihat bola rambut tentang bagaimana dan di mana kami memutuskan apa yang harus dilakukan dengan/tentang koma, sudah ada tempat yang kami pangkas outputnya kembali untuk menempatkannya di tempat yang tepat. Saya memutuskan untuk melakukan sesuatu yang sedikit sederhana, mendapatkan beberapa tes yang memverifikasi perilaku sederhana dan kemudian melihat tentang penyetelan dan refactor nanti.

Contoh yang Anda sebutkan:

var a,
    b;

Akan menjadi contoh tuning yang bisa dibahas nanti.

Kedengarannya bagus. Saya menghargai umpan balik.

Dan terima kasih banyak telah memeriksanya. Jika Anda memiliki tes yang ingin Anda tambahkan, itu akan sangat membantu.

Apakah halaman ini membantu?
0 / 5 - 0 peringkat