Форматування коду: Покладання функцій на основі ієрархії викликів у файлі класу?

Пропозиція із "Чистого коду" Боба Мартіна змушує мене почухати голову .. "Якщо функція викликає іншу, вона повинна бути вертикально близькою, а абонент повинен бути вище позивача"

Поки що я більш-менш дотримуюся вказівок .Net, які групують членів класу за типом (властивості, ctors, функції) та видимістю (public / prot. / Private). Наконечник спочатку здається неприємним .. але це "просто може спрацювати". Я особисто стикався з випадками, коли мені сподобався такий макет - простіше розгортатись, коли ти в правильній ланцюжку дзвінків.

Ідея за підказкою здається здоровою, але інші сценарії на кшталт "дозвольте мені переглянути загальнодоступний інтерфейс цього класу" можуть погіршитися. Можливо, дядько Боб звертається до малих класів та підтримує IDE для перегляду типів ...

Хтось пробував це протягом тривалого періоду?

Оновлення: схоже, фрагмент коду в порядку

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

}

Я можу тут вийти на кінцівку, але мені цікаво, чи впливає на це інструмент, який ви використовуєте. Я маю на увазі текстовий редактор проти рішення IDE, яке повинні прийняти розробники.

У IDE у вас є набагато більше функціональних можливостей для перегляду вихідних файлів. Як правило, ви можете отримати список методів, відсортованих за алфавітом, за видимістю або навіть повернення типу на бічній панелі. Ви також можете перейти до методу, якщо вам це потрібно. Ви також можете генерувати дерева викликів для методів і розгортати дані. У вас також є потужна команда пошуку, яка може підтримувати регулярні вирази. У цій ситуації порядок створених методів насправді не має значення, оскільки у вас є види, окрім вихідного коду.

У текстовому редакторі, як правило, немає цих функцій - найближче, що ви матимете, - це, мабуть, сильна знахідка / заміна. Тут ви хочете приділити більше уваги структурі файлу, оскільки навігація може бути складніше. Ви хочете мінімізувати витрачений час на прокручування файлу, щоб знайти те, що шукаєте, і послідовний та логічний порядок методів може допомогти.

Справа в тому, що названі речі менш цікаві, ніж називати речі. Чим більше метод називає інші методи, тим більше шансів на те, що цей метод є частиною зовнішнього API об'єкта (на відміну від деталі реалізації). Це означає, що зовнішній API класу - публічні методи, якщо ваша мова підтримує цю концепцію - природно "захоче" опинитися у верхній частині файлу, що полегшить пошук цих методів. І навпаки, помічники і такі функції "хочуть" знаходитись внизу файлу.

(Я пояснюю цю концепцію, не оцінюючи її ефективність.)

Якщо під тривалим періодом ви маєте на увазі більше пари? Тоді ні
. Пару років тому я почав робити це за яким-небудь новим кодом, і повільно зводив з розуму, поки не зупинився.

Мої особисті переваги щодо проведення занять

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

Але це не релігійно, властивості та методи можуть змішатися разом. Видимість не входить у нього (я не групуюсь за загальнодоступними / захищеними / приватними)

У нас тут хлопець в офісі дотримується суворої структури щодо всього файлу класу, з усім згрупованим в основні групи та підгрупи. . . Я мушу визнати, що я думаю, що регіони - це робота сатани, вони обертають мене навколо фекінового повороту.

Щоразу, коли я відкриваю один із його занять, я помираю трохи всередині :(