Зачем объяснять? Параметры функций, их возвращаемые результаты и тело управляющей функции все скажут за вас.
Вижу шесть приватных функций. Нашёл, что одна из них вызывает другие. Ок, с ней понятно.
Остальные пять ― одни делают какую-то общую работу и не имеют смысла друг без друга, или логически независимы и используются или могут использоваться где-то ещё?
Если я удаляю за ненадобностью главную функцию, эти пять можно тоже удалить? IDE могут помочь это выяснить, но не точно и невсегда удобно. Если я таки удалю все функции и ничего не сломается, может всё-таки не стоило удалять ― вдруг был расчёт переиспользовать их функционал? Не зря же их кто-то (или я сам) выделил в отдельные функции.
А если не удалю, получится мёртвый код, который вроде есть, но вроде нигде не используется. Хрен знает, как он тут появился, зачем нужен и что с ним делать.
Более того, все пять стадий и зависимости между ними станут явными и будут выражены непосредственно в коде, а не в ваших комментариях.
Ну и стоило ли ломать зависимости, чтобы потом их восстанавливать? Цепочка действий и так была прекрасно обозначена в исходной функции. Зачем последовательность превращать во множество, чтобы потом из множества опять собирать последовательность? Явные зависимости, если уж есть, завсегда понятнее неявных.
Управляющая функция имеет ту же сигнатуру, что и исходная — ее детали наружу не торчат.
Мы ведь про пишущих/читающих исходники говорим, а не про стороннего пользователя, который видит только публичный API. К такому стороннему пользователю вся эта тема вообще не имеет отношения.
Под "наружу" я имею в виду сигнатуры функций.
Когда есть одна большая функция, у неё все кишки, все детали реализации внутри. Свернул функцию и кишок не видно. Надо изменить логику ― внутри функции изменил, снаружи никто не заменил.
А когда большая операция искусственно раздроблена на мелкие части, изменение внутри одной часто влечёт изменение в других. У одной изменились выходные параметры ― меняй входные у другой. Изменения серьёзнее ― переписывай другие функции целиком. Инкапсуляция близка к нулю.
Аргументы стадийных функций отражают данные, необходимые для каждого этапа большого процесс.
Нет смысла фиксировать детали реализации в сигнатурах функций. Сигнатура ― это контракт, который функций «обещает» выполнить неважно каким способом. И тот контракт видится как нечто более стабильное, чем внутренности. А при искусственном делении оказывается, что не контракт влияет на реализацию, а наоборот.
И как бонус — вы можете переиспользовать стадийные функции в другом варианте большого процесса.
Когда/если это понадобится, тогда можно будет озаботиться. Опыт показывает, что с большой вероятностью не понадобится.
Далее чем больше блок который мы хотим отдельно выделить в контексте кода комментарием, тем больше вероятность что нам будет выгоднее вынести весь этот блок как отдельную функцию, тем самым устранив необходимость фильтровать информацию читателю.
В результате линейная последовательность операций получается записанной в исходнике нелинейно. И читателю (в т.ч. нам в будущем) приходится прыгать взад-вперёд по исходнику, чтобы восстановить в голове полную картину происходящего.
Если есть другие причины бить большую функцию на мелкие, кроме её размера, ― бей; не других причин ― оставь как есть, не порть.
у вас будет одна публичная функция и 5 приватных.
Или была одна приватная, стало шесть приватных, одинаковых с виду. Сразу весело.
Потому знания о том что в каком порядке будет вызываться будут сокрыты.
Не понял. Если я читаю исходник, мне не надо, чтобы логика работы была скрыта, мне надо, чтобы всё было кристально прозрачно. Если же я простой потребитель публичного API, то мне пофиг на исходник и как оно там внутри написано.
Это по сути и есть "приватные" функции. Можно так же объявить замыкания и дать пояснение тому что они делают при помощи переменной.
Вероятно, имелись в виду лямбда-функции. Но в любом случае ты понимаешь, что некоторая проблема есть, и чрезмерное количество мелких функций небесплатно с точки зрения поддержки.
если ваша функция слишком длинная и скажем имеет в своем названии And это признак того что оно делает слишком много.
Ну делает и делает, это не повод её дробить. Есть другие причины для дробления ― пожалуйста. Упрощение тестирования, например. Нет других причин ― оставьте бедную функцию в покое.
В целом комментарии как правило создают лишнюю когнитивную нагрузку. Но не всегда конечно.
Я лишние функции не создают нагрузку разве?
Вот есть операция из пяти стадий, которые выполняются друг за другом и друг без друга не работают. Бьёшь большую функцию на пять маленьких и одну управляющую и получаешь в исходнике шесть артефактов вместо одного. Поди потом помни и объясняй всем, зачем они нужны и в каком порядке их правильно вызывать. Как бонус, в большой функции её интимные локальные данные были скрыты от посторонних взглядов, а теперь эти детали реализации торчат наружу в виде аргументов.
Только не надо говорить, что это не проблема. В C# для её решения сделали локальные функции.
Актуальность имён функций утрачивается так же легко, и они так же легко врут.
Комментарий может отсутствовать, а имя функции не может.
Комментарии в длине не ограничены, а от длины имени функции зависит удобство её использования. Но чем короче имя функции, тем больше шансов, что оно что-то утаивает.
Просто «список», без уточнений ― это абстрактная упорядоченная коллекция нефиксированного размера, которая реализована может быть как угодно. Когда термин «список» встречается в описании какого-нибудь алгоритма, если нет уточнений, лучше его именно так абстрактно и понимать.
Система координат, которую мы будем использовать, обладает очень ценным свойством: взаимной перпендикулярностью. Это значит, что в пересечении каждой из осей на своей соответствующей плоскости угол между ними равен 90 градусам.
Вряд ли имеет смысл выделять точки и вектора в отдельные типы. Во-первых, иногда точку удобнее воспринимать как её смещение относительно начала координат, и тогда это уже не очень точка. Во-вторых, геометрических смыслов у векторов даже не два, а три: точка, смещение и направление. И если уж использовать отдельные типы, то их надо тоже три, плюс четвёртый ― абстрактный вектор, где в одном месте будут собраны все полезные для работы с векторами математические операции.
Проще работать с абстрактными векторами, не забывая конечно про геометрический смысл каждого конкретного вектора:
Точка. Вектор задаёт её координаты относительно начала координат.
Смещение. Вектор задаёт его направление и дальность. Смещение относительно, к началу координат не привязано.
Направление. Например, нормаль треугольника, нормаль к поверхности в какой-то точке, направление взгляда персонажа, ось вращения. У такого вектора главное ― направление. Длина не принципиальна, но очень удобно, чтобы она всегда была единичной.
Имеется три основных типа преобразований при переводе вектора из одной системы координат в другую: поворот, масштабирование и перенос. Геометрический смысл вектора определяет, какие преобразования к нему нужно применять, а какие не нужно:
К точке надо примерять все три: поворот, масштабирование и перенос.
К смещению только два: поворот и масштабирование. Перенос изменяет длину вектора смещения, а она при переносе меняться не должна.
Для вектора направления важен только поворот. Применение переноса нарушает и направление вектора и его длину. Равномерное по всем осям масштабирование сохранит направление, но нарушит единичную длину; неравномерное масштабирование нарушит всё.
Игры больше не challenge, игры все больше entertainment. Жаль, хотя я понимаю разработчиков. Большая часть аудитории того-же XCOM не потянет играть в оригинальный UFO: Enemy Unknown с его сложным процессом.
Если в современном XCOM: Enemy Unknown не беречь жизни своих солдат, то состоящий из новобранцев отряд к середине игры становится практически бесполезен. Game Over.
Безотносительно языка я бы сказал, что у массивов предполагается фиксированный размер с возможной многомерностью, а у списков переменный размер и одномерность. Собственно, это всё, что можно сказать про различия массивов и списков не вдаваясь в детали конкретной реализации.
> Вот никогда не понимал, почему вопросы такого типа являются безусловным маркером уровня программиста. Загуглить ответ — 5 минут, прочесть и понять, ну пусть еще час. При наличии опытного товарища, ответ на вопрос займет 15 минут.
Если программист не знает, как устроены и чем отличаются структуры данных в его языке, значит он не может делать между ними осмысленный выбор и пишет код как придётся, а не как надо. Поэтому работать работу скорее возьмут его опытного товарища.
В реале эффективнее строить несколько энергоблоков на одной АЭС, чем несколько АЭС по одному энергоблоку. Только это эффективность не с точки зрения ГВт на реактор, а с точки зрения инфраструктуры и логистики.
В игре это обыграли бонусом мощности реакторов. Эта механика подталкивает игроков строить большие и интересные штуки, а не кучу скучных маленьких.
Запускается, да, но память кушает охотно. Открыл своё последнее сохранение, у процесса commit size 5,7 Гб.
У меня есть простой нетбук на дешёвом Селероне 2х1,6 ГГц с родными 2 Гб памяти. Из любопытства запускал на нём Factorio ― сильно лагало. Потом поменял на 8 Гб, ещё раз запустил для сравнения ― было вполне играбельно даже на прилично развитой базе.
У меня начинает замедляться на стадии, когда производство железных/медных пластин находится примерно в районе 20k в минуту. Если заранее думать о производительности, можно сделать производство раз в десять эффективнее в пересчёте на мегагерц процессора, но я не хочу об этом думать, играю как играется.
А какими факторами из реальной жизни это объясняется?
Тем, что одно большое предприятие эффективнее сотни маленьких.
Задумка разработчиков состояла в том, чтобы пользователи игрались с дизайном большой и сложной электростанции, вместо того чтобы штамповать бесконечные поля из простых клонов, как в случае солнечных панелей и ТЭС.
На самом деле, для занятия территории достаточно довольно редкой сетки из одиноких строений
Уже не так с версии 0.13, если не ошибаюсь. Сейчас каждое строение лишь немного уменьшает вероятность, что жуки построят рядом свою базу. Чтобы снизить вероятность до близкой к нулю, надо строить сплошной ряд чего-нибудь. Логично построить сплошную стену.
Вижу шесть приватных функций. Нашёл, что одна из них вызывает другие. Ок, с ней понятно.
Остальные пять ― одни делают какую-то общую работу и не имеют смысла друг без друга, или логически независимы и используются или могут использоваться где-то ещё?
Если я удаляю за ненадобностью главную функцию, эти пять можно тоже удалить? IDE могут помочь это выяснить, но не точно и невсегда удобно. Если я таки удалю все функции и ничего не сломается, может всё-таки не стоило удалять ― вдруг был расчёт переиспользовать их функционал? Не зря же их кто-то (или я сам) выделил в отдельные функции.
А если не удалю, получится мёртвый код, который вроде есть, но вроде нигде не используется. Хрен знает, как он тут появился, зачем нужен и что с ним делать.
Ну и стоило ли ломать зависимости, чтобы потом их восстанавливать? Цепочка действий и так была прекрасно обозначена в исходной функции. Зачем последовательность превращать во множество, чтобы потом из множества опять собирать последовательность? Явные зависимости, если уж есть, завсегда понятнее неявных.
Мы ведь про пишущих/читающих исходники говорим, а не про стороннего пользователя, который видит только публичный API. К такому стороннему пользователю вся эта тема вообще не имеет отношения.
Под "наружу" я имею в виду сигнатуры функций.
Когда есть одна большая функция, у неё все кишки, все детали реализации внутри. Свернул функцию и кишок не видно. Надо изменить логику ― внутри функции изменил, снаружи никто не заменил.
А когда большая операция искусственно раздроблена на мелкие части, изменение внутри одной часто влечёт изменение в других. У одной изменились выходные параметры ― меняй входные у другой. Изменения серьёзнее ― переписывай другие функции целиком. Инкапсуляция близка к нулю.
Нет смысла фиксировать детали реализации в сигнатурах функций. Сигнатура ― это контракт, который функций «обещает» выполнить неважно каким способом. И тот контракт видится как нечто более стабильное, чем внутренности. А при искусственном делении оказывается, что не контракт влияет на реализацию, а наоборот.
Когда/если это понадобится, тогда можно будет озаботиться. Опыт показывает, что с большой вероятностью не понадобится.
В результате линейная последовательность операций получается записанной в исходнике нелинейно. И читателю (в т.ч. нам в будущем) приходится прыгать взад-вперёд по исходнику, чтобы восстановить в голове полную картину происходящего.
Если есть другие причины бить большую функцию на мелкие, кроме её размера, ― бей; не других причин ― оставь как есть, не порть.
Или была одна приватная, стало шесть приватных, одинаковых с виду. Сразу весело.
Не понял. Если я читаю исходник, мне не надо, чтобы логика работы была скрыта, мне надо, чтобы всё было кристально прозрачно. Если же я простой потребитель публичного API, то мне пофиг на исходник и как оно там внутри написано.
Вероятно, имелись в виду лямбда-функции. Но в любом случае ты понимаешь, что некоторая проблема есть, и чрезмерное количество мелких функций небесплатно с точки зрения поддержки.
Ну делает и делает, это не повод её дробить. Есть другие причины для дробления ― пожалуйста. Упрощение тестирования, например. Нет других причин ― оставьте бедную функцию в покое.
Я лишние функции не создают нагрузку разве?
Вот есть операция из пяти стадий, которые выполняются друг за другом и друг без друга не работают. Бьёшь большую функцию на пять маленьких и одну управляющую и получаешь в исходнике шесть артефактов вместо одного. Поди потом помни и объясняй всем, зачем они нужны и в каком порядке их правильно вызывать. Как бонус, в большой функции её интимные локальные данные были скрыты от посторонних взглядов, а теперь эти детали реализации торчат наружу в виде аргументов.
Только не надо говорить, что это не проблема. В C# для её решения сделали локальные функции.
LinkedList ― это конкретно «связный список».
Просто «список», без уточнений ― это абстрактная упорядоченная коллекция нефиксированного размера, которая реализована может быть как угодно. Когда термин «список» встречается в описании какого-нибудь алгоритма, если нет уточнений, лучше его именно так абстрактно и понимать.
Текст читается так, словно равенство X=Y×Z выполняется только для правосторонней системы координат. Хотя на самом деле в левосторонней оно верно тоже.
Вряд ли имеет смысл выделять точки и вектора в отдельные типы. Во-первых, иногда точку удобнее воспринимать как её смещение относительно начала координат, и тогда это уже не очень точка. Во-вторых, геометрических смыслов у векторов даже не два, а три: точка, смещение и направление. И если уж использовать отдельные типы, то их надо тоже три, плюс четвёртый ― абстрактный вектор, где в одном месте будут собраны все полезные для работы с векторами математические операции.
Проще работать с абстрактными векторами, не забывая конечно про геометрический смысл каждого конкретного вектора:
Точка. Вектор задаёт её координаты относительно начала координат.
Смещение. Вектор задаёт его направление и дальность. Смещение относительно, к началу координат не привязано.
Имеется три основных типа преобразований при переводе вектора из одной системы координат в другую: поворот, масштабирование и перенос. Геометрический смысл вектора определяет, какие преобразования к нему нужно применять, а какие не нужно:
К точке надо примерять все три: поворот, масштабирование и перенос.
К смещению только два: поворот и масштабирование. Перенос изменяет длину вектора смещения, а она при переносе меняться не должна.
Если в современном XCOM: Enemy Unknown не беречь жизни своих солдат, то состоящий из новобранцев отряд к середине игры становится практически бесполезен. Game Over.
Если программист не знает, как устроены и чем отличаются структуры данных в его языке, значит он не может делать между ними осмысленный выбор и пишет код как придётся, а не как надо. Поэтому работать работу скорее возьмут его опытного товарища.
Не понимаю акцента не пузырьке. O() у него может и не очень, зато константы хорошие. Проблема ведь не в методе сортировки, а в самой сортировке.
На поздних этапах атомная бомба тоже очень хороша, даже проще ботов. Главное ― под ноги не стрелять. Нынче это самый популярный способ суицида.
Все до единого способы уничтожать деревья в Factorio:
https://www.youtube.com/watch?v=_FodUsfR32s
Для тех, кто по какой-то причине ещё не видел их в действии: https://www.reddit.com/r/factorio/comments/69k9jp/clearing_out_a_path_for_rail_lines_became_a_lot/
В реале эффективнее строить несколько энергоблоков на одной АЭС, чем несколько АЭС по одному энергоблоку. Только это эффективность не с точки зрения ГВт на реактор, а с точки зрения инфраструктуры и логистики.
В игре это обыграли бонусом мощности реакторов. Эта механика подталкивает игроков строить большие и интересные штуки, а не кучу скучных маленьких.
Г — геймдизайн.
Запускается, да, но память кушает охотно. Открыл своё последнее сохранение, у процесса commit size 5,7 Гб.
У меня есть простой нетбук на дешёвом Селероне 2х1,6 ГГц с родными 2 Гб памяти. Из любопытства запускал на нём Factorio ― сильно лагало. Потом поменял на 8 Гб, ещё раз запустил для сравнения ― было вполне играбельно даже на прилично развитой базе.
У меня начинает замедляться на стадии, когда производство железных/медных пластин находится примерно в районе 20k в минуту. Если заранее думать о производительности, можно сделать производство раз в десять эффективнее в пересчёте на мегагерц процессора, но я не хочу об этом думать, играю как играется.
В движении идеален танк с огнемётом.
Тем, что одно большое предприятие эффективнее сотни маленьких.
Задумка разработчиков состояла в том, чтобы пользователи игрались с дизайном большой и сложной электростанции, вместо того чтобы штамповать бесконечные поля из простых клонов, как в случае солнечных панелей и ТЭС.
На пару недель, скорее.
Уже не так с версии 0.13, если не ошибаюсь. Сейчас каждое строение лишь немного уменьшает вероятность, что жуки построят рядом свою базу. Чтобы снизить вероятность до близкой к нулю, надо строить сплошной ряд чего-нибудь. Логично построить сплошную стену.