Apa konsekuensi dari memiliki referensi dan penggunaan yang tidak perlu?


12

Saya agak aneh dan cenderung menjaga proyek saya dengan membersihkan referensi dan usingdi setiap kelas hanya menyimpan apa yang sebenarnya digunakan.

Argumen lain apa yang bisa saya buat (selain menenangkan saraf OCD saya) untuk menjaga hal-hal yang penting? Saya pikir sebagian besar referensi sistem, setiap referensi untuk pekerjaan kustom akan membawa banyak masalah kompatibilitas ke belakang. Apakah jejak rilis lebih besar? Kompilasi waktu lebih lama?


5
Perhatikan bahwa usings dan referensi bukan hal yang sama. Banyak jawaban gagal memperhitungkannya.
phoog

1
Jika Anda ingin menjaga kode tetap bersih, dan menggunakan seminimal mungkin, pertimbangkan untuk membeli ReSharper. Ekstensi luar biasa ke Visual Studio. Saya tidak bisa hidup / program tanpa. ;-)
Anders

Jawaban:


13

Intellisense akan menjadi tempat yang jauh lebih berguna bagi Anda jika Anda menjaga usingminimum, dan itu adalah keuntungan besar.

Selain itu, saya rasa tidak ada untungnya. Jadi mungkin kompiler C # akan bekerja lebih cepat dengan, katakanlah, 1%; terus.


1
Nilai kumulatif 1% itu cukup besar ... tetapi pada dasarnya Anda akan mengharapkan kompiler untuk mengoptimalkan masalah apa pun. Namun saya tidak punya masalah dengan menjadi rapi
Murph

C # IntelliSense agak berantakan sejak sekitar 2005, ketika mereka mulai memasukkan semuanya ke dalam daftar.
Rei Miyasaka

@ReiMiyasaka sehingga Anda mendapatkan IntelliSense untuk apa pun yang Anda inginkan dan kemudian lakukan Ctrl+.untuk memperbaiki dengan cepat "Tambahkan namespace XYZ"
kizzx2

1
@Murph: tidak peduli seberapa besar nilai kumulatif 1% pada akhirnya, itu akan tetap 1% dari total yang terakumulasi, sehingga akan selalu menjadi ngawur. Selain itu, kompiler tidak dapat mengabaikan apa pun usingsampai mengetahui bahwa mereka sebenarnya tidak perlu, tetapi tidak dapat mengetahuinya kecuali telah mengkompilasi seluruh file sumber Anda terlebih dahulu. Seperti dengan referensi proyek, mereka tidak dibuang hanya karena mereka tampaknya tidak digunakan, karena mereka dapat digunakan dalam cara yang dinamis (tidak terdeteksi pada waktu kompilasi).
Mike Nakis

1
Sedikit terlambat, tetapi dalam kasus saya, kami membuat aplikasi untuk perangkat sumber daya yang sangat terbatas. Menambahkan referensi yang tidak perlu akan memengaruhi ukuran aplikasi akhir. Dan kami akan mencoba mendistribusikan paket dan bersaing dengan paket lain, paket yang lebih besar dapat membuat pengguna berpikir dua kali untuk mengunduh aplikasi atau tidak.
hmadrigal

9

Karena hampir sepele untuk melakukannya di Visual Studio (klik kanan sederhana), mengapa tidak melakukannya?

Ini konsisten dengan Occam's Razor , itu hanya rekayasa yang bagus.

Mengenai konsekuensi dari tidak melakukannya, pertimbangkan apa yang terjadi jika beberapa pengembang lain mencoba untuk membuka proyek Anda dan itu berisi referensi (yang tidak digunakan) ke perpustakaan yang tidak ada di komputernya. Sekarang pengembang yang buruk perlu mencari tahu mengapa referensi yang belum terselesaikan itu ada dan apa yang harus dilakukan tentang hal itu.

Jika Anda suka, pertimbangkan itu dalam hal aturan emas. Apakah Anda ingin mengambil alih pengembangan pada proyek yang memiliki banyak referensi ke perpustakaan yang tidak Anda miliki di komputer Anda dan bahwa Anda tidak tahu mengapa mereka ada di sana?


+1, ada add-in yang dapat melakukan ini untuk seluruh solusi. Ini juga mengingatkan saya pada video ClojureScript dan Google Closure di mana seluruh optimasi program penting karena halaman web khas sekitar 1MB sekarang. Merupakan kebiasaan yang baik untuk memiliki - membersihkan barang-barang yang tidak diperlukan.
Ayub

6

usingpernyataan hanya untuk kompiler untuk dapat sepenuhnya merujuk kelas, dll. usingPernyataan tambahan tidak akan memiliki efek yang berarti pada waktu kompilasi.

Juga, runtime tidak akan memuat rakitan yang direferensikan sampai benar-benar diperlukan, jadi sekali lagi saya tidak percaya ada konsekuensi negatif dari referensi yang tidak dibutuhkan.

Jika Anda menggunakan alat seperti Reflector, menemukan dan menghapus bit-bit yang tidak perlu ini sebagian besar bisa otomatis, jadi saya katakan boros menghabiskan banyak waktu untuk kegiatan ini. Misalnya, satu atau dua jam menghapus secara manual usingpernyataan yang tidak dibutuhkan lebih dari membayar lisensi Reflector - dan ia hadir dengan banyak fitur peningkatan produktivitas lainnya.


Membersihkan menggunakan adalah fitur bawaan VS 2010 (saya pikir 2008 juga). Dan ReSharper dapat melakukan referensi juga. Tapi ya, sebelum saya memulai pembersihan skala besar, saya akan melihat menggunakan alat untuk melakukan ini untuk saya.
MPelletier

+1 untuk secara jelas mengungkapkan perbedaan antara usingreferensi yang tidak digunakan dan yang tidak digunakan. Keduanya sangat berbeda!
phoog

1

Selain di atas, saya kira belum disebutkan di sini bahwa, setiap referensi memerlukan komponen baik dalam .NET framework atau DLL eksternal. Jika referensi dibuat ke DLL eksternal, Anda harus memiliki itu kapan (dan di mana) Anda menjalankan perangkat lunak.

Sunting - Sesuai komentar valid oleh phoog di bawah ini: Aplikasi akan tetap berjalan jika DLL tidak digunakan dan tidak perlu dikirimkan bersama aplikasi hanya karena ditambahkan ke referensi. Untuk menangani referensi yang tidak digunakan dalam kode, Anda mungkin ingin melihat: Menghapus referensi yang tidak digunakan .


1
Jika referensi tidak digunakan, Anda tidak perlu DLL kapan dan di mana Anda menjalankan perangkat lunak.
phoog

@phoog, terima kasih atas komentar Anda. Setidaknya dalam. NET VS2010, jika Anda secara manual menambahkan referensi ke solusi, DLL secara fisik ditambahkan ke folder bin bahkan jika Anda tidak menggunakannya dalam kode.
NoChance

1
Tetapi, jika Anda menghapus DLL dari folder bin, atau menerbitkan aplikasi tanpa DLL, aplikasi tersebut harus tetap berjalan.
phoog

@ phoog, Anda benar, terima kasih telah menunjukkan ini. Saya akan mengedit posting.
NoChance
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.