it-swarm-tr.com

#Regions bir antipattern veya kod kokusu mu?

C # #region/#endregion anahtar sözcüklerini düzenleyicide katlanabilir yapmak için anahtar kelimeler. Ne zaman bunu yapsam da, muhtemelen diğer sınıflara veya yöntemlere yeniden yerleştirilebilecek büyük kod parçalarını gizlemek için yapıyorum. Örneğin, sadece yönetilebilir hale getirmek için 3 veya 4 bölgeli 500 satır kod içeren yöntemler gördüm.

Bölgelerin mantıklı kullanımı bir sorun işareti midir? Bana öyle geliyor.

274
Craig

Kod kokusu, tasarımda hata sayısını potansiyel olarak artıracak bir sorun olduğunu gösteren bir semptomdur: bu bölgeler için geçerli değildir, ancak bölgeler uzun yöntemler gibi kod kokuları oluşturmaya katkıda bulunabilir.

Dan beri:

Bir anti-desen (veya antipattern), sosyal veya ticari operasyonlarda veya yazılım mühendisliğinde yaygın olarak kullanılabilen, ancak uygulamada etkisiz ve/veya ters etkili bir modeldir.

bölgeler are anti-paternler. Kodun kalitesini veya okunabilirliğini arttırmayan, hata sayısını azaltmayan ve kodu sadece refactor için daha karmaşık hale getirebilecek daha fazla çalışma gerektirirler.

Yöntemlerin içinde bölgeleri kullanmayın; yerine refactor

Yöntemler kısa olmalıdır. Bir yöntemde yalnızca on satır varsa, muhtemelen diğer beşte çalışırken beş tanesini gizlemek için bölgeler kullanmazsınız.

Ayrıca, her yöntem bir ve bir tek şey yapmalıdır. Diğer yandan bölgeler farklı şeyleri ayırmak. Metodunuz A, sonra B yaparsa, iki bölge oluşturmak mantıklıdır, ancak bu yanlış bir yaklaşımdır; bunun yerine, yöntemi iki ayrı yönteme yeniden yansıtmalısınız.

Bu durumda bölgelerin kullanılması da yeniden düzenlemeyi daha zor hale getirebilir. Sahip olduğunuzu hayal edin:

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
}

İlk bölgeyi ikinciye konsantre olmak için çökmek sadece riskli değildir: akışı durdurma istisnasını kolayca unutabiliriz (bunun yerine return ile bir koruma maddesi olabilir, bu da tespit edilmesi daha da zor), ancak kodun bu şekilde yeniden düzenlenmesi gerekirse de bir sorun olurdu:

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
}

Şimdi, bölgeler bir anlam ifade etmiyor ve muhtemelen birincideki koda bakmadan ikinci bölgedeki kodu okuyamaz ve anlayamazsınız.

Bazen gördüğüm başka bir durum da:

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
}

Argüman doğrulama onlarca LOC'yi yaymaya başladığında bölgeleri kullanmak cazip gelebilir, ancak bu sorunu çözmenin daha iyi bir yolu vardır: .NET Framework kaynak kodu tarafından kullanılan:

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)
{
    ...
}

Gruplamak için yöntemler dışındaki bölgeleri kullanma

  • Bazı kişiler bunları alanları, özellikleri vb. Bir araya getirmek için kullanır. Bu yaklaşım yanlış: kodunuz StyleCop uyumluysa, alanlar, özellikler, özel yöntemler, yapıcılar vb. Zaten birlikte gruplandırılır ve bulması kolay. Değilse, kod tabanınızda tekdüzelik sağlayan kurallar uygulamayı düşünmeye başlama zamanı.

  • Diğer insanlar bölgeleri benzer varlıkları bir sürü saklamak için kullanırlar. Örneğin, yüz alanı olan bir sınıfınız olduğunda (yorumları ve boşlukları sayarsanız en az 500 satır kod oluşturur), bu alanları bir bölgeye koymanız, daraltmanız ve unutmanız cazip olabilir. Yine, yanlış yapıyorsunuz: bir sınıftaki birçok alanla, miras kullanmayı veya nesneyi birkaç nesneye ayırmayı daha iyi düşünmelisiniz.

  • Son olarak, bazı kişiler bölgeleri ilgili şeyleri bir araya getirme: temsilci ile bir olay veya IO ile ilgili diğer yöntemlerle ilgili bir yöntem, İlk durumda, bakımı, okunması ve anlaşılması zor bir karmaşa haline gelir.İkinci durumda, muhtemelen birkaç sınıf oluşturmak daha iyi bir tasarım olacaktır.

Bölgeler için iyi bir kullanım var mı?

Hayır. Eski bir kullanım vardı: oluşturulan kod. Yine de, kod oluşturma araçları bunun yerine kısmi sınıfları kullanmak zorundadır. C # 'ın bölge desteği varsa, bunun nedeni çoğunlukla bu eski kullanımdır ve artık kodlarında çok fazla kişi bölge kullandığından, mevcut kod tabanlarını bozmadan bunları kaldırmak imkansız olacaktır.

Bunu goto olarak düşünün. Dilin veya IDE bir özelliği desteklemesi, günlük olarak kullanılması gerektiği anlamına gelmez. StyleCop SA1124 kuralı açık: bölgeleri kullanmamalısınız. Asla.

Örnekler

Şu anda iş arkadaşımın kodunun kod incelemesini yapıyorum. Kod tabanı birçok bölge içeriyor ve aslında hem bölgelerin nasıl kullanılmayacağına hem de bölgelerin neden kötü koda yol açtığına dair mükemmel bir örnek. İşte bazı örnekler:

4000 LOC canavarı:

Son zamanlarda bir yerde çok fazla usings ("Kullanılmayan Kullanımları Kaldır" komutunu uyguladıktan sonra) içerdiğinde, bu dosyanın içindeki sınıfın çok fazla şey yaptığının iyi bir işaret olduğunu okudum. Aynı şey dosyanın boyutu için de geçerlidir.

Kodu incelerken, 4.000 LOC dosyasıyla karşılaştım. Bu kodun yazarının aynı 15 satır yöntemini yüzlerce kez kopyalayıp yapıştırdığı, değişkenlerin adlarını ve çağrılan yöntemi hafifçe değiştirdiği ortaya çıktı. Basit bir normal ifade, sadece birkaç jenerik ekleyerek dosyayı 4.000 LOC'dan 500 LOC'a kırpmaya izin verdi; Daha zekice bir yeniden düzenleme ile bu sınıfın birkaç düzine çizgiye indirilebileceğinden eminim.

Bölgeleri kullanarak yazar, kodun sürdürülmesinin imkansız ve kötü yazılmış olduğu gerçeğini görmezden gelmeye ve kodu yeniden düzenlemek yerine kodu çoğaltmaya teşvik etti.

Bölge “Do A”, Bölge “Do B”:

Bir başka mükemmel örnek, sadece görev 1'i, sonra görev 2'yi, sonra görev 3'ü vb. Gerçekleştiren bir canavar başlatma yöntemiydi. Her biri bir konteyner sınıfında bir şey başlatan beş veya altı görev vardı. Tüm bu görevler tek bir yöntemde gruplandırıldı ve bölgeler halinde gruplandı.

Bunun bir avantajı vardı:

  • Yöntem, bölge adlarına bakarak anlaşılması oldukça açıktı. Bununla birlikte, bir kez yeniden düzenlenmiş olan aynı yöntem orijinal kadar açık olacaktır.

Öte yandan konular birden fazla idi:

  • Bölgeler arasında bağımlılıklar olup olmadığı belli değildi. Umarım değişkenlerin yeniden kullanımı söz konusu değildir; Aksi takdirde, bakım daha bir kabus olabilir.

  • Yöntemin test edilmesi neredeyse imkansızdı. Bir seferde yirmi şeyi yapan yöntemin bunları doğru bir şekilde yapıp yapmadığını nasıl anlarsınız?

Alanlar bölgesi, özellikler bölgesi, yapıcı bölgesi:

Gözden geçirilen kod aynı zamanda tüm alanları bir araya getiren birçok bölgeyi, tüm özellikleri bir arada, vb. İçeriyordu. Bunun bariz bir sorunu vardı: kaynak kodu büyümesi.

Bir dosyayı açıp çok geniş bir alan listesi gördüğünüzde, önce sınıfı yeniden düzenleme, ardından kodla çalışma eğiliminiz artar. Bölgelerle, şeyleri daraltma ve unutma alışkanlığı kazanırsınız.

Başka bir sorun, her yerde yaparsanız, kendinizi mantıklı olmayan tek bloklu bölgeler oluştururken bulacaksınız. Bu aslında bir kurucu içeren çok sayıda #region Constructor Olduğu gözden geçirdiğim kodda böyleydi.

Son olarak, alanlar, özellikler, yapıcılar vb. zaten sıralı olmalıdır . Eğer öyleyse ve sözleşmelerle eşleşiyorsa (büyük harfle başlayan sabitler vb.), Öğelerin türünün nerede durduğu ve diğerlerinin başladığı zaten açıktır, bu nedenle bunun için açıkça bölgeler oluşturmanıza gerek yoktur.

291

Kaç kişi nefret bölgeleri bu kadar tutkuyla inanılmaz!

İtirazlarının çoğuna tamamen katılıyorum: Bir #region görünümden gizlemek kötü bir şeydir. Bir sınıfı #regions ayrı sınıflara ne zaman yeniden düzenlenmesi gerektiği açıkça bir hatadır. Bir #region gereksiz semantik bilgi gömmek için, gereksizdir.

Ancak bunların hiçbiri, kodunuzdaki bölgeleri kullanmanın yanlış olduğu bir şey olduğu anlamına gelmez doğasında! Sadece çoğu insanın itirazlarının, diğerlerinin IDE bu gibi özellikleri yanlış kullanma eğiliminde olduğu takımlarda çalışmasından kaynaklandığını varsayabilirim: Ben kendi başıma birincil çalışma lüksüne sahibim ve takdir ediyorum Belki de obsesif kompulsif bozukluğumdur, ancak ekranımda ne kadar düzgün ve zarif bir şekilde yazılmış olursa olsun bir grup kodu görmek istemiyorum. mantıksal bölgelere ben yok I yapmak umurumda kod üzerinde çalışmak için bakım kodu daraltmak sağlar. Kötü yazılmış kodu görmezden gelmiyorum, daha fazla olduğundan daha fazla yeniden düzenleme mantıklı değil ve ek "meta" organizasyon anlamsız yerine açıklayıcı.

Şimdi C++ 'da çalışmak için daha fazla zaman harcadığım için, Windows API'ya daha doğrudan programlama yaptım, bölgeler için desteğin C # için olduğu kadar iyi olmasını diliyorum. Alternatif bir GUI kitaplığı kullanmanın kodumu daha basit veya daha açık hale getireceğini ve böylece ekrandan alakasız kod gürültüsü alma ihtiyacını ortadan kaldıracağını iddia edebilirsiniz, ancak bunu yapmak istememek için başka nedenlerim var. Klavyemle yeterince yetkinim ve IDE bölgeleri alt bölümlere ayrılmış kodun genişletilmesi/daraltılması bir saniyeden daha kısa sürüyor. Beyin gücünde tasarruf ettiğim zaman, bilinçli odağımı sınırlamaya çalışıyorum sadece şu anda üzerinde çalıştığım koda değmez, hepsi tek bir sınıfa/dosyaya ait, ama hepsi aynı zamanda ekranıma ait değil.

Mesele şu ki #regions kodunuzu ayırmak ve mantıksal olarak bölmek her ne pahasına olursa olsun kaçınılması kötü bir şey değildir. Ed'in belirttiği gibi, bu bir "kod kokusu" değildir. Kodunuz kokuyorsa, bunun bölgelerden gelmediğinden emin olabilirsiniz, bunun yerine bu bölgelere gömmeye çalıştığınız herhangi bir koddan emin olabilirsiniz. Bir özellik daha organize olmanıza veya daha iyi kod yazmanıza yardımcı olursa, kullan diyorum. Bir engel haline gelirse veya yanlış kullandığınızı fark ederseniz, durdur kullanarak. En kötüsü en kötüye gelirse ve onu kullanan kişilerle bir ekip üzerinde çalışmak zorunda kalırsanız, kod özetini kapatmak için klavye kısayolunu ezberleyin: Ctrl+MCtrl+P. Ve şikayet etmeyi bırak. Bazen bunun "gerçek", "hardcore" programcılar olarak görülmek isteyenlerin kendilerini denemeyi ve kanıtlamayı sevdikleri başka bir yol olduğunu hissediyorum. Sözdizimi renklendirmekten kaçınmaktan daha iyi bölgelerden kaçınamazsınız. Seni daha maço geliştirici yapmaz.

Tüm bunlar söyleniyor, bölgeler içinde bir yöntem sadece saçmalık. Kendinizi bunu yapmak istediğinizde bulduğunuzda, ayrı bir yönteme yeniden bakmanız gerekir. Bahane yok.

115
Cody Gray

İlk uzakta, artık "kod kokusu" terimi dayanamıyorum. Çok sık kullanılır ve çoğu zaman iyi kodu tanımayan insanlar tarafından atılır. Neyse...

Ben şahsen pek çok bölge kullanmayı sevmiyorum. Bu kodu almak zorlaştırır ve kod ben ilgilendiğim. Çok sık dokunulmasına gerek yok kod büyük bir yığın olduğunda bölgeleri seviyorum. Bunun dışında benim yoluma giriyor gibi görünüyorlar ve "Özel Yöntemler", "Genel Yöntemler" gibi bölgeler beni deli ediyor. Çeşitliliğin yorumlarına benziyorlar i++ //increment i.

Ayrıca, bu terimin bir metin düzenleyicisinin düzenini değil, program mantığını/tasarım desenlerini tanımlamak için yaygın olarak kullanıldığı için, bölgelerin kullanımının gerçekten bir "anti-desen" olamayacağını da ekleyeceğim. Bu özneldir; sizin için uygun olanı kullanın. Bölgelerin aşırı kullanımı nedeniyle hiçbir zaman sürdürülemez bir programla sonuçlanmayacaksınız, bu da anti-kalıpların hepsi hakkında. :)

70
Ed S.

Evet bölgeler bir kod kokusudur!

Derleyiciden tamamen ayrılmış bölgeleri gördüğüme sevindim. Her geliştirici, hiçbir zaman başka bir programcı için hiçbir zaman değerli olmayacak kendi anlamsız tımar düzeni ile gelir. Bebeklerini süslemek ve güzelleştirmek isteyen programcılar ile her şeyim var, gerçek bir değerle ilgisi yok.

"Tanrım, meslektaşımın burada bazı bölgeler kullanmasını diliyorum" diye bir örnek düşünebilir misin?

Benim IDE tüm bölgeleri otomatik olarak genişletecek şekilde yapılandırabilsem de, bunlar hala bir göz ağrısıydı ve gerçek kodu okumaktan mahrum bırakıyorlar.

Herkese açık yöntemlerimin bir araya getirilip birleştirilmemesi gerçekten daha az umurumda. Tebrikler, değişken bildirim ve başlatma arasındaki farkı biliyorsunuz, kodda göstermeye gerek yok!

Değersiz bakım!

Buna ek olarak, dosyanızın kullanılması ve bölgelerin kullanımı yoluyla 'bilgi mimarisi' gibi temel sorunla mücadele etmek isteyebilirsiniz: Sınıfınız çok büyük! Daha küçük parçalara bölmek çok daha faydalıdır ve düzgün bir şekilde yapıldığında gerçek anlambilim/okunabilirlik sağlar.

23
Joppe

Şahsen bölgeleri çeşitli yöntem türlerini veya kod parçalarını birlikte gruplandırmanın bir yolu olarak kullanıyorum.

Yani bir kod dosyası açıldıktan sonra şöyle görünebilir:

  • Kamusal Mülkler
  • Kurucular
  • Kaydetme Yöntemleri
  • Düzenleme Yöntemleri
  • Özel Yardımcı Yöntemler

Bölgeleri yöntemlerin içine koymam. Kod kokusunun bir işareti olan IMHO. Bir keresinde 1200 çizginin üzerinde bir yöntemle karşılaştım ve içinde 5 farklı bölge vardı. Korkunç bir manzaraydı!

Kodunuzu diğer geliştiriciler için işleri daha hızlı bulmanızı sağlayacak şekilde organize etmenin bir yolu olarak kullanıyorsanız, bunun bir sorun işareti olduğunu düşünmüyorum. Bir yöntemin içindeki kod satırlarını gizlemek için kullanıyorsanız, o yöntemi yeniden düşünmenin zamanı geldiğini söyleyebilirim.

15
Tyanna

Çok büyük bir sınıfı okunabilir yapmak için #region Bloklarını kullanmak, genellikle Tek Sorumluluk İlkesini ihlal ettiğinin bir işaretidir. Davranışı gruplandırmak için kullanılıyorlarsa, o zaman muhtemelen sınıfın çok fazla şey yaptığını (bir kez daha SRP'yi ihlal ettiğini).

"Kod kokusu" düşünce çizgisine sadık kalarak, #region Blokları kendilerinde kod kokusu değil, kokuları gizlemeye çalıştıkları için daha çok "Kod için Febreze" dir. Onları geçmişte bir ton kullandım, ancak yeniden düzenlemeye başladığınızda daha az görmeye başladınız çünkü çok fazla saklanmıyorlar.

10
Austin Salonen

Buradaki anahtar kelime "mantıklı" dır. Bir bölgeyi bir yöntemin içine sokmanın mantıklı olduğu bir durumu hayal etmek zor; kod gizleme ve tembellik olma ihtimali çok yüksek. Bununla birlikte, burada ve orada birkaç kişinin olması için kişinin kodunda iyi nedenler olabilir.

Çok sayıda bölge varsa, bunun bir kod kokusu olduğunu düşünüyorum. Bölgeler genellikle gelecekteki yeniden düzenleme için olası bir yere dair bir ipucudur. Birçok bölge, birisinin aslında ipucu almadığı anlamına gelir.

Doğru bir şekilde kullanıldığında, birçok yöntemle tek bir sınıfın yapısı ile her birinde sadece birkaç yöntemle birçok sınıfın yapısı arasında iyi bir orta zemin sağlarlar. Bir sınıf, birden fazla sınıfa yeniden yerleştirilmesi gereken noktaya yaklaşmaya başladığında en yararlıdır, ancak henüz orada değildir. İlgili yöntemleri birlikte gruplandırarak, sayıları artmaya devam ederse kendi yöntemlerine bir dizi ilgili yöntemi çıkarmayı kolaylaştırıyorum. Örneğin, 500 kod satırına yaklaşan bir sınıfım varsa, bir bölgede bir araya toplanan toplam 200 satır kod kullanan bu yöntem kümesi muhtemelen bir şekilde yeniden düzenleme yapmak için iyi bir parçadır - ve 100 satır kodlu diğer bölge yöntemler de iyi bir hedef olabilir.

Bölgeleri kullanmaktan başka bir yol, büyük bir yöntemi yeniden düzenlemenin olumsuz etkilerinden birini azaltmaktır: Bir okuyucunun çoğunlukla ilgisiz başka bir yönteme ulaşmak için kaydırması gereken çok sayıda küçük, özlü, kolayca yeniden kullanılan yöntem. Bir bölge, bir yöntemi ve yardımcılarını okuyucular için meta-kapsül haline getirmenin güzel bir yolu olabilir, böylece sınıfın farklı bir yönüyle çalışan biri bunları daraltabilir ve kodun bu bölümünü hızlı bir şekilde işten çıkarabilir. Tabii ki, bu sadece bölgeleriniz gerçekten iyi organize edilmişse ve kodunuzu belgelemek için başka bir yol olarak kullanılıyorsa işe yarar.

Genel olarak, bölgelerin kendimi düzenli tutmama, kodumu "belgelemem" ve bölgeler kullanmamaya göre çok daha erken bir zamanda yeniden odaklanabileceğim yerleri yakalamama yardımcı olduğunu düşünüyorum.

5
Ethel Evans

Çoğunlukla çeşitli işlem türlerini düzenlemek için CRUD sunucu sınıfları için bölgeler kullanıyorum. O zaman bile, onlarsız memnuniyetle gidebilirim.

Çok kullanılırsa, kırmızı bir bayrak kaldırır. Çok fazla sorumluluğu olan sınıfları ararım.

Deneyimlerime göre, yüzlerce satırlı bir yöntem kesinlikle bir kokudur.

4
TaylorOtwell

Temel kuralım: Bir dosyada 5'ten fazla bölge varsa kod kokusudur

Yani, alanı, yöntemleri, özellikleri ve yapıcıları tanımlamak iyi olabilir, ancak diğer her yöntemi kendi bölgesinde bir bölgeye sarmaya başlıyorsanız, bir şey yanlış

..ve evet, çoğu zaman kötü kodlama standartları, kod üretimi ya da her ikisi yüzünden böyle birçok projede bulundum. Kodun iyi bir genel görünümünü elde etmek için görsel stüdyoda tüm anahatları açıp kapatmak zorunda kalan eski hızlı.

4
Homde

BÖLGELERİN KULLANIMI VAR

Onları daha önce Windows form uygulamaları için "el kodlaması" arayüz olayları için kullandım.

Ancak benim işimde, SQL'i işlemek için bir kod üreteci kullanıyoruz ve otomatik olarak bölgeleri seç, güncelle, sil, vb. Yöntemlerini sıralamak için kullanıyor.

Bu yüzden sık sık kullanmama rağmen, büyük kod parçalarını kaldırmak için gayet iyi.

4
Ken

Bölgeleriniz [~ # ~] kodunda [~ # ~] varsa, kesinlikle bir sorununuz var demektir (oluşturulan kodun durumunu engelleme.) Bölgeleri koda koymak temelde "bunu yeniden düzenleme" der.

Ancak, başka durumlar da var. Bir süre önce aklıma gelen biri: İçinde birkaç bin önceden hesaplanmış kalem bulunan bir tablo. Bu, geometrinin bir açıklamasıdır, tabloda bir hata olmaması, ona bakmak için asla bir fırsat olmayacaktır. Elbette, verileri bir kaynaktan veya benzerinden alabilirdim, ancak bu, okumayı kolaylaştırmak için derleyiciyi kullanmayı engelleyecektir.

4
Loren Pechtel

Ben bir "kod kokusu" olduğunu söyleyebilirim.

Anti-paternler genellikle bir yazılım parçasındaki temel yapısal problemlerdir, oysa bölgeler tek başlarına bir editörde iğrenç bir davranışa neden olur. Bölgeleri kullanmak aslında doğası gereği kötü değildir, ancak özellikle kod parçalarını gizlemek için çok fazla kullanmak başka yerlerde, bağımsız ve daha büyük sorunların olduğunu gösterebilir.

3
whatsisname

Son zamanlarda yapılan bir projede, içinde birkaç bölge bulunan 1700 hat yöntemi vardı. İlginç olan, bölgelerin yöntem içinde yapılan farklı eylemleri göstermesidir. Kodun işlevselliğini etkilemeden her bir bölgede bir refactor -> ayıklama yöntemi yapabildim.

Genel olarak, kazan plakası kodunu gizlemek için kullanılan bölgeler yararlıdır. Özellikleri, alanları ve benzerlerini gizlemek için bölgeleri kullanmayı önermeliyim çünkü sınıf içinde çalışırken bakmak için çok uygunsuzlarsa, muhtemelen sınıfın daha da parçalanması gerektiğinin bir işaretidir. Ancak zor bir kural olarak, bir bölgeyi bir yönteme koyarsanız, muhtemelen o bloğu bir bölgeye sarmaktan ne olduğunu açıklayan başka bir yöntem çıkarmanız daha iyi olur.

3
Michael Brown

Bölgeler kaliteli kodda kullanılabilir mi? Muhtemelen. Bahse girerim, çoğu durumda. Ancak, kişisel deneyimim beni çok şüpheli bırakıyor - bölgelerin neredeyse tamamen yanlış kullanıldığını gördüm. Yorgun olduğumu söyleyebilirim, ama yine de iyimserim.

Kabaca bugüne kadar gördüğüm bölge kodunu üç kategoriye ayırabilirim:

  • Kötü faktörlü kod: Gördüğüm kodun çoğu bölgeleri fakir bir adamın faktoring aracı olarak kullanıyor. Örneğin, farklı amaçlar için uzmanlaşmanın mantıklı olduğu noktaya kadar büyüyen bir sınıf, bunun yerine her amaç için bir tane olmak üzere ayrı bölgelere ayrılabilir.

  • Sorunlu etki alanı için yanlış kitaplıklar ve bazen yanlış dil kullanılarak yazılmış kod Genellikle, bir programcı sorun etki alanı için doğru kitaplık kümesini kullanmadığında, kodun inanılmaz derecede ayrıntılı hale geldiğini görürsünüz - çok sayıda küçük yardımcı işlevle gerçekten ait değiller (muhtemelen kendi kütüphanelerine aittirler).

  • Öğrenciler veya yeni mezunlar tarafından yazılan kod. Bazı programlar ve dersler, öğrencileri her türlü garip amaç için bölgelerin kullanımını teşvik etmeye çalışıyor. Kaynak kodu, bölge etiketlerinin kod satırlarına oranının 1: 5 veya daha kötü olduğu noktaya kadar kirleten bölgeleri görürsünüz.

3
blueberryfields

Bölgeleri yalnızca bir şey için kullanıyorum (en azından bunları kullandığım diğer yerleri düşünemiyorum): bir yöntem için birim testleri gruplandırmak.

Genellikle sınıf başına bir test sınıfı var ve daha sonra yöntem adı olan bölgeleri kullanarak her yöntem için birim sınamaları gruplandırın. Kod kokusu veya başka bir şey olup olmadığından emin değilim, ancak temel fikir, birim testlerin, koddaki bir şey değiştiği için kırılmadıkça değişmesi gerekmediğinden, belirli bir yöntem için tüm testleri bulmamı kolaylaştırıyor oldukça hızlı.

Geçmişte kod düzenlemek için bölgeler kullanmış olabilirim, ancak son yaptığım zamanı hatırlayamıyorum. Yine de birim test derslerinde bölgelerime bağlı kalıyorum.

3
Anne Schuessler

Ben bir anti-desen olduğuna inanıyorum ve açıkçası ortadan kaldırılması gerektiğini düşünüyorum. Ama standart oldukları bir yerde çalışmak talihsiz bir durumda iseniz Visual Studio bir bölge her gördüğünüzde kusmak istediğiniz miktarı en aza indirmek için harika bir araç sunar I nefret #Bölgeler

Bu eklenti, gerçekten küçük bölgelerin yazı tipi boyutunu maks. Ayrıca tüm bölgeleri açmak için ctr + m + l tuşlarına basmanıza gerek kalmayacak şekilde genişletilirler. Bu kod kanseri formunu düzeltmez, ancak katlanılabilir kılar.

2
DeadlyChambers

Bölgeler şık bir kurumsal fikirdi, ancak her şeyi aşırı kategorize etmek isteyen bazı geliştirici eğilimlerini hesaba katmadı ve çoğu modern güne göre genellikle gereksizdi OOP uygulamalar ... bunlar bir "koku" , bunları kullanmanın genellikle sınıfınızın/yönteminizin çok büyük olduğunu ve yeniden hesaplanması gerektiğini gösterir, çünkü SOLID ilkeleri ... “gibi” koku, mutlaka bir şeylerin kötü gittiği anlamına gelmez.

Bölgeler, parçalamak için mantıklı olan uzun sıralı veri işlevlerine sahip olduğunuz nesne yönelimli kod, IMO yerine işlevsel kodda daha fazla amaca hizmet eder, ancak bunları kişisel olarak c #'da kullandığım zamanlar olmuştur ve neredeyse her zaman Bakmanız gerekmeyen/bakmak istemediğiniz koda odaklanın. Benim için bunlar genellikle NPoco veya varyantları için kullanılan kod tabanındaki ham SQL dizesi sabitleriydi. Verilerin POCO nesnesini ORM'niz aracılığıyla doldurmaya gerçekten önem vermedikçe, bunlara bakmak tamamen anlamsızdı ... ve umursarsanız, hey, bölgeyi genişletin ve BAM! 150+ satır izleme keyfi için bazı karmaşık SQL sorgusu.

0
Jeremy Holovacs

Görünürlük ve üye türünün her bir kombinasyonunu içeren bölgeleri kullanıyorum. Böylece tüm özel işlevler bir bölgeye vs. girer.

Bunu yapmamın nedeni kodu katlayabilmem. Bunun nedeni, bir proxy'ye bir başvuru ekleyebilmem için editörümün betiği olmasıdır:

#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

ve her bir parçanın düzgün bir şekilde uygun bölgeye yerleştirilmesini sağlayın.

Bu durumda makro projemi analiz eder, bana bir vekil listesi verir ve istediğim kodunu enjekte eder. İmlecim bile hareket etmiyor.

C # öğrenmesinin başlangıcında, ortaklıkları bir arada tutmak için bölgelerin kullanımını düşünmüştüm, ancak bu her zaman bire bir ilişki olmadığı için bir hit ve özledim önerisidir. İki bölge tarafından kullanılan bir üyeyi korkutmak, hatta bu şartlarda işleri parçalamak isteyen.

Diğer tek ayırma türü yöntemler- Komutlar, İşlevler ve İşleyiciler içine yöntemleri ayıracağım, bu yüzden genel, özel vb. Komutlar için bir bölgem olacaktı.

Bu bana ayrıntı düzeyini veriyor, ancak tutarlı, kesin güvenebileceğim ayrıntı düzeyi.

0
Mark

Bölgeler önişlemci ifadeleridir - başka bir deyişle, yorum gibi ele alınır ve temel olarak derleyici tarafından yoksayılır. Bunlar tamamen Visual Studio'da kullanılan görsel bir araçtır. Bu nedenle #region gerçekten bir kod kokusu değildir, çünkü sadece kod değildir. Kod kokusu daha ziyade içine yerleştirilmiş birçok farklı sorumluluğu olan 800 hat yöntemidir. Yani bir yöntemde 10 bölge görürseniz - muhtemelen bir kod kokusunu gizlemek için kullanılır. Çok iyi yazılmış ve yapılandırılmış bir sınıfta da bir sınıfı göze daha hoş ve daha gezilebilir yapmak için son derece etkili kullandıklarını söylemiştim!

0
BKSpurgeon