Kod biçimlendirme: Sınıf dosyasındaki çağrı hiyerarşisine dayalı işlevleri düzenleme?

Bob Martin "Temiz kod" dan bir öneri başımı kaşıyor .. "Eğer bir kez fonksiyon başka çağırırsa, onlar dikey olarak yakın olmalı ve arayan callee üstünde olmalıdır"

Şimdiye kadar, sınıf üyelerini türe (özellikler, ctorlar, işlevler) ve görünürlüğe (genel / prot. / Özel) göre gruplayan .Net yönergelerine az çok bağlı kaldım. İpucu ilk başta sorun gibi görünüyor .. ama "sadece işe yarayabilir". Şahsen bu düzeni sevdiğim durumlarla karşılaştım - doğru çağrı zincirindeyken detaylarını incelemek daha kolay.

Bahşiş arkasındaki fikir kulağa hoş geliyor ama "bu sınıfın genel arayüzüne bakayım" gibi diğer senaryolar daha da kötüleşebilir. Belki Bob Amca küçük sınıflar ve görüntüleme türleri için IDE desteği kullanıyor ...

Bunu uzun süre deneyen var mı?

Güncelleme: Kod pasajı hazır gibi görünüyor

class SomeType()
{
  /// fields, ctors, et. all
  public void Method1()   { // calls HelperMethod1 and HelperMethod2 }
  private void HelperMethod1 { // calls HelperMethod3 }
  private void HelperMethod3 {}
  private void HelperMethod2 {}

  public void Method2 () { // and so on... }

}

Burada bir uzuvda olabilirim, ama kullandığınız aracın bu konuda bir etkisi olup olmadığını merak ediyorum. Geliştiricilerin vermesi gereken IDE kararına karşı metin editörüne atıfta bulunuyorum.

Bir IDE'de, kaynak dosyaları görüntülemek için çok daha fazla işleve sahipsiniz. Genellikle, alfabetik olarak, görünürlüğe göre sıralanan yöntemlerin bir listesini veya kenar çubuğundaki türü bile döndürebilirsiniz. Bunun için bir kullanımınız varsa, bir yönteme de atlayabilirsiniz. Ayrıca yöntemler için çağrı ağaçları oluşturabilir ve ayrıntıya inebilirsiniz. Ayrıca, normal ifadeleri destekleyebilecek güçlü bir find komutunuz da vardır. Bu durumda, oluşturduğunuz yöntemlerin sırası, kullanılabilir kaynak kodu dışında görünümlere sahip olduğunuz için gerçekten önemli değildir.

Bir metin düzenleyicide, genellikle bu özelliklere sahip değilsiniz - sahip olduğunuz en yakın özellik muhtemelen güçlü bir bulma / değiştirme işlemidir. Burada, dosyanızın yapısına daha fazla dikkat etmek isteyeceksiniz, çünkü gezinmek daha zor olabilir. Aradığınızı bulmak için dosyanın etrafında kaydırma süresini en aza indirmek istersiniz ve tutarlı ve mantıklı bir yöntem sırası yardımcı olabilir.

Mesele şu ki, denilen şeyler bir şeyi çağırmaktan daha az ilginçtir. Bir yöntem diğer yöntemleri ne kadar çok çağırırsa, bu yöntemin nesnenin harici API'sının bir parçası olma olasılığı o kadar yüksektir (bir uygulama ayrıntısının aksine). Bu, dilinizin bu kavramı desteklemesi halinde sınıfın harici API'sı anlamına gelir - doğal olarak dosyanın üstünde "olmasını" isteyecek ve bu yöntemleri bulmayı kolaylaştıracaktır. Tersine, yardımcı fonksiyonlar ve bu gibi şeyler dosyanın altında olmasını isteyecektir.

(Kavramını açıklıyorum, etkinliğini değerlendirmiyorum.)

Uzun süreye göre birkaç günden fazla demek istiyorsan? Sonra hayır.
Birkaç yıl önce bunu yeni bir kodla yapmaya başladım ve duruncaya kadar kendimi yavaşça delirdim.

Benim kişisel sınıfları dışarı atarken için tercihi

class MyClass
{
    // static fields
    // fields
    // constructors
    // properties
    // methods
} 

Ancak bu dini değil, özellikler ve yöntemler birbirine karışabilir. Görünürlük bu duruma gelmiyor (kamu / korumalı / özel olarak gruplandırmıyorum)

Burada bir adam var, sınıf dosyasındaki her şey üzerinde sıkı bir yapıya sahip, her şey ana gruplar ve alt gruplar halinde, hepsi de bölgelere güzelce yerleştirilmiş. . . İtiraf etmeliyim ki bölgeler Şeytan'ın işi, beni çil kıvrımının etrafında sürüyorlar.

Sınıflarından birini her açtığımda içeride biraz ölürüm :(