Избавляемся от If и Switch в коде на C#! КАК !?
HTML-код
- Опубликовано: 25 мар 2018
- ШКОЛА ПРОГРАММИРОВАНИЯ ЯЮНИОР - holymonkey_sandbox
INSTA - / ijunior_school
Наш новый канал - / @user-wq2dk1kn2v
БОРИС (Бесплатное Обучение Разработке Игр) - ijunior.ru/boris/promo01?...
Обучение с нуля с гарантией трудоустройства - ijunior.ru/unity-start?...
МОЯ КНИГА - csharpbook.sakutin.ru
ГРУППА КАНАЛА - holymonkey
Я В VK - rsakutin
ЧАТ В ТЕЛЕГЕ - t.me/csharp_faggots_fan_club
Немного изменил мой процедурноориентированный мозг.
Привет. Спасибо за видео. Было бы интересно посмотреть материал про паттерн "Состояние".
8:23 class Damageable
c# naming conventions: имена классов должны быть существительными (noun) из 1 или нескольких слов (noun phrases), имена интерфейсов должны быть (фразами) существительными (noun) или прилагательными (adjective).
А где вы эти все правила наименования берете? Можете скинуть такие сайты. Я мучаюсь с тем, как следует называть делегаты и события, а также методы, которые мы в них передаем. Вроде такое правило специальное есть.
@@theshamil6796 официальный сайт Майкрософт, C# specification. Они же и создали этот ЯП
По поводу вопроса "визуализация сущности - это не задача самой сущности" можно попробовать передать ответственность в Какой-нибудь Printer, который будет форматировать данные сущности. И этот принтер передавать в метод show для сущности. Так мы выделим из неё этот responsibility
Благодарю, очень интересные способы, которые, на самом деле, делают код красивым)
А разве это не паттерн стратегия ? Здесь же замену объекта контролирует клиент, а в паттерне состояние это делает либо контекст, либо само состояние имеющее ссылку на контекст, без участия клиента. Да и чисто семантически, вы устанавливаете СТРАТЕГИЮ (то есть алгоритм) расчета урона в зависимости от типа юнита, а не от его состояния (что юнит ранен/устал/болен и.тд)
Чувак. Работай над звуком! Хороший контент погибнет потому, что много людей его просто не услышат.
Хотел спросить, нельзя ли потише, а то ещё слышно.
Ещё с произношением английского беда.
+1 годный контент, но приходиться на макс выкручивать громкость.
думаешь легко вот так сразу вовремя микрофон из ж**пы вытащить. :)
Согласен, очень трудно слушать, прям до зевоты.
«Вот так, с помощью нехитрых приспособлений буханку белого (или черного) хлеба можно превратить в троллейбус… Но зачем?»
хе-хе, про такую реализацию логики знал, про такое как в принимаемых consolecolor color не знал, спасибо за видео.
Предусматривать ситуации, которые "никогда не произойдут" это очень круто.
Это называется определять множество функции на множестве аргументов, которые не планируется использовать.
Нормализации звука - наше все, чел!
Во 2м примере вспоминается warcraft 3, там похожая ситуация - юниты получают разное количество урона в зависимости от типа брони, но там все-таки сложнее, т.к. тип атаки тоже разный. Здесь можно обойтись 1 классом Unit, сделать у него поле damageMultiplier и в ApplyDamage() сделать Health -= damage * damageMultiplier
Вообще можно, но он для примера показал что делать если нужно исполнить разный код в зависимости от того, кто попал под урон
Нихуя ты умный. Я б тебя назначил главным программистом.
Очень интересная тема, продолжай)
а вот со второй штукой хочется поспорить. порой реально удобнее использовать свитч, оставив наследование на как можно более поздний уровень (непосредственно работа с префабами/блюпринтами)
Я не совсем понимаю о чём идёт речь. Можете привести пример?
Юнити касается в меньшей мере, в префабы не наследуются, ближе подход к анриалу. Допустим есть ряд объектов, которые невероятно похожи (к примеру оружие в игре, или гранаты. или какие-то странные машинки с очень спецефическими нюансами в управлении), которые отличаются реально в одной мелочи (читай, в одном методе)
тогда, для дизайнеров и прочих удобнее если им нужно будет брать не один из кучи компонентов вида "фигня 1", "фигня 2", "фигня редкая баклажанная", а просто выбрать из выпадающего списка его тип
таким же способом удобно сделать всякие "способности" в играх, если их набор заранее очерчен и конкретные способности отличаются лишь анимациями и значениями маны/урона. Ты даёшь геймдизам конструктор из которого он собирает очередное гавно, которая сломает баланс игры :)
У нас примерно так и сделано кстати. Только вместо перечислений используем выпадающий список из реализаций интерфейса - sun9-9.userapi.com/c840731/v840731632/5ff3f/T_BDmPITWF8.jpg
Во втором примере стоит оговорить, что это не совсем разные алгоритмы, а алгоритмы из какого-то класса, что мы можем выделить обобщённый алгоритм по зависимости.
Если бы речь шла, скажем, о типах сообщений от операционной системы, то там просто входящий параметры могут оказаться разными: либо координаты, либо код клавиши, например.
Примеры хорошие. Только в первом примере другие компоненты не знают по какому индексу с массиве лежит item, и где-то снова возникнет хардкод индексов. С точки зрения самого примера это не критично, но ведь кто-то этого не поймет и так и напишет. Второй пример хочется расширить до разрушаемых и не разрушаемых объектов (например зданий), потому что новички просто все унаследуют от Damageable с пустым ApplyDamage
Я думаю, что будет лучше поместить все в интерфейс, а для зданий добавить еще один интерфейс для разрушения
Прощу прощения, а можете скинуть методички, про которые говорите в видео?
Лучше использовать Dictionary чем Array,
потому что у тебя нет гарантии "itemId" всегда будет последовательным
Во второй ситуации, вроде, можно было сделать класс для объектов (Human, Animal, Building). И просто задавать им параметры.
Ну это так, для наглядности полиморфизма создал. С точки зрения программирования(не с точки зрения темы этого видео) это является правильным кодом. Можно так же переименовать Damageable в Entity, чтобы было более "правильно"
@@mezozzoi Ну ок, спасибо за ответ.
ShowInfo можно ещё сделать extention-методом
Есть минус у твоего рефакторинга: дополнительное выделение памяти. Под создание массива в 1 случае, и создание виртуальной таблицы во 2м.
Для 1 случая сам процесс выделения памяти относительно дорогой, и им не стоит злоупотреблять. 2й способ очень хорош, если много вариантов в изначальном switch
Смысл вообще твоей претензии, когда в массиве 5 элементов всего?
Пишешь как тебе удобнее. Главное читаемость и реюзабилити кода, расширяемость
@@SysWOOOW Отвечу на твой пост, чисто ради продвижения этого видео чуть выше в топ :) В моём 1м посте констатация факта. Память выделяется. Каждый сам решает для себя, как ему и что удобней. В принятии решения нужно учитывать все плюсы и минусы.
Как по мне, любая претензия в плане "доп затраты для памяти" неуместны, в частности для unity и c# в связке. На это есть несколько причин:
1)в c# нет достаточного количества инструментов для динамической работы с памятью, как в c или c++. Хитровыебнуться с динамическим выделением памяти(и конечно же с динамической чисткой) под объект, имеющем в себе трехмерные массивы не выйдет, сдвинуть побитово массив из указателей тоже (да и не надо, не для этого язык создавался). На борту c# уже есть "авточистка", которая +- нормально работает. Можно запариться и написать библиотеку на чистом с, которая будет подчищать память в процессе работы, но это такой гемор, который ещё мир не видовал
2) unity не самая оптимизированная платформа, которая сама по себе работает так себе. И игры, которые выходят с её конвейера даже с самым оптимизированным кодом (if и switch повсюду лол) работают жопой об косяк(вспомним Тарков), только если это не супер казуал, где нечему нагружаться .
Пример в видео не нацелен на оптимизацию, видео вообще не про это(кста, вроде такое видео есть на канале), это про то, как сделать код более логичным, архитектуру устойчивой и удобное взаимодействие с кодом в будущем. Можно написать код один раз так, чтобы он работал и ты даже вроде понимаешь, как она работает, как все устроено, но в какой-то момент тебе надо его дополнить или исправить...и ты даже не знаешь, как к нему подступиться, потому что код хоть и логичен, но не структурирован.
@@user-fu4mu2fw3h я пишу на плюсах, и делаю с памятью что хочу 🙈
Могу массив структур и на стеке разместить (если прям часто используется)
Часто используемый код оптимизируешь с профилировщиком и красота. Про выделение памяти в С# с тобой согласен.
С одной стороны сущность сама себя отрисовать не может, с другой стороны сущность сама себе нанести урон может. Увеличивается объем кода, добавляется абстракции, выстраиваются новые цепочки наследования и всё ради того что бы избавиться от if-else? Чем же эта конструкция так ужасна? Боюсь представить что будет если новичок будет пытаться строить нечто похожее.
Тем что она часто упирается в производительность. Если ты люто обмазываешься тактами и операциями в с, то неожиданно для себя откроешь, что полиморфизм быстрее условий раза так в 2.
Я писал компилятор, и разница когда ты делаешь всё через различные условия и полиморфизм очень даже ощутимая. Диск ~80мс + сборка 25\10мс.
(+Так легче код поддерживать)
как включить вертикальные пунктирчики для фигурных скобок?
Спасибо. Уже применил)
Отличное содержание, НО ... буквы и картинки с эффектом зумИн/зумАут постоянными и тихий звук оооочень напрягают. Лови палец вверх :)
Спасибо! Классно!)
"Кода стало больше, он стал лучше." Нет, не стал, мы опять обменяли память на быстродействие.
я только начал учить язык вопрос? . а если свитч будет допустим 100 кейсов то что лучше ?
@@narilcrow свитч и создан для множественного выбора. Либо свич, либо миллион реализаций, как в видео. Но настолько большой свич, может свидетельствовать о неправильном подходе при разработке алгоритма. Опишите подробнее ситуацию, может быть предложу альтернативу.
@@theMRbot2013 нет у меня свитчей на 100 кейсов просто вопрос . это мысленный эксперимент не более .
@@narilcrow тогда на чисто риторический вопрос чисто риторический ответ: ошибка в разработке алгоритма.
@@theMRbot2013 спс за ответы .
Нащет замены switch хороши сделано сделал код удобней и легко редактируемым спасибо Роман
Что-то с Damageable тут явно дичь какая-то... Опять же куча копипасты в коде остается и наследование от класса, который не является образующим для сущности. Я, конечно, не особо шарю про игрострой, но разве плохо интерфейсы для таких вещей использовать и проверять возможность урона по наличию онного через where метода или каким-нибудь гетом из движка? Я понимаю, что конкретно в этом случае может так приемлимо и даже хорошо, но очень хочется разобраться в целом.
сними еще видео,как говорить,чтоб тебя все хорошо слышали)
Будьте осторожны и внимательны с копипастой. Автор видео хорошо продемонстрировал возможный выстрел себе в ногу. В первом примере до рефактора последовательность цветов была "красный, синий, серый", после рефактора стало "Синий, красный, желтый".
суть же не цветах, а в способах реализации
😂
Ждём ролик, когда будешь код для прода писать
главное чтобы код удобно читался
Деда с костылями на фоне - я снимал, так уж вышло)
Компот тренируется к следующей битве
В первой ситуации я бы использовал цикл и массив цветов, меньше кода вышло бы.
Вопрос, чем таки плох switch? Ведь в первом примере, закинул на кучу три экземпляра, а если их больше и они сложнее это работа для garbage collector.
Потому что про память никто не будет думать, когда вопрос стоит про архитектуру приложения.
Байтоёберство мешает разработке сложных систем а к этим приёмам нужно привыкать в самом начале, как к хорошему тону.
Так он же сказал чем плох switch, при расширений придется каждый раз добавлять case.
А зачем? Это писанина , когда можем в классе одну строчку добавить место целого case.
@@antonpashkevich5061 Я бы по дискутировал, но нужно пересмотреть видео, что бы понять, о чем речь, комент писал год назад🙂, но судя по коментарию, дело не в том, что проще написать, а в производительности. Наверное меня смущала лишняя работа сборщика.
давай ищчо!
про состояния интересно послушать.
Насчёт второго примера, думаю что для геймдева ни перечисление ни наследование не подходят. Если говорить про юнити, то она компонент-ориентирована, поэтому стоит это использовать для добавления свойств. Для каждого свойства отдельный компонент. И использовать префабы вместо скриптабл обджектов. В реальном проекте такой метод не пробовал, просто пища для размышлений.
Просто наследование и другие методики - это программирование "в слепую", без интерфейса. В случает движка это не эффективно. Вот что я хотел сказать.
Видео классное, и оно подойдёт для изучения C#, но вот для геймдева не слишком применимо. Точнее не в этом направлении нужно обучать(возможно)
И вообще, на программиста слишком много навешивают, а как же дизайнеры?)
Наследование везде не любят, на только в GameDev :)
парень, с помощью перечислений ИИ для уловной мобы может написать школьник за часик. при чём безопасно в плане механических описок. если Ты считаешь перечисления чем-то не нужным - просто начни писать что-то большее, чем базовые туториалы. для написания игровой логики они оч важны и удобны
Если ты делаешь игры в соло, то здесь тебя никто не ограничивает - делай что хочешь. Если дело доходит до командной работы с дизайнерами, которые не шарят твои программные "приколы", то начинаются проблемы.
Да и проблема в том, что всех изначально приучают использовать перечисления и наследование, ведь это действительно удобно для небольшого туториала. Ну а вот туториалов по тому, как организовать сложный и большой проект я не видел пока что. Ведь это не выгодно создателю видео.
так дизайнерам даёшь готовый функционал. лучше вообще у них студию удалить и заблочить запуск моно ;)
наш проект делает пол сотни людей, весит он добрых 130 Гб, и я просто понятия не имею как без перечислений можно поднять такую махину. перечисления лежат в основе FSM. Альтернатива перечислениям тут только старые олдскульные сишные дефайны, но это реально опасная штука
kirill sviderski а а а
Ты меня не понял)
Я не против перечислений и наследования это основы! Куда без них?) Это как отказаться от функций и возвращать значения через параметры метода.
Но в примере, показанном в видео, можно найти более красивое и юзер френдли решение
Надеюсь вы таки узнали о существовании Dictionary...
Роман, а кроме красивого кода, есть ли выигрыш в производительности?
А кому она нужна, производительность? Быстрей ифов ничего работать не будет. Полиморфизм съедает много ресурсов, и кое-где его применение вообще запрещено. Например VK отказались от ООП в PHP как раз отчасти из-за этого.
@@rsakutin а тогда какой смысл в том, что ты сделал? Выходит ты просто увеличил количество кода без надобности и усложнил читаемость.
@@vladk4144 смысл в расширяемости я тоже думал нахера оно это пока мне не понадобилась сделать больше персонажей чем один, а если у тебя их 200 и более, поэтому это важная и прикольная штука
@@vladk4144 как по мне гораздо понятней стало
А не проще было текст выводить с переменной, А цвет ставить через массив или enum.
Тогда можно было и в ShowDataInfo(d, c) передавать ссылку на объект и все. Вообще, хотелось бы больше узнать про техническую часть - мне кажется что создание массива, класса это будет более затратно по ресурсам чем самый первый метод
ниxyя, не досмотрел 10 секунд и там показали что так и сделали. Ну тогда да - так намного лучше будет
Найс ты меня просветил. Для челов который дрочат на оптимизон, говорю - Виртуальные методы это таблица, а ифы и кейсы 95% это условные ветвления. По таблице ты просто перешёл и потратил х2 такта, а условие хоть и обрабатывается х1 но полностью ломает конвейер процессора и в итоге ты получаешь шляпу.
я бы вообще убрал items и использовал tuple, еще больше сокращаем код, так сказать
Ублюдские костыли! Все глаза в начале сломал, ну нахрена??
что за сочетания клавиш на 5ой минуте?
нормализуйте звук плиз, еду в тралике, на полной громкости еле-еле слышу
тише можно?
Начало 1:39
если операций много и код повторяется 1400 раз, static и массивы лучше не юзать.
Массивы(с фиксированным кол-во) это узконаправленная фича. ArrayList топ
@@mezozzoi ArrayList давно устарел, вместо него используют List
Голова закружилась от гифки
ничё не понятно
Рома себе под нос пробормотал
а ты разберись)))
Ужасная заставка в начала ролика, хотелось выключить просто из-за того, что кровь из глаз пошла. Используй статичные картинки или гифки с большей длинной пожалуйста.
нда. может пример фиговый или еще что, но ИМХО стало хуже. зачем-то создали класс там где спокойно обходились без него
...чувак ты путаешь СИНТАКСИС и КОД
дэмЭджейбл
Это и так было известно
1 случай: афтар, плохому детей учишь, уж лучше пускай юзают свич, чем массив классов, которые жрут память, да и к томуже будут пораждать промахи кеша в критичных к скоростям участкам.
В таких случаях либо массив стековых данных, либо свич, иначе стремление к красоте породит фризы на этапе продакшна, а ведь можно избежать этого сразу
Какой же мусор у вас в голове :)
я пока не посмотрел видео, но как я понял там все условия заменяют на тернарные операторы
Ну избавились вы от условных ветвлений, на что похож стал ваш код, на шифрограмму и по объёму такой же длины. Код должен быть читаемым для всех программистов. Вы б ещё на ассемблере написали такую простую задачу как ветвления. Зачем усложнять жизнь.
В данном случае изменения были не ради читаемости. Проблем с читаемостью у свитча особо нет. Все было сделано ради большей расширяемости.
Ну фиг знает. Как по мне как раз читать это легче. А
А про читаемый для всех программистов. Все кто изучали ООП это без проблем прочитают, а если человек заявляет что он программист шарпов, он по-умолачанию должен ООП изучить был.
Про зачем усложнять жизнь. Конечно, если пишется что-то маленькое, тем более одним человеком - можно как угодно писать, но вот ты действительно стал разработчиком, попал в реальный проект, скажем на моменте когда в нем уже есть 500к строк, вот как думаешь, тебе бы было проще рабобраться с отдельным модулем, или лазить по свичам, ифам и прочему? Все эти паттерны придумали как раз для того чтобы ты не тратил потом месяц разбираясь что тут и для чего.
Выключили спустя 2 минуты из за деда с костылями и кучи воды ниочем
Кода стало ещё больше :/
3 причины почему это плохо
@@rsakutin 3 причины, почему это хорошо? Чем больше кода -> больше байта на обработку, в любом случае весь программный код перекомпилируется на стандартные условия, тот же if (блоки условий), создать массив можно гораздо проще, включая методы доступа...
@@rsakutin А так же ухудшилась читаемость кода. И скорость работы программы.
Надо использовать goto, if else, switch для лохов))))
при беглом чтении иф читается как фи
не разжевал, слишком быстро
А чем паттерн "Состояние" отличается от паттерна "Шаблонный метод
"
Шутки не очень, информация очень полезная, но чел, не нужно выкрикивать, режет уши, из-за того, что выкручиваю на максимум.
я конечно только учусь, но как по мне, это просто выпендреж . больше запутал ,чем научил
Это кажется выпендрёжем до первого серьёзного, расширяемого проекта. Когда на двухсотом case'е ты перестанешь понимать что ты делаешь, а при желании что-либо поправить - убьёшь несколько часов на ctrl+c и ctrl+v.
Это как ездить на велосипеде. Он охуенен, пока ты двигаешься на нём от дома до ларька с сигаретами, а когда нужно перевезти 10 тонн кирпичей для дома - начинаешь понимать, что где-то ты проебался в своём выборе способа передвижения
@@iKolesDev прошел год и теперь я понимаю о чем видео, так как сам недавно не зная о том, реализовал без апдейта подобную систему с уроном, учетом брони и смертью противника. время "лечит" как говорится. только сейчас начинаю понимать эти маневры, так как опыта на тот момент не хватало понять. так что за комент стыдно теперь. )))
Очень полезная инфа, но визуальная подача не очень. Слишком быстро пишешь код и так же быстро скроллишь, дергаешся между сотроками, не давая времени на осознание написанного кода.
Для осознания кода существует пауза на видео. Имхо неудобства при просмотре не ощутил
@@user-qq7jc3ej6l если сравнивать с видео гайдами, например от unity, то само качество подачи и отображения кода там на порядок выше
@@apex_grove на вкус и цвет... Например многим лучше когда автор пишет код быстро и не тратит их время на выписывание каждого куска кода очень медленно
ага избавились от свич, но нагородили кучу непонятного кода, да еще и массив создали , супер.
Игорь Князь в чем проблема массива если он скрывает индексацию малой ценой (память на ссылки на объект почти не расходуется). Также код понятен любому мало мальски образованному программисту.
Самое главное это удобство редактирования кода и всегда надо это учитывать. Что бы внесение изменений не вызывало головную боль и трату кучи времени.
@@rsakutin тем что id это уникальный идентификатор. Понадобиться из игры удалить пару items из середины и все приплыли, переписывай потом за тобой и указывай id для пару сотен накопившихся вещей.
Лучшее - враг хорошего.
На 3 минуте, мой мозг больше не выдержал увиденного...
ЗАЧЕМ нужно намеренно усложнять то, что проще простого?! В простоте совершенство!
И ещё, играм нужен НЕ красивый, а ЛУЧШИЙ код! - Лучший для игры, а не для кого-то, кто вздумает его читать.
(впрочем, читающему вот такой код, где даже условные операторы заменены классами, я уж точно не позавидую...)
А для игры лучше тот код, который оптимальней, меньше засоряет память, кучу, меньше нагружает процессор.
Но как правило, чем код "правильней" и "красивее", - тем он наоборот, ХУЖЕ для самой игры!
Так например, многие стремятся избавлятся от связанности, переносить всё на события и делегаты... - а на деле потом получают в игре, торможения и глюки! А простой связанный код, работает и летает.
Да и примеры не корректны. Ну кто так будет делать программу? ну разве что, новички.
Обычно, любая однотипная обработка, и так, сразу оформляется как процедура или функция.
А ты вот возьми те же IF или Switch, и в каждую секцию, помести абсолютно разные, уникальные обработки и действия. - ну и как ты это без IF сделаешь?
Нет ну есть конечно варианты, через лямбда-выражения выёживать (на хабре было описано), но гемора, и опять же, ударит по производительности.
Через полиморфизм сделаю, для этого он и нужен. В конце я эту ситуацию описал.
@@rsakutin Я с человеком согласен - ужас. Это видео - троллинг?
Ты сейчас так это говоришь как яндере дев
Интерфейсы для лохов, давай абстрактные классы!
Профан. Не смотрите, чушь несет. Методы правильные, но не понимает зачем это делает. Аргументирует красивым кодом )... Корону побольше нарисуй, а то не поверят.
Излишнее ветвление сбивает конвеер проца, при неправильном предсказании ветвления онным. На что может потребоватся до ххх тактов. Избавление ветвления делается именно для этого.
То есть по-твоему читаемость, расширяемость и изменяемость кода не имеет значения? Для огромного числа приложений удобство поддерживания и стоимость разработки в приоритете над скоростью работы.
@@user-lx9nk7vf8c Ну не знаю, какая тут читаемость улучшилась. Автор сам это говорит, после оптимизаций... Кода стало больше, и явно он сложнее для понимания чем простой case. Единственное что улучшилось, это возможность добавления новых условий в массив, возможно даже динамически, но ты, опять же, об этом не сказал. Ну и грамотный программист, опять же, конечно скажет про конвеер и т.д. и разжует, а тут все очень поверхностно. Дилетанты...
Visual Studio на русском - жесть, исправь плиз на English
Обожаю оптимизаторов. Из маленького говно кода, который хорошо читался, сделал большой, но менее читабельный. И главное - на это было убито время, которое можно было потратить на написание нового кода.
Это не оптимизация, а рефакторинг. Это раз.
Два, потратив время на написание этого кода ты сокращаешь объем работ в будущем. Конечно, если программа которую ты пишешь это калькулятор на обратной польской записи, то ничего такого действительно не нужно, но представь что у тебя сложная система управления комплексом устройств, а к этому еще и api прекручено чтобы можно было свой UI запилить, плюс клиенты хотят с разными базами данных работать из-за того что ну купили они прокачаную версию и их MySql не устраивает теперь(ну или как в рф - меньше вопросов к твоему софту если берешь отечественную разработку). Вот как думаешь, сколько ты потратишь времени чтобы добавить поддержку пары новых устройств, переписать все запросы что ты написал для MySql на какой-нибудь Postgre так чтобы остальную логику нигде менять не нужно было, ну или найти баг, когда у тебя там свичи в 100к строк в куче мест?
@@stanislavsh6582 что такое оптимизация и рефакторинг ты знаешь, а вот что такое сарказм - похоже нет. Это первое. Второе. В погоне за красивым кодом можно дойти до абсурда, слепо следуя одним принципам и полностью забивая на другие, например на KISS. И да! Если у тебя в коде 100 к строк свичей, то твой код говно, а ты говнокодер. Прими это.
@@Midavok Как раз руководствуясь KISS и приходишь к тому что у тебя switch с миллионом case'ов или куча if'ов в коде, а методы раздуваются, няша.
Посмотри на пример кода YandereDev'а, он-то как раз не гнался за красивым кодом, и что имеем в конечном итоге? Маленькое нововведение в игру занимают по полгода.
Да блин, попробуй начать писать хотя бы платформер, добавляя постепенно новые фитчи, инвентарь игрока, систему покупок бафов, разные типы врагов и их взаимодействие друг с другом(например если моб ударит другого то они начинают друг с другом драться), ты поймешь что KISS это конечно весело, когда ты пишешь хелловорлды и калькуляторы, но когда нужно делать даже средний проект, скажем на 100к строк, то как-то уж лучше заложить в самом начале возможность для роста и развития, чем потом плеваться и переписывать все это, либо плакать, но есть катус.
@@stanislavsh6582 про 100к свичей могу заметить только, что не надо путать "делай проще" с "делай тупо". Ты либо не читал " Совершенный код", либо нихрена не понял. Печально
@@Midavok Да Господи. Так пишешь, будто никогда не имел дело с легаси, а только по книжкам с реальной ситуацией в программировании знаком. Людям ставили изначально простую маленькую задачу и они пилили побыстрее, а потом продукт оказывался успешным, в него пихали новые фитчи, и оказывается, что уже фиг что впихнешь, так чтобы все не сломалось к чертовой бабушке, потому что все же такие прошаренные, у них KISS всюду, потому давайте нафигачим глобальных переменных, удобно же из любого места можно получить доступ, давайте нафигачим синглтонов где не надо, давайте у нас вообще половина программы на статике будет, ну а фига ли, а потом у них все разваливается, они быстренько уходят в другую контору и пусть новые программисты занимаются поддержкой и развитием этого. Ну да, удобно. Зато делали как проще. Только кому и что? Проще писать такой код - безусловно, проще ли потом нормально поддерживать и развивать - да хрен там. Зато анекдоты в комментариях пишут, ишь какие молодцы.