Длина функции

Как я думаю мысль автора в том чтобы разделить «Что и как» через название и реализацию, а все что дальше это уже «смягчение» дискуса какая она должна быть потому и потому, то есть мысль в том что она может быть какая угодно. Нет проблемы в том что не всегда можно уместить функцию — это нормально.

Я не спорю с вами — это мое имхо что написано, с чем я собственно полностью согласен на уровне — сначала идет definition того что делается, а уже другой очередью идет реализация — как бы разные процессы мыследеятельности. Вот об этом «заборе» мне кажется он и пишет — а что за забором это уже вообще не имеет значения без точечного контекста.

Я стараюсь разделять свои функции на два типа — «логические» (не имеет ничего общего с логическими операциями) и «физические» (разумеется, ничего общего с физикой).

Я представляю себе как бы два разных читателя кода. Один — босс, ему вечно некогда, он вечно торопится. Ему надо только знать, что сделано. И не важно — как. А второй — технарь, вот ему важно знать, как именно сделана конкретная вещь. Но не важно, в рамках какой большой высокоуровневой задачи. От неё вообще должно быть как можно меньше зависимостей.

Я знаю, в разных умных книжках эти вещи по разному называются. «Бизнес-логика» и «низкоуровневая реализация», или ещё как-нибудь. Но практически все авторы имеют ввиду если не одно и то же, то нечто близкое. В больших сложных проектах уровней может быть и побольше, этакая фрактальная структура.

Так вот… О чём это я? А! «Логические» функции я стараюсь делать короткими. Это как тезисы доклада для босса. А вот «физические» — они могут быть и короткими, и длинными. Зависит от алгоритма, от предметной области — да мало ли от чего. Не всегда технарю удобно нырять по стеку всё ниже и ниже каждые 5 строчек. А босс редко спросит про детали. Ну 2, максимум 3 уровня — дальше он не полезет вникать.

И не важно, что обычно босс и технарь — это я сам. Такая вот шиза.

А если функции разбросаны по разным проектам, которые собираются независимо друг от друга на разных машинах, то такие вызовы не сможет заинлайнить вообще никакая оптимизация.

По-моему, из контекста всё очевидно. Сомнения в том, выделять код в отдельную функцию или не выделять, возникают только тогда, когда все итоговые функции будут находиться в одном файле… и, скорее всего, даже в одном классе. Когда код нужно вызывать из других файлов, его по-любому придётся оформить в виде отдельной функции. К сожалению (к счастью), goto между файлами не переходит.

Угу.
Частенько бывает удобно набросать «монстра» абы-как — точнее «как есть», если понятно, что он должен делать.
А потом уже существующий текст аккуратно расчленять на функции — причём в процессе это работы функции могут нарисоваться даже там, где они первоначально никак не планировались.

Ну и стек. Каждый вызов функции сопровождается пушем в стек.

Так вот эти проверки и вынести в отдельную функцию. Фишка в том что при анализе функции ты будешь видеть две строчки — подготовка и проверка а не 20 строк непойми какого зубодробительного мусора. Но т.к. эта функция используется только один раз то компилятор её заинлайнит и окончательный код никак не будет отличаться от изначальной — никаких лишних вызовов, использование стека и т.д.
Выгода в структурированности исходного кода, а не результата.

Код в первую очередь должен быть понятным на уровне предметной области. А преждевременная оптимизация — зло. Будь то функции по 100+ строк или вынос каждого оператора в отдельную функцию.

Код в первую очередь должен быть читабелен человеком.

Не уверен, какие именно функции автор имеет в виду (отдельные функции, функции-члены, методы?), но он, по-моему, забывает еще одну очень важную вещь, что функции, почти все, контекстно зависимые, и этот контекст необходимо передавать в функцию, либо делать глобальным.

Глобальный контекст (глобальные переменные) — это палка о двух концах, где-то оправдан, а где-то вреден. В любом случае, с глобальным контекстом читающему код уж точно сладко не придется, потому что придется листать вверх-вниз, чтобы понять что куда присвоилось и когда, и зачем.

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

Я, конечно, утрирую, но, думаю, смысл понятен; маленькие функции по… гмм… «методологии» автора могут в такой же степени злом, как и добром.

По-моему, вы перегнули палку. Совершенно ясно, что не нужна отдельная функция для создания ArrayList'а.

Конкретно в вашем примере может иметь смысл вынести логику преобразования элемента в отдельную функцию. А для преобразования массивов в Java 8 есть стандартные средства.

public void requestSomethingParseAndSave(String parameter) {
  List<Integer> data = this.getAPI().getData(parameter);
  this.getObservers().notify('data received')
  List<Integer> newData = data.stream().map(MyClass::parseData).collect(Collectors.toList());
  this.getObservers().notify('data parsed', newData)
  this.getAPI().saveData(newData);
}

private static int parseData(int x) {
    return x + 15;
}

Из названия функции видно, что её можно разбить на три:

• Request
• Parse
• Save

Рано или поздно нам придётся писать ещё одну бизнес функцию, в которой будет получение данных и их сохранение.

Все верно, но что считать за элемент — строку или блок? Нам, в принципе, не нужно держать в памяти непосредственно все строки кода, надо держать суть блоков — здесь 5 строк вычисляют среднее квадратичное, здесь 5 строк выполняют нормализацию, здесь 5 строк выводят данные. Это три элемента, а не 15.

Кстати, в книге Барбары Оакли Думай как математик утверждается что данное утверждение устарело и сейчас считается что в рабочей памяти может содержаться 4 порции информации. Вроде бы по тексту даже ссылки на конкретные исследования были.

Разбиение на куски привносит два жирных плюса:

1) автодокументирование, пояснять большой кусок кода комментариями больше становится не нужно, название функции прекрасно само говорит за себя

2) тестирование, маленькие куски выполняют очень мало работы, следовательно покрытие тестами становится весьма тривиальной задачей

Если принять это во внимание, то можно отбросить фломастерный вопрос по поводу чистоты и приглядности кода.