Definitelytyped: Tab vs spasi?

Tidak ada pertempuran. Gunakan tab.

Saya memilih spasi!

Biarkan konflik internal dimulai! :senyum:

ha ha. kita tidak membutuhkan itu. Tapi tahukah Anda... kami tidak akan melakukan percakapan ini jika kami menggunakan tab dan setiap pengembang masih memiliki kode yang disejajarkan dengan sempurna seperti yang diinginkannya (2 spasi atau 4 spasi). Hanya mengatakan.

Saya suka tab.
tapi saya pikir kita harus mematuhi pengaturan default untuk VisualStudio.

Spasi dengan ukuran indentasi 4 (default VS).
Atur IDE Anda untuk melakukan tab virtual untuk Anda dan semua orang senang.
Saya hanya tidak suka melihat [tab] [tab] [spasi] [spasi] [spasi] untuk kode yang ingin disejajarkan dengan kata pada baris di atas.

Jika ada yang ingin menulis aturan TSLint untuk menerapkan gaya yang konsisten (misalnya: tab atau 4 spasi tetapi tidak keduanya) maka kami akan menjalankannya di penguji baru (memiliki dukungan TSLint).

Lihat juga https://github.com/palantir/tslint/issues/122

Spasi! FWIW JS libs menggunakan spasi (sudut/jquery)

Ini mungkin terjadi karena Crockford : http://javascript.crockford.com/code.html

Satuan lekukan adalah empat spasi. Penggunaan tab harus dihindari karena (sampai tulisan ini ditulis di abad ke-21) masih belum ada standar untuk penempatan tabstop. Penggunaan spasi dapat menghasilkan ukuran file yang lebih besar, tetapi ukurannya tidak signifikan melalui jaringan lokal, dan perbedaannya dihilangkan dengan minifikasi.

Karena TS adalah JS, kita benar-benar harus menyesuaikan diri.

Yah, Crockford adalah pria tua yang sedikit pemarah, jadi aku menganggapnya sebagai garam.

Ada statistik di Reddit beberapa waktu lalu di mana seseorang menganalisis sebagian besar Github dan itu seperti 60% / 40% mendukung spasi. Saya sendiri dan semua tempat saya bekerja sejauh ini adalah tab (walaupun sebagian besar adalah AS3). Ini bekerja dengan baik. Penyelarasan kode hanya membuang-buang waktu tetapi jika diperlukan tab pintar juga berfungsi dengan baik di sana.

Kutukan sebenarnya yang ingin saya singkirkan adalah campuran _indents_. Sebelum kita pergi termonuklir pada satu atau yang lain di seluruh repo, setidaknya harus konsisten _per file_.

Pada titik tertentu kami akan melakukan #2228 tetapi itu adalah langkah yang cukup besar (mengacaukan banyak atribusi sehingga kami dapat membiarkan @dt-bot melakukannya).

Yah, Crockford adalah pria tua yang sedikit pemarah, jadi aku menganggapnya sebagai garam.

sepakat

Jika Anda bosan, saya sarankan untuk membaca permintaan tarik yang dibuat ke JSON.js. selalu mereka disampaikan oleh orang-orang yang tidak tahu cara Doug yang sedikit aneh. Mereka semua ditolak titik kosong :-)

Baru saja melihat ini: https://github.com/iplabs/typescript/blob/languageService-v2/src/services/languageService.ts#L199 -L213 defaultnya adalah 4 spasi dengan tab dikonversi ke spasi

    export class EditorOptions {
        public IndentSize: number = 4;
        public TabSize: number = 4;
        public NewLineCharacter: string = "\r\n";
        public ConvertTabsToSpaces: boolean = true;

        public static clone(objectToClone: EditorOptions): EditorOptions {
            var editorOptions = new EditorOptions();
            editorOptions.IndentSize = objectToClone.IndentSize;
            editorOptions.TabSize = objectToClone.TabSize;
            editorOptions.NewLineCharacter = objectToClone.NewLineCharacter;
            editorOptions.ConvertTabsToSpaces = objectToClone.ConvertTabsToSpaces;
            return editorOptions;
        }
    }

Sungguh memuaskan @basarat!

CRLF agak bodoh tapi terserah.

Mungkin kita harus pergi untuk itu. Saya akan mencoba menjalankan TypeScript-formatter pada semuanya dan melihat apa yang terjadi.

Tuan yang terhormat, rumah jagal yang luar biasa.. 562 total file .d.ts, dengan 446 file diubah..

https://github.com/Bartvds/DefinitelyTyped/tree/34907936bfc22562f30bb09ee82282ca0515b8b3

https://github.com/Bartvds/DefinitelyTyped/commit/34907936bfc22562f30bb09ee82282ca0515b8b3

Maaf, kami tidak dapat menampilkan seluruh perbedaan karena terlalu banyak file (446) yang diubah

Heh.

Dan melakukan tes juga:

https://github.com/Bartvds/DefinitelyTyped/tree/46f9d17b2b074c887bff35b06112070b28924248

https://github.com/Bartvds/DefinitelyTyped/commit/46f9d17b2b074c887bff35b06112070b28924248

Maaf, kami tidak dapat menampilkan seluruh perbedaan karena terlalu banyak file (442) yang diubah.

Bagus. Jadi kami memiliki teknologi, itu bagian yang mudah. Tetapi sekarang perlu memutuskan apakah ini adalah sesuatu yang kita inginkan karena itu akan memiliki dampak yang serius.

Untuk satu baris atribusi akan ke neraka. Dan jika kami menerimanya, kami mungkin harus menerapkan pemformatan di tester. Saya memiliki pengaturan TSLint di tester (tetapi dinonaktifkan) sehingga dapat melakukan banyak hal.

Mungkin kita harus meningkatkan penguji ke utilitas CLI yang dapat menjalankan pemformat dan menjalankan tes, dengan cara yang dapat digunakan dengan baik (ini agak berfungsi sekarang secara lokal tetapi harus ditingkatkan dengan api CLI bersih dll).

Saya katakan lebih cepat lebih baik. Tetapi kabar baiknya adalah Anda tidak akan kehilangan sejarah kesalahan . Saya berharap GitHub telah mengimplementasikan fitur ini juga dalam tampilan berbeda mereka.

Ya, tapi sayang sekali bahwa git blame -w -M tidak berfungsi secara online. Saya baru saja mengirim email ke dukungan Github tentang hal itu.

@Bartvds , ada tanggapan dari GitHub?!

Mengabaikan spasi putih pada tampilan kesalahan GitHub tidak dimungkinkan saat ini, tetapi kami mungkin menambahkannya di masa mendatang. Terima kasih atas sarannya, saya akan menambahkannya ke Daftar Permintaan Fitur sehingga tim dapat melihatnya.

Jadi mungkin butuh beberapa saat, jika pernah.

Saya tidak peduli apa yang dikatakan oleh orang yang tahu segalanya atau panduan gaya – tab untuk lekukan adalah satu-satunya cara untuk mempertahankan maksud pengembang saat penyelarasan terlibat. Lihat posting blog saya tentang hal itu .

konsep penyelarasan kode (selaraskan pada var dan = dalam kasus Anda) bagus. Tapi yang sulit untuk dipertahankan dalam refactoring. Jadi saya tidak menggunakannya saja. Juga alat format otomatis tidak menghormatinya misalnya kode format otomatis di TypeScript

Juga untuk

  public string FirstName { get; set; }        =>  public  string  FirstName { get; set; }    
  public string Surname { get; set; }          =>  public  string  Surname   { get; set; }
  public int Age { get; private set; }         =>  public  int     Age       { get; private set; }
  private Address Address { get;  set; }       =>  private Address Address   { get; set; } 

Tambahkan properti baru dan Anda perlu _reformat_ semua baris ini. Bukan perubahan kode yang baik untuk ditinjau.

Alur kerja Anda mungkin berbeda dan mungkin memungkinkan untuk ini. Itu membuatnya lebih mudah untuk dibaca (kode sebagai seni) tetapi saya belum berhasil mengalami tim yang memindahkannya.

Itu hal yang paling aneh. Reaksi naluriah saya terhadap gagasan mencampur tab dan spasi adalah menggigil dan berpikir "itu kotor!"

Benar-benar irasional saya tahu - tetapi sepenuhnya tulus. Manusia memang aneh...

@johnnyreilly Anda adalah korban kesalahpahaman umum . Menggunakan tab untuk lekukan dan spasi untuk penyelarasan BUKAN hal yang sama dengan _mixing_ tab dengan spasi. Anda jelas tidak membaca posting blog.

Menggunakan tab untuk penyelarasan adalah mengapa begitu banyak yang telah dimatikan dari tab sama sekali, karena orang-orang melakukannya dengan salah. Seandainya mereka melakukannya dengan benar sejak awal, tidak ada yang akan memperhatikan ketika mereka mengubah preferensi editor mereka untuk menampilkan lebar tab pada ukuran yang berbeda. Inilah yang coba ditunjukkan oleh gif animasi di atas, bagaimana orang-orang melakukan kesalahan.

@basarat , saya sangat setuju dengan Anda. Saya jarang mengerjakan proyek dengan penyelarasan kode, tetapi saya melihatnya dari waktu ke waktu. Jika Anda entah bagaimana dapat menegakkan bahwa pengembang di proyek Anda tidak menggunakan penyelarasan sama sekali, maka saya akan mengatakan lakukan saja. Jika tidak, dengan spasi untuk lekukan, tidak ada cara untuk alat linting, antara lain, untuk membedakan antara apa yang dimaksudkan untuk lekukan vs apa yang dimaksudkan untuk penyelarasan, di luar penguraian kode menjadi CST (cara berlebihan).

Tentu saja, ada banyak alasan lain untuk tidak menggunakan spasi untuk lekukan di zaman modern ini. Editor menangani tab dengan baik, tetapi mereka tidak pernah berurusan dengan spasi. Navigasi tombol panah, hapus, backspace – mereka tidak memperlakukan satu indentasi spasi seperti satu unit. Saya telah menggunakan Visual Studio, Sublime, PHPStorm dan Notepad ++, tetapi mereka semua memiliki masalah mendasar dengan spasi untuk lekukan.

Navigasi tombol panah, hapus, backspace – mereka tidak memperlakukan satu indentasi spasi seperti satu unit.

Navigasi: Saya menggunakan tombol ctrl + panah. Mereka melompati spasi (semua spasi benar-benar) + kata.

Untuk hapus / backspace: Untuk pemilihan kata saya menggunakan kata perluas (ctrl+w dari default resharper) dan unexpand selection (ctrl+shift+w). Saya jarang perlu memilih _inside_ whitespace, cukup gunakan tab (tambahkan indentasi) dan shift tab (kurangi indentasi).

@jedmao sebenarnya saya mengerti maksud Anda - saya hanya membagikan reaksi naluriah (dan irasional) saya. Saya tidak mengatakan itu masuk akal :senyum:

@johnnyreilly paham .

@basarat Saya menggunakan kunci Home dan End dalam beberapa skenario spasi putih Anda. Saya telah mencoba menggunakan navigasi Ctrl + arrow key tetapi tidak selalu berhasil. Inilah mengapa saya jarang menggunakannya karena konsistensi mental. Perhatikan contoh berikut:

for (var i = 0; i < 10; i++) {
    if (i > 5) {
        console.log('I am greater than 5');
    }
}

Katakanlah kursor saya berada di awal baris 3 dan saya ingin menavigasi ke awal baris 2.

Menggunakan teknik Anda di Sublime, saya bisa melakukannya dengan salah satu dari 2 cara:

• Up , Hold Ctrl , Left , Release Ctrl (4 langkah logis)
• Hold Ctrl , Left , Release Ctrl , Up , Hold Ctrl , Right , Left , Release Ctrl (8 langkah logis)

Di Visual Studio, skenario ke-2 dapat dikurangi menjadi 7 langkah logis.

• Hold Ctrl , Left , Release Ctrl , Up , Hold Ctrl , Right , Release Ctrl (7 langkah logis)

Dengan karakter tab yang sebenarnya, jalur terpendek hanya 2 langkah logis tanpa tombol pengubah. Tidak bisa lebih sederhana.

• Left , Up

Saya gagal melihat bagaimana pemilihan kata akan membantu dalam menghapus atau memundurkan indentasi spasi. Saya mencobanya di Visual Studio tanpa hasil. Inilah mengapa saya membuat Plugin TabSanity untuk Visual Studio . Sayangnya, saya tidak mengetahui plugin semacam itu untuk editor lain.

Dengan karakter tab yang sebenarnya, selalu 2 langkah logis tanpa tombol pengubah. Tidak bisa lebih sederhana

:+1: Saya melihat keuntungan Anda. Namun ketika saya mengedit komentar ini, ctrl dll berfungsi sama dengan VS saya sehingga kebiasaan saya terbawa;)

Saya gagal melihat bagaimana pemilihan kata akan membantu dalam menghapus atau memundurkan indentasi spasi

Buruk saya, deskripsi saya membingungkan. Abaikan bit pemilihan "kata". Fokus saja pada I rarely need to select inside whitespace though, just use tab (increase indent) and shift tab (decrease indent). Ini bekerja dengan indentasi spasi dengan baik.

Dengan karakter tab yang sebenarnya, selalu 2 langkah logis tanpa tombol pengubah.

Bagaimana dengan :

public  string  FirstName { get; set; }    
public  string  Surname   { get; set; }
public  int     Age       { get; private set; }
private Address Address   { get; set; } 

Bukankah dari awal Age untuk mengubah jenis Surname yaitu string pada baris sebelumnya sama dengan skenario Ctrl ?

@basarat saya menggunakan Tab dan Shift+Tab religius; meskipun, biasanya untuk beberapa baris kode. Saya kira Anda bisa mengatakan bahwa Shift+Tab adalah alias yang bagus untuk penekanan tombol backspace pada tab, tetapi jelas tidak sesederhana atau seintuitif backspace .

Ctrl+Delete akan menjadi alias terdekat dengan kunci Delete , tetapi memiliki potensi untuk menghapus lebih dari satu indentasi; sedangkan, kunci Delete pada tab hanya menghapus satu indentasi. Bekerja kadang-kadang dan bukan yang lain adalah mengapa saya tidak menggunakannya sama sekali (konsistensi mental).

Saya, seperti Anda, juga jarang, jika pernah, perlu memilih spasi di dalam. Saya tidak pernah menyarankan bahwa saya akan melakukannya. Saya tidak memilih spasi putih, tetapi menavigasinya untuk mencapai suatu tempat. Contoh keselarasan Anda di atas pasti ketika saya akan menggunakan navigasi Ctrl + arrow key . Inilah sebabnya, seperti yang saya katakan sebelumnya, saya jarang menggunakan navigasi Ctrl + arrow key karena skenario yang Anda tunjukkan mungkin satu-satunya kasus di mana saya akan menggunakannya.

Pada akhirnya, yang paling mengganggu saya adalah Anda harus benar-benar mengubah memori otot Anda saat beralih di antara file dengan tab untuk lekukan vs. spasi untuk lekukan. Apa yang efisien (langkah logis paling sedikit) dalam file dengan tab untuk lekukan sama sekali tidak berfungsi dalam file dengan spasi untuk lekukan. Anda bisa menyalahkan editor karena tidak memberi Anda pengalaman yang mulus, tetapi itu tidak adil karena secara harfiah tidak mungkin (tanpa CST) bagi editor untuk membuat asumsi dalam file dengan spasi untuk lekukan tentang apa yang dimaksud dengan indentasi dan apa yang disejajarkan.

Yang lebih membuat frustrasi adalah sangat sulit bagi orang untuk mengenalinya. Ruang untuk lekukan adalah kejahatan murni... dengan tanduk.

Kesimpulan akhir? Saya hanya ingin berkontribusi, apa yang Anda gunakan?

Kesimpulan akhir? Saya hanya ingin berkontribusi, apa yang Anda gunakan

Konsisten per file. Jangan campur ini dalam satu file

@basarat komiknya salah. Kita semua tahu orang Apple akan menggunakan spasi dan orang Microsoft akan menggunakan tab.

@jedmao Saya seorang pria ms dan saya menggunakan spasi :)

Saya pikir #4211 adalah proposal yang bagus.

Saya akan mengusulkan untuk menggunakan 2 spasi seperti yang dilakukan dalam panduan gaya airbnb/javascript ...

Saran: Gunakan standar pengkodean yang ditetapkan oleh perpustakaan yang sedang diketik. Jika pustaka yang diketik menggunakan spasi, tanda kutip tunggal, dan LF, lakukan hal yang sama dalam definisi tipe. Dengan cara ini kita dapat menghindari argumen spasi vs tab.

Satu-satunya masalah adalah tidak mudah untuk menegakkan aturan ini. Jika Anda perlu menegakkannya dan memiliki konsistensi penuh, maka saya akan merekomendasikan untuk mengikuti konvensi paling populer. Menurut situs web ini , itu spasi dan tanda kutip tunggal.

Preferensi pribadi saya adalah spasi (4) dan _double_ tanda kutip, tapi saya baik-baik saja dengan menggunakan tanda kutip tunggal jika itu berarti semuanya konsisten.

Bisakah pengguna pro-tab dan pro-tab-space menerima kompromi serupa?

Preferensi pribadi saya adalah spasi (4) dan tanda kutip ganda, tetapi saya boleh menggunakan tanda kutip tunggal jika itu berarti semuanya konsisten.

@glen-84 murni untuk hiburan Anda ... di sini mengapa tim penyusun menggunakan tanda kutip ganda: https://github.com/Microsoft/TypeScript/issues/5811#issuecomment -160187924

• JSON
• Bekerja di semua bahasa sehingga lebih sedikit beban kognitif

Saya pribadi menggunakan tanda kutip tunggal karena saya mendapati diri saya melakukan lebih banyak dan lebih banyak TypeScript secara eksklusif :rose:

Saya pikir itu juga sedikit lebih terbaca, dan itu adalah 57% vs 43% (bukan perbedaan besar), tapi saya kira Anda harus menarik garis di suatu tempat. =)

Saya suka titik @jedmao pada tab untuk lekukan dan spasi untuk penyelarasan.

Pengungkapan penuh: Saya berasal dari Go-land di mana kami memiliki go fmt dan tidak pernah ada diskusi tentang tab atau spasi .. Ini tab untuk lekukan dan spasi untuk penyelarasan dan berfungsi dengan sangat baik :+1:

Spasi tentunya. Karena tidak ada yang tahu bagaimana tab dirender dengan tepat di editor yang berbeda jika digunakan di tempat lain.

@hinell mengapa penting jika tab dirender secara berbeda di editor yang berbeda? Seharusnya tidak, selama tab "hanya" digunakan untuk indentasi.

Saya lebih suka tab, terutama karena ini: http://nickgravgaard.com/elastic-tabstops/

Ternyata, ada alasan yang lebih besar lagi untuk menggunakan tab: aksesibilitas pengembang .

• https://github.com/prettier/prettier/issues/7475
• https://www.reddit.com/r/javascript/comments/c8drjo/nobody_talks_about_the_real_reason_to_use_tabs/