it-swarm-id.com

Apakah #regions adalah antipattern atau kode bau?

C # memungkinkan penggunaan #region/#endregion kata kunci untuk membuat area kode dilipat di editor. Setiap kali saya melakukan ini, meskipun saya melakukannya untuk menyembunyikan potongan besar kode yang mungkin dapat di refactored ke kelas atau metode lain. Sebagai contoh saya telah melihat metode yang berisi 500 baris kode dengan 3 atau 4 wilayah hanya untuk membuatnya dapat dikelola.

Jadi, apakah penggunaan wilayah secara bijaksana merupakan tanda masalah? Sepertinya begitu bagi saya.

274
Craig

Bau kode adalah gejala yang menunjukkan bahwa ada masalah dalam desain yang berpotensi meningkatkan jumlah bug: ini bukan kasus untuk daerah, tetapi daerah dapat berkontribusi menciptakan bau kode, seperti metode panjang.

Sejak:

Anti-pola (atau antipattern) adalah pola yang digunakan dalam operasi sosial atau bisnis atau rekayasa perangkat lunak yang mungkin umum digunakan tetapi tidak efektif dan/atau kontraproduktif dalam praktiknya

region are anti-pola. Mereka membutuhkan lebih banyak pekerjaan yang tidak meningkatkan kualitas atau keterbacaan kode, yang tidak mengurangi jumlah bug, dan yang hanya dapat membuat kode lebih rumit untuk diperbaiki.

Jangan gunakan daerah di dalam metode; refactor sebagai gantinya

Metode harus pendek . Jika hanya ada sepuluh baris dalam suatu metode, Anda mungkin tidak akan menggunakan daerah untuk menyembunyikan lima di antaranya saat mengerjakan lima lainnya.

Juga, setiap metode harus melakukan satu dan satu-satunya hal . Daerah, di sisi lain, dimaksudkan untuk memisahkan hal-hal yang berbeda . Jika metode Anda menggunakan A, maka B, masuk akal untuk membuat dua wilayah, tetapi ini adalah pendekatan yang salah; alih-alih, Anda harus mengubah metode menjadi dua metode terpisah.

Menggunakan wilayah dalam kasus ini juga dapat membuat refactoring lebih sulit. Bayangkan Anda memiliki:

private void DoSomething()
{
    var data = LoadData();
    #region Work with database
    var verification = VerifySomething();
    if (!verification)
    {
        throw new DataCorruptedException();
    }

    Do(data);
    DoSomethingElse(data);
    #endregion

    #region Audit
    var auditEngine = InitializeAuditEngine();
    auditEngine.Submit(data);
    #endregion
}

Meruntuhkan wilayah pertama untuk berkonsentrasi pada yang kedua tidak hanya berisiko: kita dapat dengan mudah melupakan pengecualian menghentikan aliran (mungkin ada klausa penjaga dengan return sebagai gantinya, yang bahkan lebih sulit dikenali), tetapi juga akan memiliki masalah jika kode tersebut harus di refactored dengan cara ini:

private void DoSomething()
{
    var data = LoadData();
    #region Work with database
    var verification = VerifySomething();
    var info = DoSomethingElse(data);

    if (verification)
    {
        Do(data);
    }

    #endregion

    #region Audit
    var auditEngine = InitializeAuditEngine(info);
    auditEngine.Submit(
        verification ? new AcceptedDataAudit(data) : new CorruptedDataAudit(data));
    #endregion
}

Sekarang, wilayah tidak masuk akal, dan Anda tidak dapat membaca dan memahami kode di wilayah kedua tanpa melihat kode di yang pertama.

Kasus lain yang kadang saya lihat adalah yang ini:

public void DoSomething(string a, int b)
{
    #region Validation of arguments
    if (a == null)
    {
        throw new ArgumentNullException("a");
    }

    if (b <= 0)
    {
        throw new ArgumentOutOfScopeException("b", ...);
    }
    #endregion

    #region Do real work
    ...
    #endregion
}

Sangat menggoda untuk menggunakan kawasan saat validasi argumen mulai menjangkau puluhan LOC, tetapi ada cara yang lebih baik untuk menyelesaikan masalah ini: yang digunakan oleh kode sumber .NET Framework:

public void DoSomething(string a, int b)
{
    if (a == null)
    {
        throw new ArgumentNullException("a");
    }

    if (b <= 0)
    {
        throw new ArgumentOutOfScopeException("b", ...);
    }

    InternalDoSomething(a, b);
}

private void InternalDoSomething(string a, int b)
{
    ...
}

Jangan gunakan wilayah di luar metode untuk mengelompokkan

  • Beberapa orang menggunakannya untuk mengelompokkan bidang, properti, dll. Pendekatan ini salah: jika kode Anda sesuai dengan StyleCop, maka bidang, properti, pribadi metode, konstruktor, dll. sudah dikelompokkan bersama dan mudah ditemukan. Jika tidak, maka saatnya untuk mulai berpikir tentang menerapkan aturan yang memastikan keseragaman di seluruh basis kode Anda.

  • Orang lain menggunakan daerah untuk menyembunyikan banyak entitas serupa . Misalnya, ketika Anda memiliki kelas dengan ratusan bidang (yang membuat setidaknya 500 baris kode jika Anda menghitung komentar dan spasi putih), Anda mungkin tergoda untuk meletakkan bidang-bidang itu di dalam suatu wilayah, menciutkannya, dan melupakannya. Sekali lagi, Anda salah melakukannya: dengan begitu banyak bidang dalam suatu kelas, Anda harus berpikir lebih baik tentang menggunakan warisan atau mengiris objek menjadi beberapa objek.

  • Akhirnya, beberapa orang tergoda untuk menggunakan daerah untuk mengelompokkan hal-hal terkait : acara dengan delegasinya, atau metode yang terkait dengan IO dengan metode lain yang berhubungan dengan IO, dll. Dalam kasus pertama, itu menjadi berantakan yang sulit untuk dipertahankan, dibaca dan dipahami. Dalam kasus kedua, desain yang lebih baik mungkin akan membuat beberapa kelas.

Apakah ada gunanya untuk daerah?

Tidak. Ada penggunaan sebelumnya: kode yang dihasilkan. Namun, alat pembuat kode hanya harus menggunakan kelas parsial saja. Jika C # memiliki dukungan wilayah, itu sebagian besar karena warisan ini digunakan, dan karena sekarang terlalu banyak orang menggunakan wilayah dalam kode mereka, tidak mungkin untuk menghapusnya tanpa merusak basis kode yang ada.

Pikirkan tentang ini sebagai goto. Fakta bahwa bahasa atau IDE mendukung fitur tidak berarti bahwa itu harus digunakan setiap hari. Aturan StyleCop SA1124 jelas: Anda tidak boleh menggunakan wilayah.

Contohnya

Saat ini saya sedang melakukan review kode dari kode rekan kerja saya. Basis kode berisi banyak daerah, dan sebenarnya adalah contoh sempurna tentang cara tidak menggunakan kawasan dan mengapa daerah menyebabkan kode buruk. Berikut ini beberapa contohnya:

4 000 monster LOC:

Saya baru-baru ini membaca di suatu tempat di Programmers.SE bahwa ketika sebuah file mengandung terlalu banyak usings (setelah menjalankan perintah "Hapus Penggunaan yang Tidak Digunakan"), itu adalah pertanda baik bahwa kelas di dalam file ini melakukan terlalu banyak. Hal yang sama berlaku untuk ukuran file itu sendiri.

Saat meninjau kode, saya menemukan 4 000 file LOC. Tampaknya pembuat kode ini hanya menyalin-menyisipkan metode 15-baris yang sama ratusan kali, sedikit mengubah nama variabel dan metode yang disebut. Regex sederhana diizinkan untuk memotong file dari 4.000 LOC menjadi 500 LOC, hanya dengan menambahkan beberapa obat generik; Saya cukup yakin bahwa dengan refactoring yang lebih pintar, kelas ini dapat dikurangi menjadi beberapa lusin baris.

Dengan menggunakan daerah, penulis mendorong dirinya sendiri untuk mengabaikan fakta bahwa kode tidak mungkin untuk dipertahankan dan ditulis dengan buruk, dan sangat menduplikasi kode alih-alih memperbaikinya.

Wilayah “Do A”, Wilayah “Do B”:

Contoh bagus lainnya adalah metode inisialisasi monster yang hanya mengerjakan tugas 1, lalu tugas 2, lalu tugas 3, dll. Ada lima atau enam tugas yang sepenuhnya independen, masing-masing menginisialisasi sesuatu dalam kelas kontainer. Semua tugas itu dikelompokkan menjadi satu metode, dan dikelompokkan ke daerah.

Ini memiliki satu keuntungan:

  • Metodenya cukup jelas untuk dipahami dengan melihat nama-nama wilayah. Ini dikatakan, metode yang sama sekali refactored akan sejelas yang asli.

Masalahnya, di sisi lain, beragam:

  • Tidak jelas apakah ada ketergantungan antar daerah. Mudah-mudahan, tidak ada penggunaan kembali variabel; jika tidak, pemeliharaan bisa menjadi mimpi buruk bahkan lebih.

  • Metode itu hampir tidak mungkin untuk diuji. Bagaimana Anda dengan mudah tahu jika metode yang melakukan dua puluh hal sekaligus melakukannya dengan benar?

Wilayah bidang, wilayah properti, wilayah konstruktor:

Kode yang ditinjau juga berisi banyak wilayah yang mengelompokkan semua bidang bersama, semua properti bersama, dll. Ini memiliki masalah yang jelas: pertumbuhan kode sumber.

Ketika Anda membuka file dan melihat daftar besar bidang, Anda lebih cenderung untuk refactor kelas terlebih dahulu, kemudian bekerja dengan kode. Dengan daerah, Anda memiliki kebiasaan untuk menghancurkan barang-barang dan melupakannya.

Masalah lain adalah bahwa jika Anda melakukannya di mana-mana, Anda akan menemukan diri Anda membuat wilayah satu blok, yang tidak masuk akal. Ini sebenarnya adalah kasus dalam kode yang saya ulas, di mana ada banyak #region Constructor mengandung satu konstruktor.

Akhirnya, bidang, properti, konstruktor dll --- harus sudah dalam urutan . Jika ya dan cocok dengan konvensi (konstanta dimulai dengan huruf kapital, dll.), Sudah jelas di mana pada jenis elemen berhenti dan lainnya dimulai, jadi Anda tidak perlu secara eksplisit membuat daerah untuk itu.

291

Sungguh luar biasa bagi saya betapa banyak orang membenci daerah dengan penuh semangat!

Saya setuju sepenuhnya dengan begitu banyak keberatan mereka: Menyorong kode menjadi #region menyembunyikannya dari pandangan adalah hal yang buruk. Membagi kelas menjadi #regions ketika itu harus di refactored ke dalam kelas yang terpisah jelas merupakan kesalahan. Menggunakan sebuah #region untuk menanamkan informasi semantik yang berlebihan, yah, berlebihan.

Tetapi tidak satu pun dari hal-hal itu berarti bahwa ada sesuatu yang inheren salah dengan menggunakan wilayah dalam kode Anda! Saya hanya dapat berasumsi bahwa sebagian besar keberatan orang berasal dari bekerja di tim di mana orang lain cenderung menggunakan fitur IDE seperti ini tidak benar. Saya memiliki kemewahan untuk bekerja sendiri, dan saya menghargai cara daerah telah membantu mengatur alur kerja saya. Mungkin itu gangguan obsesif kompulsif saya, tapi saya tidak suka melihat banyak kode di layar saya sekaligus, tidak peduli seberapa rapi dan elegan tulisan itu. ke dalam wilayah logis memungkinkan saya untuk menutup kode yang saya tidak peduli bekerja pada kode yang saya jangan peduli. Saya tidak mengabaikan kode yang ditulis dengan buruk, tidak masuk akal untuk memperbaikinya lagi, dan organisasi "meta" tambahan bersifat deskriptif, daripada tak berarti.

Sekarang saya telah menghabiskan lebih banyak waktu bekerja di C++, pemrograman lebih langsung ke Windows API, saya mendapati diri saya berharap bahwa dukungan untuk daerah sama baiknya dengan C #. Anda bisa berargumen bahwa menggunakan pustaka GUI alternatif akan membuat kode saya lebih sederhana atau lebih jelas, sehingga menghilangkan kebutuhan untuk mengeluarkan suara kode yang tidak relevan dari layar, tapi saya punya alasan lain untuk tidak ingin melakukan itu. Saya cukup mahir dengan keyboard saya dan IDE bahwa memperluas/menciutkan kode yang dibagi menjadi beberapa daerah membutuhkan waktu kurang dari sepersekian detik. Waktu saya menghemat tenaga otak, mencoba membatasi fokus sadar saya hanya kode yang sedang saya kerjakan, lebih dari sepadan. Itu semua milik dalam satu kelas/file, tetapi tidak semua milik di layar saya pada saat yang sama.

Intinya adalah menggunakan #regions untuk memisahkan dan membagi secara logis kode Anda bukanlah hal yang buruk untuk dihindari. Seperti yang ditunjukkan Ed, ini bukan "bau kode". Jika kode Anda berbau, Anda dapat yakin bahwa itu bukan berasal dari daerah, melainkan dari kode apa pun yang Anda coba kubur di wilayah itu. Jika fitur membantu Anda menjadi lebih teratur, atau menulis kode yang lebih baik, maka saya katakan gunakan. Jika itu menjadi penghalang, atau Anda salah menggunakannya, maka stop menggunakannya. Jika yang terburuk menjadi yang terburuk, dan Anda dipaksa untuk bekerja di tim dengan orang-orang yang menggunakannya, maka hafal pintasan keyboard untuk mematikan kode yang menjabarkan: Ctrl+MCtrl+P. Dan berhenti mengeluh. Terkadang saya merasa ini adalah cara lain yang ingin dilihat oleh programmer yang "benar", "keras" untuk mencoba dan membuktikan diri. Anda tidak lebih baik menghindari daerah daripada menghindari pewarnaan sintaksis. Itu tidak membuat Anda menjadi pengembang yang lebih macho.

Semua itu dikatakan, daerah dalam metode hanya omong kosong belaka. Setiap kali Anda mendapati diri Anda ingin melakukan itu, Anda harus melakukan refactoring ke dalam metode terpisah. Tidak ada alasan.

115
Cody Gray

Pertama, saya tidak tahan istilah "kode bau" lagi. Ini digunakan terlalu sering dan sering kali dilemparkan oleh orang-orang yang tidak bisa mengenali kode yang baik jika itu menggigit mereka. Bagaimanapun ...

Saya pribadi tidak suka menggunakan banyak daerah. Itu membuatnya lebih sulit untuk mendapatkan kode, dan kode itulah yang saya tertarik. Saya suka daerah ketika saya memiliki sejumlah besar kode yang tidak perlu disentuh terlalu sering. Selain itu, mereka sepertinya menghalangi saya, dan daerah seperti "Metode Pribadi", "Metode Publik", dll. Hanya membuat saya gila. Mereka mirip dengan komentar varietas i++ //increment i.

Saya juga akan menambahkan bahwa penggunaan wilayah tidak bisa benar-benar menjadi "anti-pola" karena istilah itu biasanya digunakan untuk menggambarkan logika program/pola desain, bukan tata letak editor teks. Ini subjektif; gunakan apa yang cocok untuk Anda. Anda tidak akan pernah berakhir dengan program yang tidak dapat dipelihara karena terlalu sering menggunakan daerah, yang merupakan inti dari anti-pola. :)

70
Ed S.

Ya daerah adalah bau kode!

Saya akan senang melihat daerah dihapus dari kompiler sama sekali. Setiap pengembang datang dengan skema perawatan tidak berguna sendiri yang tidak akan pernah bernilai bagi programmer lain. Saya memiliki segalanya yang berkaitan dengan programmer yang ingin mendekorasi dan mempercantik bayi mereka, tidak ada hubungannya dengan nilai nyata.

Dapatkah Anda memikirkan satu contoh di mana Anda berpikir, "Ya ampun, saya berharap kolega saya telah menggunakan beberapa daerah di sini!"?

Meskipun saya dapat mengkonfigurasi IDE untuk secara otomatis memperluas semua wilayah, mereka masih membuat mata saya sakit dan mengurangi membaca kode yang sebenarnya.

Saya benar-benar tidak peduli jika semua metode publik saya dikelompokkan bersama atau tidak. Selamat Anda tahu perbedaan antara deklarasi variabel dan inisialisasi, tidak perlu menampilkannya dalam kode!

Perawatan berharga!

Selain itu jika file Anda perlu dan 'arsitektur informasi' melalui penggunaan wilayah, Anda mungkin ingin memerangi masalah inti: Kelas Anda terlalu besar! Memecahnya menjadi bagian-bagian yang lebih kecil jauh lebih bermanfaat dan, jika dilakukan dengan benar, menambah semantik/keterbacaan yang sebenarnya.

23
Joppe

Saya pribadi menggunakan daerah sebagai cara untuk mengelompokkan berbagai jenis metode atau bagian kode bersama-sama.

Jadi file kode mungkin terlihat seperti ini saat membukanya:

  • Properti Publik
  • Konstruktor
  • Simpan Metode
  • Edit Metode
  • Metode Pembantu Pribadi

Saya tidak menempatkan daerah dalam metode. IMHO itu adalah tanda bau kode. Saya pernah menemukan metode yang panjangnya lebih dari 1200 baris dan memiliki 5 wilayah berbeda di dalamnya. Itu adalah pemandangan yang menakutkan!

Jika Anda menggunakannya sebagai cara untuk mengatur kode Anda dengan cara yang akan membuat menemukan hal-hal lebih cepat untuk pengembang lain, saya tidak berpikir itu pertanda masalah. Jika Anda menggunakannya untuk menyembunyikan baris kode di dalam metode, saya akan mengatakan sudah waktunya untuk memikirkan kembali metode itu.

15
Tyanna

Menggunakan #region blok untuk membuat kelas yang sangat besar dapat dibaca biasanya merupakan tanda melanggar Prinsip Tanggung Jawab Tunggal. Jika mereka terbiasa mengelompokkan perilaku, maka itu juga kemungkinan bahwa kelas melakukan terlalu banyak (sekali lagi melanggar SRP).

Tetap berpegang pada garis pemikiran "bau kode", #region blok bukanlah bau kode dalam dan dari diri mereka sendiri tetapi sebaliknya mereka lebih "Febreze for code" di mana mereka mencoba untuk menyembunyikan bau. Sementara saya telah menggunakan mereka satu ton di masa lalu, ketika Anda mulai refactoring Anda mulai melihat lebih sedikit karena mereka akhirnya tidak banyak bersembunyi.

10
Austin Salonen

Kata kunci di sini adalah "bijaksana". Sulit membayangkan kasus di mana menempatkan suatu wilayah di dalam suatu metode adalah bijaksana; itu terlalu mungkin menyembunyikan kode dan kemalasan. Namun, mungkin ada alasan bagus untuk memiliki beberapa wilayah di sana-sini dalam kode seseorang.

Jika ada banyak dan banyak daerah, saya pikir itu adalah bau kode. Daerah sering merupakan petunjuk di tempat yang memungkinkan untuk refactoring di masa depan. Banyak daerah berarti seseorang tidak benar-benar pernah mengambil petunjuk itu.

Digunakan dengan bijaksana, mereka memberikan jalan tengah yang baik antara struktur kelas tunggal dengan banyak metode dan struktur banyak kelas dengan hanya beberapa metode di masing-masing. Mereka paling berguna ketika kelas mulai mendekati ke titik di mana ia harus dire-refour menjadi beberapa kelas, tetapi belum ada di sana. Dengan mengelompokkan metode terkait bersama, saya membuatnya mudah nanti untuk mengekstrak seperangkat metode terkait ke kelas mereka sendiri jika mereka terus bertambah jumlahnya. Misalnya, jika saya memiliki kelas yang mendekati 500 baris kode, kumpulan metode yang menggunakan 200 baris total kode yang dikumpulkan bersama di suatu wilayah mungkin merupakan bagian yang baik untuk direformasi entah bagaimana - dan wilayah lain dengan 100 baris kode di dalamnya metode mungkin juga menjadi target yang baik.

Cara lain yang saya suka gunakan daerah adalah untuk mengurangi salah satu efek negatif dari refactoring metode besar: Banyak metode kecil, ringkas, mudah digunakan kembali bahwa pembaca harus menggulir melalui untuk sampai ke metode lain yang sebagian besar tidak terkait. Suatu wilayah dapat menjadi cara yang bagus untuk meta-encapsulate suatu metode dan bantuannya bagi pembaca, sehingga seseorang yang bekerja dengan aspek kelas yang berbeda hanya dapat meruntuhkannya dan dengan cepat mengabaikan bagian kode itu. Tentu saja, ini hanya berfungsi jika wilayah Anda benar-benar terorganisasi dengan baik dan pada dasarnya digunakan sebagai cara lain untuk mendokumentasikan kode Anda.

Secara umum, saya menemukan daerah membantu saya mengatur diri saya, membantu "mendokumentasikan" kode saya, dan membantu saya menangkap tempat untuk memperbaiki lebih cepat daripada jika saya tidak menggunakan daerah.

5
Ethel Evans

Saya terutama menggunakan daerah untuk kelas server CRUD untuk mengatur berbagai jenis operasi. Bahkan saat itu, saya dengan senang hati bisa pergi tanpa mereka.

Jika digunakan secara luas, itu akan menaikkan bendera merah. Saya akan mencari kelas yang memiliki tanggung jawab terlalu banyak.

Dalam pengalaman saya, metode dengan ratusan baris kode jelas merupakan bau.

4
TaylorOtwell

Aturan praktis saya adalah: Jika Anda memiliki lebih dari 5 wilayah dalam file itu adalah bau kode

Yaitu, mungkin baik untuk menggambarkan bidang, metode, properti dan konstruktor, tetapi jika Anda mulai membungkus setiap metode lain di wilayah itu sendiri ada sesuatu yang sangat salah

..dan ya, saya sudah banyak proyek di mana itu terjadi, sering karena standar pengkodean yang buruk, pembuatan kode atau keduanya. Sudah lama cepat harus beralih semua garis besar di studio visual untuk mendapatkan gambaran yang baik dari kode.

4
Homde

REGIONAL MEMILIKI PENGGUNAANNYA

Saya telah menggunakannya secara pribadi untuk acara antarmuka "coding tangan" sebelum untuk windows membentuk aplikasi.

Namun pada pekerjaan saya, kami menggunakan generator kode untuk menangani SQL dan secara otomatis menggunakan wilayah untuk memilah jenis metode pilih, perbarui, hapus, dll.

Jadi sementara saya tidak sering menggunakannya, mereka baik-baik saja untuk menghapus potongan kode besar.

4
Ken

Jika Anda memiliki daerah DI kode Anda pasti memiliki masalah (kecuali kasus kode yang dihasilkan.) Menempatkan daerah dalam kode pada dasarnya mengatakan "refactor this."

Namun, ada beberapa kasus lain. Salah satu yang terlintas dalam benak saya adalah beberapa waktu yang lalu: Meja dengan beberapa ribu item yang sudah dihitung sebelumnya. Ini adalah deskripsi geometri, singkat dari kesalahan dalam tabel tidak akan pernah ada kesempatan untuk melihatnya. Tentu, saya bisa mendapatkan data dari sumber daya atau sejenisnya tetapi itu akan menghalangi menggunakan kompiler untuk membantu membuatnya mudah dibaca.

4
Loren Pechtel

Saya akan mengatakan itu adalah "bau kode."

Anti-pola umumnya merupakan masalah struktural mendasar dalam sebuah perangkat lunak, sedangkan wilayah, dengan sendirinya hanya menyebabkan perilaku yang menjengkelkan dalam editor. Menggunakan wilayah sebenarnya tidak secara inheren buruk, tetapi menggunakannya banyak, terutama untuk menyembunyikan potongan kode dapat menunjukkan ada masalah lain, independen dan lebih besar terjadi di tempat lain.

3
whatsisname

Pada proyek baru-baru ini, ada metode garis 1700 dengan beberapa daerah tertanam di dalamnya. Yang menarik adalah bahwa daerah-daerah membatasi tindakan yang berbeda yang dilakukan dalam metode tersebut. Saya dapat melakukan refactor -> ekstrak metode pada masing-masing daerah tanpa memengaruhi fungsionalitas kode.

Secara umum, daerah yang digunakan untuk menyembunyikan kode pelat ketel berguna. Saya akan menyarankan agar tidak menggunakan daerah untuk menyembunyikan properti, bidang, dan sejenisnya karena jika mereka terlalu sulit untuk dilihat saat bekerja di dalam kelas, itu mungkin merupakan tanda bahwa kelas harus lebih lanjut dipecah. Tetapi sebagai aturan keras, jika Anda menempatkan suatu wilayah dalam suatu metode, Anda mungkin lebih baik mengekstraksi metode lain yang menjelaskan apa yang terjadi daripada membungkus blok itu di suatu wilayah.

3
Michael Brown

Bisakah daerah digunakan dalam kode yang berkualitas baik? Mungkin. Saya yakin mereka, dalam banyak kasus. Namun, pengalaman pribadi saya membuat saya sangat curiga - saya telah melihat daerah hampir secara eksklusif disalahgunakan. Saya akan mengatakan bahwa saya letih, tetapi masih optimis.

Secara kasar saya dapat membagi kode menggunakan wilayah yang saya lihat sampai saat ini menjadi tiga kategori:

  • Kode dengan faktor buruk: Sebagian besar kode yang saya lihat menggunakan daerah sebagai alat anjak orang miskin. Sebagai contoh, kelas yang telah berkembang ke titik di mana masuk akal untuk mengkhususkannya untuk tujuan yang berbeda mungkin malah dibagi menjadi daerah yang terpisah, satu untuk setiap tujuan.

  • Kode ditulis menggunakan pustaka yang salah, dan terkadang bahasa yang salah, untuk domain masalah Seringkali, ketika seorang programmer tidak menggunakan set pustaka yang tepat untuk domain masalah, Anda akan melihat kode menjadi sangat verbose - dengan banyak fungsi pembantu kecil yang benar-benar bukan milik (mereka mungkin termasuk di perpustakaan mereka sendiri).

  • Kode ditulis oleh siswa atau lulusan baru. Beberapa program dan kursus tampaknya mencoba dan menanamkan siswa dengan penggunaan daerah untuk segala macam tujuan aneh. Anda akan melihat wilayah mengotori kode sumber ke titik di mana rasio tag wilayah terhadap baris kode berada dalam kisaran 1: 5 atau lebih buruk.

3
blueberryfields

Saya menggunakan wilayah hanya untuk satu hal (setidaknya saya tidak bisa memikirkan tempat lain yang saya gunakan): untuk mengelompokkan tes unit untuk suatu metode.

Saya biasanya memiliki satu kelas uji per kelas dan kemudian mengelompokkan tes unit untuk setiap metode dengan menggunakan daerah yang memiliki nama metode. Tidak yakin apakah itu bau kode atau apa, tetapi karena ide dasarnya adalah bahwa unit test tidak perlu diubah kecuali mereka rusak karena ada sesuatu dalam kode yang berubah, membuat saya lebih mudah untuk menemukan semua tes untuk metode tertentu cukup cepat.

Saya mungkin pernah menggunakan daerah untuk mengatur kode di masa lalu, tapi saya tidak ingat kapan terakhir kali saya melakukannya. Saya tetap berpegang pada daerah saya di kelas-kelas unit test.

3
Anne Schuessler

Saya percaya ini adalah pola anti dan terus terang berpikir mereka harus dihilangkan. Tetapi jika Anda berada dalam situasi yang tidak menguntungkan bekerja di tempat di mana mereka standar Visual Studio menawarkan alat yang luar biasa untuk meminimalkan jumlah yang Anda ingin muntah setiap kali Anda melihat wilayah I Hate #Regions

Plugin ini akan max ukuran font daerah sangat kecil. Mereka juga akan diperluas sehingga Anda tidak perlu menekan ctr + m + l untuk membuka semua wilayah. Itu tidak memperbaiki bentuk kanker kode ini tetapi itu membuatnya tertahankan.

2
DeadlyChambers

Wilayah adalah ide organisasi yang bagus, tetapi gagal memperhitungkan beberapa kecenderungan pengembang yang ingin mengkategorikan semuanya, dan umumnya tidak perlu menurut kebanyakan praktik modern OOP ... itu adalah "bau" , dalam arti bahwa menggunakannya sering menunjukkan bahwa kelas/metode Anda terlalu besar dan harus di-refactored, karena Anda kemungkinan melanggar "S" dari prinsip-prinsip SOLID ... tetapi seperti bau, itu tidak selalu berarti ada sesuatu yang buruk.

Wilayah melayani lebih banyak tujuan dalam kode fungsional daripada kode berorientasi objek, IMO, di mana Anda memiliki fungsi panjang dari data sekuensial yang masuk akal untuk dipecah, tetapi ada kalanya saya secara pribadi menggunakannya dalam c #, dan mereka hampir selalu fokus pada kode yang tidak perlu/ingin Anda lihat. Bagi saya, ini biasanya konstanta string SQL mentah dalam basis kode yang digunakan untuk NPoco atau variannya. Kecuali Anda benar-benar peduli bagaimana data datang untuk mengisi objek POCO melalui ORM Anda, ini sama sekali tidak berguna untuk dilihat ... dan jika Anda benar-benar peduli, hei, cukup rentangkan wilayah dan BAM! 150+ baris dari beberapa query SQL yang rumit untuk kesenangan Anda menonton.

0
Jeremy Holovacs

Saya menggunakan wilayah untuk memuat setiap kombinasi visibilitas dan tipe anggota. Jadi semua fungsi pribadi masuk ke suatu daerah, dll.

Alasan saya melakukan ini bukan karena saya bisa melipat kode. Itu karena saya memiliki editor saya sehingga saya dapat memasukkan, katakanlah, referensi ke proxy:

#region "private_static_members"
 /// <summary>
 /// cache for LauncherProxy
 /// </summary>
private static LauncherProxy _launcherProxy;
#endregion

#region "protected_const_properties"
protected LauncherProxy LauncherProxy{
  get{
    if(_launcherProxy==null) {
      if (!God.Iam.HasProxy(LauncherProxy.NAME)) {
        God.Iam.RegisterProxy(new LauncherProxy());
      }
      _launcherProxy=God.Iam.Proxy(LauncherProxy.NAME) as LauncherProxy;
    }
    return _launcherProxy;
  }
}
#endregion

ke dalam kode dan masing-masing bagian rapi dimasukkan ke dalam wilayah yang tepat.

Dalam hal ini makro akan menganalisis proyek saya, beri saya kotak daftar proksi dan menyuntikkan kode yang saya inginkan. Kursor saya bahkan tidak bergerak.

Pada awal pembelajaran C # saya telah mempertimbangkan penggunaan daerah untuk menjaga kesamaan, tetapi itu adalah untung-untungan karena itu bukan hubungan satu-ke-satu setiap saat. Siapa yang ingin khawatir tentang anggota yang digunakan oleh dua daerah, atau bahkan mulai memecah hal-hal dengan persyaratan tersebut.

Satu-satunya jenis pemisahan lainnya adalah metode - saya akan membagi metode menjadi Perintah, Fungsi, dan Penangan, jadi saya akan memiliki wilayah untuk Perintah publik, pribadi, dll.

Ini memberi saya granularity, tetapi konsisten, tegas granularity saya dapat mengandalkan.

0
Mark

Wilayah adalah ekspresi preprosesor - dengan kata lain mereka diperlakukan seperti komentar dan pada dasarnya diabaikan oleh kompiler. Mereka murni alat visual yang digunakan dalam Visual Studio. Karenanya #region sebenarnya bukan bau kode, karena itu bukan kode. Bau kode bukan metode 800 baris yang memiliki banyak tanggung jawab yang berbeda tertanam di dalam dll. Jadi jika Anda melihat 10 wilayah dalam satu metode - itu mungkin digunakan untuk menyembunyikan bau kode. Setelah mengatakan bahwa saya telah melihat mereka menggunakan sangat efektif untuk membuat kelas lebih menyenangkan mata dan lebih dinavigasi - dalam kelas yang ditulis dengan sangat baik dan terstruktur juga!

0
BKSpurgeon