То есть иногда она всё-таки бесплатно даётся? И в чём тогда вред расширяемости именно в таких ситуациях?
Когда бесплатно — ни в чем. Я нигде не утверждаю что расширяемость всегда вредна. Учитесь читать то что вам отвечают. Я утверждаю что чаще всего за расширяемость надо платить, а платить в тех случаях когда она вам не нужна — очевидно вредно.
Я просто не вижу в чём вред именно самой расширяемости как таковой.
Я уже сочувствовал вам по этому поводу
Банальный пример: у вас есть проект на десятки(а то и сотни) тысяч строк кода. Вы можете запихать все эти строки в один единственный класс
Это не банальный, а детский и оторванный от реальности до нельзя утрированный пример. Потрудитесь привести чтото более реалистичное и далекое от крайностей
Вы несете полную херню и очень тупо передергиваете, как будто расширяемость это святое и всеми силами надо извернуться так чтобы эту святость не опорочить
Расширяемость крайне редко дается бесплатно, вы либо платите за нее усложнением системы, либо большими затратами времени на подумоть\написать.
Так вы просто вред не умеете подсчитывать. Вот например нужно сделать MVP — без расширяемости делать неделю, с расшираемостью — две. Например MVP не взлетел, вы потеряли х2 денег, тупо изза расширяемости.
Или есть 3 фичи в проекте, одна из них скорее всего потребует расширения, две другие — нет. Вы опять же потратите больше денег и времени на разработку, добавляя расширяемость там где не надо.
Кроме того добавляя расширяемость везде вы усложняете систему. В итоге в определенный момент вы получаете обратный эффект, систему становится сложнее понять, сложнее модифицировать, сложнее фиксить в ней баги, и багов становится намного больше.
что она где-то не нужна я себе могу ещё представить
Красивый код — это код, который не имеет багов и который просто расширять. В идеале если он ещё и шустрый.
У кода нет значимого параметра «красота», вообще. Код — это просто описание системы.
который просто расширять
Это все относится не к коду, а к системе. Чем система проще — тем она лучше. Расширяемость — не есть признак качества, порой расширяемую систему сделать дольше и дороже чем такую, которую можно быстро переписать.
Как мне кажется, это не пустая трата времени
Именно что пустая, «красота» кода на качество системы влияет мало
Проблема электрона не в пользователях, а в разработчиках. Было бы поменьше js-дебилов, неспособных даже питон выучить, электрон не был бы так популярен. Как только появится вменяемый кроссплатформенный фреймворк, позволяющий делать приложения под win\mac\linux дешево, на современном прикладном языке (а не на плюсах), и не даунским способом — то электрон умрет. Например если флаттер допортируют. Потому что пользователи не хотят лагучее говно.
Вас еще не замонали споры на тему ОПП vs функциональщина? И то в чем то говно, и это в чем то говно.
Любой современный язык мультипарадигменный, там есть элементы процедуного, ооп и функциональных подходов. В разных кейсах удобны разные подходы. Адекватные люди выбирают подход под задачу.
Писать реальные проекты на чистой функциональщине надо сильно упороться. Это редко в каких кейсах преимущества дает.
Мне кажется, что первична все же читаемость, а не то, сколько тиков тратятся на вызов
В любом коде первична система, которую он описывает, а сам код вторичен. Это как в делать в доме стены потоньше, чтобы в автокаде красивее смотрелось.
Код должен быть в меру понятен, нечитаемое говно это плохо, но и вылизывать код до блеска никакого смысла нет. Извращения на тему «как бы покрасивее написать код» — пустая трата времени.
В эпоху электрона считать тики это уже не модно
Самим то нравится говно на электроне использовать? Хотите чтобы весь софт был такой?
Не, я соглашусь с тем что в прикладном софте считать тики с нынешним железом и оптимизациями компиляторов нецелесообразно, но ставить читаемость кода выше характеристик программы это абсурд и идиотизм.
Ну и разбиение кода на микрофункции по 1-2 строки не увеличивает читабельность, а ухудшает. Сами посмотрите на примеры кода в статье, там же ничего сходу не понятно.
Написание понятного кода не поддается алгоритмизации с помощью набора правил (типа «функция должна быть не длиннее 4 строк»), хватит заниматься ерундой.
Поддержу только тезис о том, что копии лучше делать явно.
Но тут скорее речь о том, что если есть выбор между тем, менять состояние объекта или не менять, то лучше избегать побочных эффектов, то есть не менять.
Этот тезис вообще ниначем не основан, для относительного низкоуровнего кода вообще вреден. Прежде чем совать иммутабельность в плюсы, надо десять раз подумать а зачем оно вам надо.
В конечном итоге тут все зависит от реализации getImage(), в плюсах красивым образом написать ее вообще невозможно. Писать мувы в таких местах это вообще боль. Под него еще надо сам image правильно написать. Вы же понимаете что мув тоже копирует объект, просто правильным образом разруливает ссылки на тяжелые объекты внутри?
Если вы так гоняете этот image, куда проще в shared_ptr его обернуть, это еще и быстрее будет.
Два метода, один под явное копирование, а второй для мутации объекта будет лучшим выбором.
Этот код вообще бессмысленный
auto image = getImage();
auto mirrored = std::move(image).mirrored();
std::cout << image.size() << std::endl; // warning, bugprone-use-after-move
image = getAnotherImage(); // OK
Вы получили объект из функции. Если этот объект создается внутри функции и возвращается, мув бессмысленен. Если он гдето там внутри продолжает использоваться, то мув сломает внутрянку этого кода. В таком случае копию всеравно придется делать.
Так куда понятнее и проще, и не нужен тулинг отслеживать мувнутые объекты
auto image = getImage();
image.flip();
auto copyImage = Image(getImage());
copyImage.flip();
Если вы пишете низкоуровневый код, отталкивайтесь от производительности, а не от советов из книжек про визуально красивый код на джаве
В чем проблема то? Есть кейс где подходит копирование, есть кейс где подходит мутирующий метод. Это С++, тут думать надо на каждом шагу. Решения чтобы можно было не думать, и при этом результат получился оптимизированный не существует.
Если программист из комментария не может решить где какой метод совать, есть куча других профессий.
В целом с современным железом и оптимизациями компилятора таким оверхедом можно принебречь. Если сильно парит — всегда можно заинлайнить.
К вопросу о разбиении кода на минимальные по размеру функции/методы.
Тут все просто, этот совет изначально дебильный. Странно, что имея опыт и понимание того как функции вызываются, вы вообще такие советы слушаете.
Понимание по какому приницпу разбивать функции, в каких кейсах, и самое главное почему так и не иначе приходит с опытом. Получить такое понимание заучив какието там правила невозможно.
Очевидно что делать функцию на 7к строк — дебилизм (но не удивлюсь если есть редкие кейс где такое оправдано), но разбивать код на функции из максимум 4 строк такая же дебильная крайность.
Любой адекватный человек понимает что написано в этой фразе. Попробуйте несколько раз прочитать, может у вас с этим трудности.
Я уже сочувствовал вам по этому поводу
Это не банальный, а детский и оторванный от реальности до нельзя утрированный пример. Потрудитесь привести чтото более реалистичное и далекое от крайностей
Вы несете полную херню и очень тупо передергиваете, как будто расширяемость это святое и всеми силами надо извернуться так чтобы эту святость не опорочить
Расширяемость крайне редко дается бесплатно, вы либо платите за нее усложнением системы, либо большими затратами времени на подумоть\написать.
Или есть 3 фичи в проекте, одна из них скорее всего потребует расширения, две другие — нет. Вы опять же потратите больше денег и времени на разработку, добавляя расширяемость там где не надо.
Кроме того добавляя расширяемость везде вы усложняете систему. В итоге в определенный момент вы получаете обратный эффект, систему становится сложнее понять, сложнее модифицировать, сложнее фиксить в ней баги, и багов становится намного больше.
Сочувствую
Надоело уже очевидные вещи расписывать
А думать правилами — вообще плохой тон. Правила скорее для людей у которых еще нет опыта
А 90% списка вообще сайты для воннабишек
Сама придумала — сама обиделась. Тоже классика.Это ваши слова. Я такого не говорил.
Вот что я говорил, тут смысл абсолютно противоположный
Это все относится не к коду, а к системе. Чем система проще — тем она лучше. Расширяемость — не есть признак качества, порой расширяемую систему сделать дольше и дороже чем такую, которую можно быстро переписать.
Именно что пустая, «красота» кода на качество системы влияет мало
Проблема электрона не в пользователях, а в разработчиках. Было бы поменьше js-дебилов, неспособных даже питон выучить, электрон не был бы так популярен. Как только появится вменяемый кроссплатформенный фреймворк, позволяющий делать приложения под win\mac\linux дешево, на современном прикладном языке (а не на плюсах), и не даунским способом — то электрон умрет. Например если флаттер допортируют. Потому что пользователи не хотят лагучее говно.
Любой современный язык мультипарадигменный, там есть элементы процедуного, ооп и функциональных подходов. В разных кейсах удобны разные подходы. Адекватные люди выбирают подход под задачу.
Писать реальные проекты на чистой функциональщине надо сильно упороться. Это редко в каких кейсах преимущества дает.
Код должен быть в меру понятен, нечитаемое говно это плохо, но и вылизывать код до блеска никакого смысла нет. Извращения на тему «как бы покрасивее написать код» — пустая трата времени.
Самим то нравится говно на электроне использовать? Хотите чтобы весь софт был такой?
Не, я соглашусь с тем что в прикладном софте считать тики с нынешним железом и оптимизациями компиляторов нецелесообразно, но ставить читаемость кода выше характеристик программы это абсурд и идиотизм.
Ну и разбиение кода на микрофункции по 1-2 строки не увеличивает читабельность, а ухудшает. Сами посмотрите на примеры кода в статье, там же ничего сходу не понятно.
Написание понятного кода не поддается алгоритмизации с помощью набора правил (типа «функция должна быть не длиннее 4 строк»), хватит заниматься ерундой.
А вы предлагаете бред. Мувы будто сами багов не могут создать.
Этот тезис вообще ниначем не основан, для относительного низкоуровнего кода вообще вреден. Прежде чем совать иммутабельность в плюсы, надо десять раз подумать а зачем оно вам надо.
В конечном итоге тут все зависит от реализации getImage(), в плюсах красивым образом написать ее вообще невозможно. Писать мувы в таких местах это вообще боль. Под него еще надо сам image правильно написать. Вы же понимаете что мув тоже копирует объект, просто правильным образом разруливает ссылки на тяжелые объекты внутри?
Если вы так гоняете этот image, куда проще в shared_ptr его обернуть, это еще и быстрее будет.
Два метода, один под явное копирование, а второй для мутации объекта будет лучшим выбором.
Этот код вообще бессмысленный
Вы получили объект из функции. Если этот объект создается внутри функции и возвращается, мув бессмысленен. Если он гдето там внутри продолжает использоваться, то мув сломает внутрянку этого кода. В таком случае копию всеравно придется делать.
Так куда понятнее и проще, и не нужен тулинг отслеживать мувнутые объекты
Если вы пишете низкоуровневый код, отталкивайтесь от производительности, а не от советов из книжек про визуально красивый код на джаве
Если программист из комментария не может решить где какой метод совать, есть куча других профессий.
Тут все просто, этот совет изначально дебильный. Странно, что имея опыт и понимание того как функции вызываются, вы вообще такие советы слушаете.
Понимание по какому приницпу разбивать функции, в каких кейсах, и самое главное почему так и не иначе приходит с опытом. Получить такое понимание заучив какието там правила невозможно.
Очевидно что делать функцию на 7к строк — дебилизм (но не удивлюсь если есть редкие кейс где такое оправдано), но разбивать код на функции из максимум 4 строк такая же дебильная крайность.