Как упоминалось ранее, в любой приличной среде IDE порядок функций в файле становится гораздо менее важным. Это также особенно относится к объектно-ориентированным языкам, где другие методы навигации более полезны, чем последовательное чтение. Например: класс heirarchy; план класса; позвоните heirarchy. Если вы действительно упускаете определения функций, возможно, в языке есть что-то, что подходит для этой цели, например: чисто виртуальные классы в C ++ (если так они называются) или интерфейсы в Java.
Однако, сказав, что всякий раз, когда я реорганизую текст в исходном файле, я всегда склоняюсь к упорядочиванию функций на основе их сплоченности [1]. После этого я иду в том порядке, в котором функции родились . Если, как и в вашем примере, у меня есть функция, из которой родились другие, более мелкие вспомогательные функции, я бы поместил их ниже того места, откуда они были извлечены. Я просто нахожу более интуитивно понятным сначала прочитать то, что важно, и игнорировать мелкие детали, пока мне не нужно их знать, и, увидев сначала более крупный метод, обычно это достигается. Похоже, это больше похоже на ваш второй пример.
Подводя итог, я бы сказал: Большой, затем Маленький , или Публичные, а затем частные помощники .
[1] Это кодовый запах, если в одном классе / файле слишком много группировок, что предполагает их разделение на более мелкие отдельные блоки.