Далее чем больше блок который мы хотим отдельно выделить в контексте кода комментарием, тем больше вероятность что нам будет выгоднее вынести весь этот блок как отдельную функцию, тем самым устранив необходимость фильтровать информацию читателю.
В результате линейная последовательность операций получается записанной в исходнике нелинейно. И читателю (в т.ч. нам в будущем) приходится прыгать взад-вперёд по исходнику, чтобы восстановить в голове полную картину происходящего.
Если есть другие причины бить большую функцию на мелкие, кроме её размера, ― бей; не других причин ― оставь как есть, не порть.
у вас будет одна публичная функция и 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, если не ошибаюсь. Сейчас каждое строение лишь немного уменьшает вероятность, что жуки построят рядом свою базу. Чтобы снизить вероятность до близкой к нулю, надо строить сплошной ряд чего-нибудь. Логично построить сплошную стену.
Пользовался дома всеми клиентскими версиями Windows от 3.11 до 10, кроме 8 (из-за меню на весь экран). Ничего плохого про Висту не могу сказать. На машинах с 1 Гб памяти и кучей программ — да, грустно; но и на XP на них получше, не так чтобы очень весело. Дома у меня в то время был двухядерник с 2 или 4 Гб, и нормально всё работало, не хуже, чем до этого на XP.
Виста в своё время понравилась несколькими вещами:
1. Поиск в стартовом меню. Как только распробовал, убрал за ненадобностью все ярлыки программ с рабочего стола и превратил его именно в рабочий стол — место для хранения текущих рабочих файлов/документов.
2. Superfetch. Запуск постоянно используемых программ действительно стал происходить быстрее.
3. По сравнению с XP появилась некоторая лёгкая ватность управления, но оно стало более предсказуемым. На XP какие-то действия выполнялись мгновенно, а какие-то могли стопорить оболочку на несколько секунд или даже десятков секунд. В Висте некоторые ранее мгновенные действия могли выполняться с небольшой задержкой в десятые доли секунды, но зато она заметно реже тупила, а некоторые длительные I/O-операции стало можно легко отменять.
4. У меня тогда стоял какой-то Radeon (9600 или X800), и в игре SimCity 4 в Windows XP жутко тормозил скроллинг карты, если было включено отображение деревьев и использовался аппаратный рендеринг. Никакими тонкими настройками и перебором драйверов я эту проблему победить не мог. В Висте же всё решилось само собой, игра залетала как надо.
Или замедлить. Часто быстрее написать с нуля, чем исправлять смысл, терминологию, а потом ещё и выворачивать наизнанку каждое предложение, чтобы звучало по-человечески, а не как явный дословный перевод.
Я так понимаю, в среднесрочной перспективе будут существовать три платформы: .Net Framework для Windows, .Net Core для трёх основных платформ и Mono для всего.
Фишка .Net Framework ― богатство функционала.
Фишка Mono ― встраиваемость и работа на всём, что движется.
Фишка .Net Core ― автономность, платформа идёт вместе с приложением.
В краткосрочной перспективе Mono переходит со своего компилятора на Roslyn, и все три ветви унифицируют свои библиотеки под флагом .Net Standard.
Примерно так я себе это представляю, но могу ошибаться.
У меня изначальная задумка была не столько для отделения «core-кода» от «не-core-кода», а скорее для того, чтобы вынести код, который я использую в каждом проекте Unity, куда-нибудь в одно место. Чтобы не хранить в десяти Unity-проектах десять копий одних и тех же, но чуть-чуть отличающихся исходников; потому что со временем перестаёшь понимать, где лежит более свежая версия, где более старая, и чем они отличаются.
Пробовал заводить для такого кода отдельный проект и билдить его dll в папку Assets текущего проекта Unity, но это неудобно. Оказалось проще кидать в Unity-проект линк на общую папку. В неё же можно положить какие-нибудь общие часто используемые ассеты, типа текстур в сеточку, в шахматную клеточку, в сеточку с пронумерованными ячейками для отладки uv-координат у геометрии.
Тут конечно появляется вероятность сломать что-нибудь в старом проекте, внеся изменения в общий код. Но пока в Unity не появится родная поддержка чего-нибудь типа NuGet, я думаю, это будет наименьшим злом.
Вот только редактор имеет обыкновение пересоздавать файлы .sln и .csproj, поэтому добавить в решение отдельную сборку довольно сложно (хотя, вроде если сильно исхитриться, то можно), а значит скорее всего придется делать их вообще разными solution'ами, что слегка неудобно — одновременно редактировать и ядро и юнити логику не получится,
Я недавно придумал использовать для этого символические ссылки.
Создаёшь отдельный солюшен (CoreSolution) и проект (CoreProject) в Студии. Внутри CoreProject делаешь папочку Core и весь код хранишь в ней. А в проекте Unity в папку Assets кидаешь символическую ссылку на папку Core. В результате, писать и редактировать код можно и в CoreSolution, и в солюшене Unity, и даже одновременно.
Косяков такого подхода пока не заметил. Единственная неприятность ― если забыться и создать новый cs-файл в Unity внутри папки Core , то в CoreProject его потом надо будет добавлять вручную через Add -> Existing Item... Этот момент несколько раздражает.
Для удобной работы со ссылками есть расширение к Проводнику ― Shell Link Extension.
возможны проблемы с подключением какого-нибудь Vector2 от юнити в этот внешний проект (не проверял, т.ч. может быть тут проблем нет).
В этом плане всё нормально. UnityEngine.dll можно подключать к сторонним проектам и пользоваться всем его управляемым кодом. Правда, его там не особо много, в основном вектора и Mathf. Если нарвёшься на метод, который реализован в нативном коде, в худшем случае получишь исключение сразу в момент его вызова.
Искал, выбирал себе какой-нибудь 3D движок, среди прочих наткнулся на Unity 3.0. Потыкался пару часов и понял ― оно. Следующие два вечера потратил на чтение официального руководства, благо, в отличие от предыдущих движков, оно было и подробное. Прочитал его один раз от начала до конца: что легко шло, прочитал полностью: какие-то очень специфические вещи, типа шейдеров, просмотрел по-диагонали. Стало понятно, что вообще в Unity есть, зачем надо, как оно между собой сообщается и в какую сторону смотреть, когда понадобиться сделать ту или иную вещь.
Имхо, кроме родного руководства больше ничего не надо. Можно ещё посмотреть обучающие ролики на интересующую тему: https://unity3d.com/learn/tutorials Ко всяким левым «урокам» на Ютубе отношусь скептически.
Если выбирать для себя правило, как писать код так, чтобы минимизировать случаи, когда где-то что-то может случайно аллоцироваться, то правило «просто не использовать foreach» малоприменимо практически.
Stack, Queue, HashSet, Dictionary, LinkedList, ICollection, IDictionary, IEnumerable на for не переводятся, у них нет индексаторов. Можно перевести на while с использованием итератора, но получим тот же foreach. LinkedList разве что можно перевести на while без итератора, но у него и так нет проблем с foreach.
На цикл for можно перевести массивы (но у них нет проблем с foreach и никогда не было), List (но у него нет проблем с foreach) и IList ― вот он, единственный случай, где от for есть польза.
Т.е. выходит, что правило «не использовать foreach» существует ради одного единственного случая с IList, а в остальных случаях либо бессмысленно, либо малоприменимо.
Если аллокации почему-то важны, взамен предлагаю другое правило, ничуть не сложнее: «без особой на то причины не использовать коллекции-интерфейсы, а коллекциями-классами, напротив, пользоваться свободно».
Не удивляемся. Интерфейсы ― отличный архитектурный инструмент, но и щедрый источник боксинга, причём не только внутри foreach. Ничего специфичного для Unity.
Всегда верьте статьями с «полезными» советами. Не тратьте время на проверку, делайте в точности так, как советуют. Авторы статей ― умные люди, они знают всё о вашем проекте: целевую платформу, жанр, все потенциально узкие места. Они даже точно знаю версию Unity, которую вы используете.
Начиная с версии 5.5 в Unity используется компилятор C# из Mono 4.6. В нём нет бага с аллокациами в foreach из-за боксинга итераторов. Да и до версии 5.5, если этот баг действительно на что-то принципиально влиял, его, имхо, было проще обходить использованием для финальных билдов другого компилятора, чем переписыванием исходного код на for. Сейчас же тем, кто переписывал foreach на for, можно начинать переписывать обратно. :)
В контексте выполнения FixedUpdate свойство Time.deltaTime возвращает значение равное Time.fixedDeltaTime, так что разницы нет. Использовать везде Time.deltaTime рекомендуется просто для однообразия.
Любопытно. Классический способ (с выходом на орбиту, а потом по гомановской траектории) требует примерно 4300-4500 м/с, чтобы попасть в SOI Муны. А сколько нужно при такой траектории?
Unity требует покупки Pro лицензий, если годовой доход организации превышает $200k. Не знаю, как они проверяют и проверяют ли вообще, но смысл в том, что им не важно, чем занимается контора.
Контора может
делать продукты на Unity и продавать;
раздавать их даром, зарабатывая на рекламе или поддержке;
использовать Unity для каких-то внутренних целей (обучение сотрудников, хз);
жить пожертвования пользователей или получать деньги из гос. бюджета.
Вообще не важно, откуда берутся деньги, но если откуда-то всё-таки берутся, изволь купить лицензии.