Mengapa menghapus yang tidak digunakan menggunakan arahan di C #?


120

Saya bertanya-tanya apakah ada alasan (selain merapikan kode sumber) mengapa pengembang menggunakan fitur "Hapus yang Tidak Digunakan Usings" di Visual Studio 2008?


Saya percaya itu adalah fitur PowerCommands untuk Visual Studio, bukan Visual Studio itu sendiri.
Hosam Aly

3
Di VS2008 ini tentunya merupakan fitur (bersama dengan kemampuan untuk mengurutkan pernyataan penggunaan) dari VS itu sendiri.
Richard

1
@Hosam: PowerCommands memungkinkan Anda melakukannya untuk seluruh proyek / solusi. Melakukan itu per file adalah fitur VS itu sendiri.
konfigurator

3
BTW, periksa Resharper jika Anda ingin kontrol yang lebih tepat atas pembersihan semacam ini.
John Feminella

2
Saya sebenarnya sangat tidak menyukai fitur ini - saya selalu mengedit file dan harus menambahkan kembali semua ruang nama Sistem setelah seseorang membersihkannya (biasanya System, System.Collections.Generic, dan System.Linq.) lebih banyak gesekan daripada yang dihematnya. Sekarang, ruang nama proyek Anda sendiri daripada ruang nama kerangka kerja - yang lebih masuk akal untuk dibersihkan, untuk memperjelas pemasangan kabel program Anda. Berharap ada cara agar VS membersihkan impor hanya dari namespace tertentu dan meninggalkan Sistem yang lebih sering Anda butuhkan.
pengguna1454265

Jawaban:


186

Ada beberapa alasan Anda ingin mengeluarkannya.

  • Tidak ada gunanya. Mereka tidak memberi nilai tambah.
  • Ini membingungkan. Apa yang digunakan dari namespace itu?
  • Jika tidak, maka Anda akan berangsur-angsur tidak berguna using pernyataan yang karena kode Anda berubah seiring waktu.
  • Analisis statis lebih lambat.
  • Kompilasi kode lebih lambat.

Di sisi lain, tidak banyak alasan untuk membiarkannya masuk. Saya rasa Anda menghemat tenaga karena harus menghapusnya. Tetapi jika Anda malas, Anda punya masalah yang lebih besar!


59
Seorang programmer yang baik itu malas, dia memaksimalkan pekerjaan untuk TIDAK dilakukan. : D
Nicolas Dorier

34
Saya tidak setuju bahwa programmer yang baik itu malas, tapi saya setuju dengan pernyataan Anda. Seorang programmer yang baik akan menghapusnya untuk menjaga kodenya tetap bersih dan dengan demikian menghindari pekerjaan / masalah / masalah di masa depan untuk dirinya sendiri dan orang lain.
Allan

2
Benar, itu tautan yang bagus. Saya rasa maksud saya hanyalah bahwa kita menginginkan "malas yang baik" daripada "malas yang buruk"; yang terakhir adalah di mana programmer tidak bisa diganggu untuk menulis kode yang baik.
Allan

5
Ada gunanya meninggalkan ruang nama standar juga. Pada proyek dan tim besar, membiarkannya menghasilkan lebih sedikit potensi konflik penggabungan, dan lebih sedikit file untuk peninjauan kode. Selain itu, banyak pengembang menambahkan metode ekstensi yang membingungkan dan sulit ditemukan, dan terkadang menemukan ruang nama yang diperlukan untuk metode ekstensi ini merepotkan. Pengembang baru mungkin terbiasa memiliki System.Linq, disertakan dalam file kode mereka, dan membuang banyak waktu untuk mencoba mencari tahu mengapa metode tertentu tidak tersedia sebelum meminta bantuan.
Tandai Di Ramp51

5
Anda mungkin ingin menyimpan beberapa di antaranya untuk mencegah intellisense menjadi bodoh sekali dalam pengkodean di masa mendatang.
yazanpro

24

Saya akan mengatakan sebaliknya - sangat membantu untuk menghapus pernyataan penggunaan yang tidak diperlukan dan tidak perlu.

Bayangkan Anda harus kembali ke kode Anda dalam 3, 6, 9 bulan - atau orang lain harus mengambil alih kode Anda dan memeliharanya.

Jika Anda memiliki daftar panjang cucian yang menggunakan pernyataan yang tidak benar-benar diperlukan, melihat kodenya bisa sangat membingungkan. Mengapa itu digunakan di sana, jika tidak ada yang digunakan dari namespace itu ??

Saya kira dalam hal pemeliharaan jangka panjang dalam lingkungan profesional, saya sangat menyarankan untuk menjaga kode Anda sebersih mungkin - dan itu termasuk membuang hal-hal yang tidak perlu darinya. Lebih sedikit kekacauan berarti lebih sedikit kebingungan dan dengan demikian lebih tinggi perawatannya.

Marc


14

Bagi saya ini adalah pertanyaan yang sangat masuk akal, yang diperlakukan dengan cara yang cukup sembrono oleh orang-orang yang menanggapi.

Saya akan mengatakan bahwa setiap perubahan pada kode sumber harus dibenarkan. Perubahan ini dapat memiliki biaya tersembunyi, dan orang yang mengajukan pertanyaan ingin diberi tahu tentang hal ini. Mereka tidak meminta untuk disebut "malas", seperti yang ditiru satu orang.

Saya baru saja mulai menggunakan Resharper, dan itu mulai memberikan peringatan dan petunjuk gaya pada proyek yang menjadi tanggung jawab saya. Diantaranya adalah penghapusan redundan menggunakan direktif, tetapi juga kualifikasi yang berlebihan, kapitalisasi dan banyak lagi. Naluri saya adalah merapikan kode dan menyelesaikan semua petunjuk, tetapi kepala bisnis saya memperingatkan saya terhadap perubahan yang tidak dapat dibenarkan.

Kami menggunakan proses build otomatis, dan oleh karena itu setiap perubahan pada repositori SVN kami akan menghasilkan perubahan yang tidak dapat kami tautkan ke proyek / bug / masalah, dan akan memicu build dan rilis otomatis yang tidak memberikan perubahan fungsional ke versi sebelumnya.

Jika kita melihat pada penghapusan kualifikasi yang berlebihan, ini mungkin dapat menyebabkan kebingungan bagi pengembang karena kelas lapisan Domain dan Data kami hanya dibedakan oleh kualifikasi.

Jika saya melihat penggunaan yang tepat dari kapitalisasi anakronim (yaitu ABCD -> Abcd) maka saya harus memperhitungkan bahwa Resharper tidak merefaktor salah satu file Xml yang kami gunakan nama kelas referensi tersebut.

Jadi, mengikuti petunjuk ini tidak sesederhana kelihatannya, dan harus diperlakukan dengan hormat.


6
Poin yang Baik, tetapi Anda juga tidak boleh lupa bahwa menjaga kode yang bersih dan tidak rumit meningkatkan pemeliharaan yang juga merupakan tujuan bisnis. Anda harus menimbang keduanya. Idealnya, Anda ingin melakukan pemfaktoran ulang semacam ini segera setelah rilis sehingga Anda dapat memiliki batu tulis sebersih mungkin untuk memulai yang baru dan memiliki banyak waktu untuk menangkap regresi akhirnya.
David Reis

14

Selain alasan yang telah diberikan, ini mencegah konflik penamaan yang tidak perlu. Pertimbangkan file ini:

using System.IO;
using System.Windows.Shapes;

namespace LicenseTester
{
    public static class Example
    {
        private static string temporaryPath = Path.GetTempFileName();
    }
}

Kode ini tidak dapat dikompilasi karena ruang nama System.IO dan System.Windows.Shapes masing-masing berisi kelas yang disebut Path. Kami dapat memperbaikinya dengan menggunakan jalur kelas lengkap,

        private static string temporaryPath = System.IO.Path.GetTempFileName();

atau kami dapat langsung menghapus garis tersebut using System.Windows.Shapes;.


13

Lebih sedikit opsi dalam munculan Intellisense (terutama jika ruang nama berisi banyak metode Ekstensi).

Secara teoritis Intellisense juga harus lebih cepat.


1
1 untuk Intellisense. Sebenarnya lambat saat memulai (saya sering melihat "Membuat cache, coba lagi nanti"), jadi ini mungkin sangat signifikan. Kompilasi waktu yang dibicarakan orang lain ... Saya belum melihat angka.
Luc

5

Hapus mereka. Lebih sedikit kode untuk dilihat dan bertanya-tanya tentang menghemat waktu dan kebingungan. Saya berharap lebih banyak orang akan MENJAGA HAL-HAL SEDERHANA, RAPI dan TIDY. Ini seperti memiliki kemeja dan celana kotor di kamar Anda. Itu jelek dan Anda harus bertanya-tanya mengapa itu ada di sana.


4

Ini juga membantu mencegah ketergantungan melingkar palsu, dengan asumsi Anda juga dapat menghapus beberapa referensi dll / proyek dari proyek Anda setelah menghapus penggunaan yang tidak terpakai.


3

Kode dikompilasi lebih cepat.


5
Punya bukti untuk mendukungnya?
cjk

14
Oh CK - Anda menangkap saya lagi. Aku berbohong. Menghapus teks yang tidak perlu sebenarnya membuat kompilasi kode lebih lambat. Pikirkanlah :)
Akun mati

@ck: Saya telah memverifikasi bahwa menghapus pernyataan menggunakan yang tidak terpakai dari sebuah proyek di tempat kerja meningkatkan waktu kompilasi dengan jumlah yang nyata. Tentu saja akan - lebih sedikit byte untuk membaca dari hard drive.
konfigurator

19
Alangkah baiknya melihat beberapa statistik nyata. Jika kita hanya menghemat beberapa milidetik saat mengompilasi, maka kecepatan bukanlah argumen yang meyakinkan. Namun, ada alasan lain untuk menghapus pernyataan penggunaan yang tidak diperlukan.
Greg

3
Ini bukan tentang berbohong atau tidak. Setiap orang yang bijaksana akan mengira bahwa lebih sedikit kekacauan berarti lebih banyak efisiensi. "Bukti" untuk mendukungnya adalah memberikan nilai pada respons Anda dan mendukung argumen bahwa "lebih cepat" tidak berarti hanya beberapa md, tetapi sebenarnya pengalaman yang lebih baik untuk lebih cepat menyusun proyek Anda.
Matheus Felipe

3

Baru-baru ini saya mendapat alasan lain mengapa menghapus impor yang tidak terpakai cukup membantu dan penting.

Bayangkan Anda memiliki dua rakitan, di mana yang satu mereferensikan yang lain (untuk sekarang mari kita panggil yang pertama Adan yang direferensikan B). Sekarang ketika Anda memiliki kode di A yang bergantung pada B semuanya baik-baik saja. Namun pada beberapa tahap dalam proses-pengembangan Anda, Anda melihat bahwa Anda sebenarnya tidak memerlukan kode itu lagi tetapi Anda membiarkan pernyataan-menggunakan di tempatnya. Sekarang Anda tidak hanya memiliki using-directive yang tidak berarti tetapi juga referensi-assembly keB yang tidak digunakan di mana saja tetapi dalam direktif usang. Ini pertama-tama meningkatkan jumlah waktu yang dibutuhkan untuk kompilasi A, karena Bharus dimuat juga.

Jadi ini bukan hanya masalah pada kode yang lebih bersih dan lebih mudah dibaca tetapi juga pada pemeliharaan referensi-assembly dalam kode-produksi di mana tidak semua rakitan yang direferensikan itu bahkan ada .

Akhirnya di contoh kami, kami harus mengirimkan B dan A bersama-sama, meskipun B tidak digunakan di mana pun di A tetapi di usingbagian-. Ini secara besar-besaran akan mempengaruhi runtime -performance Asaat memuat assembly.


2

Setidaknya dalam teori, jika Anda diberi file C # .cs (atau file kode sumber program apa pun), Anda harus dapat melihat kode dan membuat lingkungan yang mensimulasikan semua yang dibutuhkannya. Dengan beberapa teknik kompilasi / parsing, Anda bahkan dapat membuat alat untuk melakukannya secara otomatis. Jika ini dilakukan oleh Anda setidaknya dalam pikiran, Anda dapat memastikan Anda memahami semua yang dikatakan file kode.

Sekarang pertimbangkan, jika Anda diberi file .cs dengan 1000 usingarahan yang hanya 10 yang benar-benar digunakan. Setiap kali Anda melihat simbol yang baru diperkenalkan dalam kode yang mereferensikan dunia luar, Anda harus melalui 1000 baris tersebut untuk mencari tahu apa itu. Ini jelas memperlambat prosedur di atas. Jadi jika Anda bisa menguranginya menjadi 10, itu akan membantu!

Menurut pendapat saya, usingdirektif C # sangat lemah, karena Anda tidak dapat menentukan simbol generik tunggal tanpa kehilangan sifat generik, dan Anda tidak dapat menggunakan usingperintah alias untuk menggunakan metode ekstensi. Ini tidak terjadi dalam bahasa lain seperti Java, Python, dan Haskell, dalam bahasa tersebut Anda dapat menentukan (hampir) dengan tepat apa yang Anda inginkan dari dunia luar. Tapi acara kemudian, saya akan menyarankan untuk menggunakan usingalias bila memungkinkan.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.