Форматирование кода: Планирование функций на основе иерархии вызовов в файле класса?

Предложение от «Чистого кода» Боба Мартина заставляет меня чесать голову… «Если одна функция вызывает другую, они должны быть расположены вертикально, а вызывающая сторона должна быть выше вызываемой»

До сих пор я более или менее придерживался рекомендаций .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 у вас гораздо больше возможностей для просмотра исходных файлов. Как правило, вы можете получить список методов, отсортированных по алфавиту, по видимости или даже по типу возврата на боковой панели. Вы также можете перейти к методу, если у вас есть его использование. Вы также можете генерировать деревья вызовов для методов и детализации. У вас также обычно есть мощная команда find, которая может поддерживать регулярные выражения. В этой ситуации порядок создания методов на самом деле не имеет значения, поскольку у вас есть представления, отличные от исходного кода.

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

Дело в том, что названные вещи менее интересны, чем называть вещи. Чем больше метод вызывает другие методы, тем более вероятно, что этот метод является частью внешнего API объекта (в отличие от подробностей реализации). Это означает, что внешний API класса - публичные методы, если ваш язык поддерживает эту концепцию, - естественно, «захочет» находиться в верхней части файла, упрощая поиск этих методов. И наоборот, вспомогательные функции и тому подобное «захотят» оказаться внизу файла.

(Я объясняю концепцию, а не оцениваю ее эффективность.)

Если под длительным сроком вы имеете в виду более пары дней? Тогда нет
. Пару лет назад я начал делать это на каком-то новом коде и медленно сводил меня с ума, пока не остановился.

Мое личное предпочтение при планировании занятий

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

Но это не религиозно, свойства и методы могут смешиваться. Видимость не входит в это (я не группирую по публичному / защищенному / частному)

У нас здесь, в офисе, есть парень, который строго следит за всем в файле классов, и все сгруппировано в основные группы и подгруппы, все они хорошо вложены в регионы. , , Должен признать, я считаю, что регионы - это дело сатаны, они сводят меня с ума.

Каждый раз, когда я открываю один из его классов, я умираю немного внутри :(