Saya bertanya-tanya apakah ada alasan (selain merapikan kode sumber) mengapa pengembang menggunakan fitur "Hapus yang Tidak Digunakan Usings
" di Visual Studio 2008?
Saya bertanya-tanya apakah ada alasan (selain merapikan kode sumber) mengapa pengembang menggunakan fitur "Hapus yang Tidak Digunakan Usings
" di Visual Studio 2008?
Jawaban:
Ada beberapa alasan Anda ingin mengeluarkannya.
using
pernyataan yang karena kode Anda berubah seiring waktu.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!
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
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.
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;
.
Lebih sedikit opsi dalam munculan Intellisense (terutama jika ruang nama berisi banyak metode Ekstensi).
Secara teoritis Intellisense juga harus lebih cepat.
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.
Kode dikompilasi lebih cepat.
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 A
dan 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 B
harus 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 using
bagian-. Ini secara besar-besaran akan mempengaruhi runtime -performance A
saat memuat assembly.
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 using
arahan 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, using
direktif C # sangat lemah, karena Anda tidak dapat menentukan simbol generik tunggal tanpa kehilangan sifat generik, dan Anda tidak dapat menggunakan using
perintah 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 using
alias bila memungkinkan.