Comments 46
Хотя не всегда можно уместить функцию в десяток строк, тем не менее присоединюсь к автору — компактные функции читаются легче, и с ними код выглядит аккуратней. ИМХО.
Как я думаю мысль автора в том чтобы разделить «Что и как» через название и реализацию, а все что дальше это уже «смягчение» дискуса какая она должна быть потому и потому, то есть мысль в том что она может быть какая угодно. Нет проблемы в том что не всегда можно уместить функцию — это нормально.
Я не спорю с вами — это мое имхо что написано, с чем я собственно полностью согласен на уровне — сначала идет definition того что делается, а уже другой очередью идет реализация — как бы разные процессы мыследеятельности. Вот об этом «заборе» мне кажется он и пишет — а что за забором это уже вообще не имеет значения без точечного контекста.
Я не спорю с вами — это мое имхо что написано, с чем я собственно полностью согласен на уровне — сначала идет definition того что делается, а уже другой очередью идет реализация — как бы разные процессы мыследеятельности. Вот об этом «заборе» мне кажется он и пишет — а что за забором это уже вообще не имеет значения без точечного контекста.
Я стараюсь разделять свои функции на два типа — «логические» (не имеет ничего общего с логическими операциями) и «физические» (разумеется, ничего общего с физикой).
Я представляю себе как бы два разных читателя кода. Один — босс, ему вечно некогда, он вечно торопится. Ему надо только знать, что сделано. И не важно — как. А второй — технарь, вот ему важно знать, как именно сделана конкретная вещь. Но не важно, в рамках какой большой высокоуровневой задачи. От неё вообще должно быть как можно меньше зависимостей.
Я знаю, в разных умных книжках эти вещи по разному называются. «Бизнес-логика» и «низкоуровневая реализация», или ещё как-нибудь. Но практически все авторы имеют ввиду если не одно и то же, то нечто близкое. В больших сложных проектах уровней может быть и побольше, этакая фрактальная структура.
Так вот… О чём это я? А! «Логические» функции я стараюсь делать короткими. Это как тезисы доклада для босса. А вот «физические» — они могут быть и короткими, и длинными. Зависит от алгоритма, от предметной области — да мало ли от чего. Не всегда технарю удобно нырять по стеку всё ниже и ниже каждые 5 строчек. А босс редко спросит про детали. Ну 2, максимум 3 уровня — дальше он не полезет вникать.
И не важно, что обычно босс и технарь — это я сам. Такая вот шиза.
Я представляю себе как бы два разных читателя кода. Один — босс, ему вечно некогда, он вечно торопится. Ему надо только знать, что сделано. И не важно — как. А второй — технарь, вот ему важно знать, как именно сделана конкретная вещь. Но не важно, в рамках какой большой высокоуровневой задачи. От неё вообще должно быть как можно меньше зависимостей.
Я знаю, в разных умных книжках эти вещи по разному называются. «Бизнес-логика» и «низкоуровневая реализация», или ещё как-нибудь. Но практически все авторы имеют ввиду если не одно и то же, то нечто близкое. В больших сложных проектах уровней может быть и побольше, этакая фрактальная структура.
Так вот… О чём это я? А! «Логические» функции я стараюсь делать короткими. Это как тезисы доклада для босса. А вот «физические» — они могут быть и короткими, и длинными. Зависит от алгоритма, от предметной области — да мало ли от чего. Не всегда технарю удобно нырять по стеку всё ниже и ниже каждые 5 строчек. А босс редко спросит про детали. Ну 2, максимум 3 уровня — дальше он не полезет вникать.
И не важно, что обычно босс и технарь — это я сам. Такая вот шиза.
«Оптимизирующие компиляторы часто работают лучше с короткими функциями, потому что их легче кэшировать» — что имелось в виду? что значит кэшировать функции?
+ В С/С++ если мелкие функции разбросаны по разным единицам трансляции, то лишь применение IPO/LTO заинлайнит такие вызовы. А оно примеряется далеко не всегда.
+ В С/С++ если мелкие функции разбросаны по разным единицам трансляции, то лишь применение IPO/LTO заинлайнит такие вызовы. А оно примеряется далеко не всегда.
А если функции разбросаны по разным проектам, которые собираются независимо друг от друга на разных машинах, то такие вызовы не сможет заинлайнить вообще никакая оптимизация.
По-моему, из контекста всё очевидно. Сомнения в том, выделять код в отдельную функцию или не выделять, возникают только тогда, когда все итоговые функции будут находиться в одном файле… и, скорее всего, даже в одном классе. Когда код нужно вызывать из других файлов, его по-любому придётся оформить в виде отдельной функции. К сожалению (к счастью), goto между файлами не переходит.
Если микро-функция используется в нескольких проектах, то это очень очень плохой признак! В нормальной ситуации такого не должно быть и в здравом уме в голову не придёт — такие микро-функции не должны идти в экспортную секцию модуля, только для внутреннего применения в пределах модуля.
Расскажите это разработчикам на node.js. То, что вы считаете плохим признаком, у них является ключевым моментом методологии разработки.
Мне их жаль. Малейшее изменение в коде такой функции и целые проекты пачками падают в бездну…
Именно это и произошло не так давно.
Малейшее исправление бага, и чинятся все зависимые проекты. Блин, это же типичное копипаста вс депенденси, причем получается что вы за копипасту. В каком мире копипаста лучше?
В принципе согласен. Но на практике могу и в несколько экранов функции писать, а уже потом по мере свободного времени заниматься рефакторингом по их декомпозиции.
Ну и стек. Каждый вызов функции сопровождается пушем в стек.
Так вот эти проверки и вынести в отдельную функцию. Фишка в том что при анализе функции ты будешь видеть две строчки — подготовка и проверка а не 20 строк непойми какого зубодробительного мусора. Но т.к. эта функция используется только один раз то компилятор её заинлайнит и окончательный код никак не будет отличаться от изначальной — никаких лишних вызовов, использование стека и т.д.
Выгода в структурированности исходного кода, а не результата.
Выгода в структурированности исходного кода, а не результата.
Так в том-то и дело что разбивать предлагается на ПОНЯТНЫЕ фрагменты. Оно итак понятно что если разбивать функцию на непонятные фрагменты то будет только хуже. И если приходится входить в функцию чтобы понять что она делает — это неправильное разбиение. Ну и да, всегда попадётся крепкий орешек который не раскусить, даже алмазные буры бывает ломаются.
Код в первую очередь должен быть понятным на уровне предметной области. А преждевременная оптимизация — зло. Будь то функции по 100+ строк или вынос каждого оператора в отдельную функцию.
Код в первую очередь должен быть читабелен человеком.
Не уверен, какие именно функции автор имеет в виду (отдельные функции, функции-члены, методы?), но он, по-моему, забывает еще одну очень важную вещь, что функции, почти все, контекстно зависимые, и этот контекст необходимо передавать в функцию, либо делать глобальным.
Глобальный контекст (глобальные переменные) — это палка о двух концах, где-то оправдан, а где-то вреден. В любом случае, с глобальным контекстом читающему код уж точно сладко не придется, потому что придется листать вверх-вниз, чтобы понять что куда присвоилось и когда, и зачем.
В случае с передачей контекста в функцию придется либо оформлять его в структуру/класс/коллекцию, либо передавать в виде пачки параметров. Если на каждую функцию делать свою структуру, например, то это может вылиться в кучу структур, которые еще в дополнение к вызову метода надо будет инициализировать. А если передавать как пачку параметров, то в итоге можем получить ситуацию, когда вызов функции со всеми параметрами длиннее, чем сама функция.
Я, конечно, утрирую, но, думаю, смысл понятен; маленькие функции по… гмм… «методологии» автора могут в такой же степени злом, как и добром.
Глобальный контекст (глобальные переменные) — это палка о двух концах, где-то оправдан, а где-то вреден. В любом случае, с глобальным контекстом читающему код уж точно сладко не придется, потому что придется листать вверх-вниз, чтобы понять что куда присвоилось и когда, и зачем.
В случае с передачей контекста в функцию придется либо оформлять его в структуру/класс/коллекцию, либо передавать в виде пачки параметров. Если на каждую функцию делать свою структуру, например, то это может вылиться в кучу структур, которые еще в дополнение к вызову метода надо будет инициализировать. А если передавать как пачку параметров, то в итоге можем получить ситуацию, когда вызов функции со всеми параметрами длиннее, чем сама функция.
Я, конечно, утрирую, но, думаю, смысл понятен; маленькие функции по… гмм… «методологии» автора могут в такой же степени злом, как и добром.
Маленькие функции, как правило, очень слабо зависят от контекста, и более того т.к. вызываются только единожды то контекст у них ровно один — то же самый что у исходного кода который завернули в эту функцию.
Просто берется код и сворачивается чтобы глаз не мозолил лишний раз. Не более того. Обычно это отлаженный код, который легко проверить по входным данным и результату и причин углубляться в него нет никаких.
Просто берется код и сворачивается чтобы глаз не мозолил лишний раз. Не более того. Обычно это отлаженный код, который легко проверить по входным данным и результату и причин углубляться в него нет никаких.
Лично меня меньше всего волнуют размеры моих функций и методов, в плане искусственной границы, обозначенной каким-нибудь потолочным магическим числом 6 или 10 (почему не 11 и не 12?).
Но подсказки моего анализатора кода по поводу слишком длинного метода принимаю во внимание всегда, как знак того что может быть здесь имеет смысл порефакторить чуток. Но если смысла нет, у меня никогда не зудит, что метод длинный.
Никогда не уменьшаю длину функции в ущерб читаемости и понятности. Никогда не выношу блок кода в отдельную функцию ТОЛЬКО ради того, чтобы другая функция стала короче.
И лично для меня, «попахивают» не длинные функции, а советы «не делать методы длинней X строк». Можно (и нужно) дать совет не делать длинные функции, не забывать про декомпозицию и пр., но когда в таком совете появляется цифра — то на свалку такой совет.
Но подсказки моего анализатора кода по поводу слишком длинного метода принимаю во внимание всегда, как знак того что может быть здесь имеет смысл порефакторить чуток. Но если смысла нет, у меня никогда не зудит, что метод длинный.
Никогда не уменьшаю длину функции в ущерб читаемости и понятности. Никогда не выношу блок кода в отдельную функцию ТОЛЬКО ради того, чтобы другая функция стала короче.
И лично для меня, «попахивают» не длинные функции, а советы «не делать методы длинней X строк». Можно (и нужно) дать совет не делать длинные функции, не забывать про декомпозицию и пр., но когда в таком совете появляется цифра — то на свалку такой совет.
Ситуация хуже некуда: звёздный кодер придумывает себе свои личные персональные принципы, а потом сам их пропагандирует, мол, я звезда и делаю вот так, а лемминги вокруг рты откроют и поддакивают, а потом с ними говорить невозможно, лопочут неосознанные догмы и всё, vox populli. Сотни их было, Макконел, или там, suckless, прости господи. Светлая идея ценности каждого мнения сталкивается с жестокой реальностью фанатизма и долбоклюйства. Субъективный идеализм, мать его.
Советую прочитать «Чистый код» Мартина;
Сначала кажется, что с такими мелкими методами, кода будет гораздо больше и будет множество методов. Но в итоге все сворачивается и становится простым и лаконичным.
А выносить часть кода в функцию, только ради избавления копипасты — это в корне не верно.
Сначала кажется, что с такими мелкими методами, кода будет гораздо больше и будет множество методов. Но в итоге все сворачивается и становится простым и лаконичным.
А выносить часть кода в функцию, только ради избавления копипасты — это в корне не верно.
Ну не знаю. Много раз сталкивался с разделением функций ради разделения функций, читать отвратительно. Вместо простого
Получается что-нибудь
Так что мне кажется выносить функцию которую используешь только один раз — блажь.
public void requestSomethingParseAndSave(String parameter) {
List<Integer> data = this.getAPI().getData(parameter);
this.getObservers().notify('data received')
List<Integer> newData = new ArrayList<>();
for (Integer i : data) {
newData.push(i + 15);
}
this.getObservers().notify('data parsed', newData)
this.getAPI().saveData(newData);
}
Получается что-нибудь
вот такое
private void notifyObserversThatDataIsReceived() {
this.getObservers().notify('data received')
}
private List<Integer> getNewData() {
return new ArrayList<>();
}
private List<Integer> parseSomething(List<Integer> data) {
// TODO rewrite, too many lines
List<Integer> newData = getNewData();
for (Integer i : data) {
newData.push(doParsing(i));
}
return newData;
}
public void requestSomethingParseAndSave(String parameter) {
List<Integer> data = this.requestSomething(parameter);
List<Integer> newData = this.parseSomething(data);
this.saveData(newData);
}
private Integer doParsing(Integer i) {
return i + 15;
}
private List<Integer> getData(String parameter) {
return this.getAPI().getData(parameter);
}
private void saveData(List<Integer> newData) {
this.getObservers().notify('data parsed', newData)
this.getAPI().saveData(newData);
}
private List<Integer> requestSomething() {
List<Integer> data = this.getData(parameter)
this.notifyObserversThatDataIsReceived()
return data;
}
Так что мне кажется выносить функцию которую используешь только один раз — блажь.
Ну почему же, стало гораздо понятней — в конечной функции стало меньше воды, просто надо остальные функции вынести в другой файл долой с глаз чтобы не мешались — они нужны будут только в крайнем случае, когда понадобится посмотреть что же всё-таки происходит в коде.
По-моему, вы перегнули палку. Совершенно ясно, что не нужна отдельная функция для создания ArrayList'а.
Конкретно в вашем примере может иметь смысл вынести логику преобразования элемента в отдельную функцию. А для преобразования массивов в Java 8 есть стандартные средства.
Конкретно в вашем примере может иметь смысл вынести логику преобразования элемента в отдельную функцию. А для преобразования массивов в 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
Рано или поздно нам придётся писать ещё одну бизнес функцию, в которой будет получение данных и их сохранение.
Семь раз написать — один обрезать
тестировать проще.
Что лучше — 10000 файлов в одной папке или 10000 папок с одним файлом в каждой? Ни то, ни другое, 100 на 100 оптимальный выбор. Надо понимать, что убирая сложность с одного уровня абстракции мы переносим его на другой.
Вроде как этот вопрос уже давно решен:
Магическое число семь плюс-минус два
The Magical Number Seven, Plus or Minus Two
Магическое число семь плюс-минус два
The Magical Number Seven, Plus or Minus Two
Все верно, но что считать за элемент — строку или блок? Нам, в принципе, не нужно держать в памяти непосредственно все строки кода, надо держать суть блоков — здесь 5 строк вычисляют среднее квадратичное, здесь 5 строк выполняют нормализацию, здесь 5 строк выводят данные. Это три элемента, а не 15.
Судя по вики, если в методе 7+-2 строк, то мозг будет оперировать строками.
Если больше, то блоками, т.е. сделает виртуальный рефакторинг и будет воспринимать блок кода как заинлайненную функцию.
Если больше, то блоками, т.е. сделает виртуальный рефакторинг и будет воспринимать блок кода как заинлайненную функцию.
Это значит, что при правильном структурировании (разбиении на блоки) мы можем нормально оперировать 49 строками в среднем, в противовес куче функций по 2-3 строки.
49 — это примерно один экран в IDE. Но мы работаем не со сферическими функциями в вакууме.
В функции используются параметры/поля класса, которые тоже требуют внимания.
Также можно посмотреть на функцию обработки сообщений от ОС. Она обычно выглядит как свитч по одному параметру, где case блоки независимы. С такой функцией можно работать, даже если она состоит из сотен строк.
Если блоки выстроены в конвейер (каждый блок оперирует только с переменными, записанными предыдущим блоком), то их может быть больше 7, но это синтетический пример.
Поэтому наличие связей между блоками также влияет на количество оперируемых строк.
Даже функцию на 3 строки можно сделать нечитаемой:
В функции используются параметры/поля класса, которые тоже требуют внимания.
Также можно посмотреть на функцию обработки сообщений от ОС. Она обычно выглядит как свитч по одному параметру, где case блоки независимы. С такой функцией можно работать, даже если она состоит из сотен строк.
Если блоки выстроены в конвейер (каждый блок оперирует только с переменными, записанными предыдущим блоком), то их может быть больше 7, но это синтетический пример.
Поэтому наличие связей между блоками также влияет на количество оперируемых строк.
Даже функцию на 3 строки можно сделать нечитаемой:
auto Process(auto var1, auto var2, ..., auto var7)
{
Prepare(var1, var2, var4, var6, var7);
Update(var2, var3, var4, var5, var6);
Save(var1, var3, var5, var7)
}
Кстати, в книге Барбары Оакли Думай как математик утверждается что данное утверждение устарело и сейчас считается что в рабочей памяти может содержаться 4 порции информации. Вроде бы по тексту даже ссылки на конкретные исследования были.
Опять любители дробить цельный понятный код на куски с сокрытием сути за якобы понятным именем разбушевались.
Разбиение на куски привносит два жирных плюса:
1) автодокументирование, пояснять большой кусок кода комментариями больше становится не нужно, название функции прекрасно само говорит за себя
2) тестирование, маленькие куски выполняют очень мало работы, следовательно покрытие тестами становится весьма тривиальной задачей
Если принять это во внимание, то можно отбросить фломастерный вопрос по поводу чистоты и приглядности кода.
1) автодокументирование, пояснять большой кусок кода комментариями больше становится не нужно, название функции прекрасно само говорит за себя
2) тестирование, маленькие куски выполняют очень мало работы, следовательно покрытие тестами становится весьма тривиальной задачей
Если принять это во внимание, то можно отбросить фломастерный вопрос по поводу чистоты и приглядности кода.
1) автодокументирование, пояснять большой кусок кода комментариями больше становится не нужно, название функции прекрасно само говорит за себя
Вообще не факт. Вот есть у вас функция «GetHeader», ну получает она какой-то заголовок, и что? То, что вместо комментария //get header list for generating report column headers вы назвали кусок кода GetHeader, не делает этот код понятнее ни на грамм.
2) тестирование, маленькие куски выполняют очень мало работы, следовательно покрытие тестами становится весьма тривиальной задачей
Если оно при этом снижает читаемость, то это сомнительный tradeoff. Я не против тестирования, я против догмы «куча маленьких функций заведомо понятнее и лучше читается».
2) тестирование, маленькие куски выполняют очень мало работы, следовательно покрытие тестами становится весьма тривиальной задачей
Если эти маленькие функции — приватные, то на тестирование это вообще не влияет. (это случай, когда код из длинного публичного метода в классе вынесли в несколько приватных в том же классе).
Как-то читал "Чистый Код" Роберта Мартина, он в 3-й главе (помимо прочего) привёл соображение, что на одну функцию должен быть один уровень абстракции ("one level of abstraction per function"). Далее, на примере листинга длинного метода testableHtml, он утверждает, что:
- вызов getHtml() — находится на очень высоком уровне абстракции;
- вызов String pagePathName = PathParser.render(pagePath) — на среднем;
- вызов (чего-то там).append("\n") — на весьма низком.
И вроде бы интуитивно это более-менее понятно, но… Кому-нибудь известны конкретные правила, по которым можно не сильно напрягаясь распределить код функции по уровням абстракции? Типа, берём уровень абстракции рассматриваемой функции, как базовый, и понимаем, что один участок кода на 3 уровня абстракции ниже, а другой — всего-лишь на 1, тогда как третий — аж на 10 выше (это, вообще, возможно?).
Sign up to leave a comment.
Длина функции