Подробнее
I FUCKING HATE YOU AND HOPE YOU DIE > I like my IDE it's so convenient
geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор,ide,без перевода,vim,visual studio,geek,ide,vim,visual studio
Еще на тему
geek ide без перевода vim visual studio
Подробнее
I FUCKING HATE YOU AND HOPE YOU DIE > I like my IDE it's so convenient
geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор,ide,без перевода,vim,visual studio,geek,ide,vim,visual studio
Подробнее
I FUCKING HATE YOU AND HOPE YOU DIE > I like my IDE it's so convenient
geek,Прикольные гаджеты. Научный, инженерный и айтишный юмор,ide,без перевода,vim,visual studio,geek,ide,vim,visual studio
!["Smsit-NON U ИИ 9NISÍB9NWU UIAIlünOOUd HI S3UININ U SULK U3SH NIA 19VH3AV 3H1 ШЛА 1H3A0 \](http://img10.reactor.cc/pics/thumbnail/post-4905276.jpg "\"Smsit-NON U ИИ 9NISÍB9NWU UIAIlünOOUd HI S3UININ U SULK U3SH NIA 19VH3AV 3H1 ШЛА 1H3A0 \")
ну отстаньте вы от него
Хотя я не сишник(хоть и учил в универе), поэтому, может у VS тонна ультимативных фичь о которых я не в курсе.
Но в любом случае как писать огромные проекты без IDE я не знаю. И как писали проекты без VCS тоже вызывает ужас. Приклоняюсь перед разработчиками 90х, но кто сейчас так делает в 99.9% случаев либо позер, либо профан.
Правда я админ и йоба проектами там не рулю
VS банально умеет работать с шаблонами на порядок лучше, чем все перечисленные "альтернативы". Для любого сколько-нибудь крупного проекта на крестах (не путать с си, это совершенно разные вещи) это критически важно.
Например? Поведение шаблонного кода и то, что в нем используется, зависит от шаблоных параметров и может координально отличаться в завсимости от того, чем этот шаблон инстанциирован. Вот уж в чем, в чем, а в шаблонном коде тебе любая ide скажет "у меня лапки", просто из-за самой природы шаблонов.
Во-первых, потому что на сегодняшний день хоть сколько-нибудь серьезные ide работают через clangd и имеют всю ту же информацию о коде, что и компилятор.
Во-вторых, в шаблонном коде возможности ide очень сильно ограничены. Я не видел чтоб vs делала что-то чего не может какой-нибудь QtCreator или Rider. Хотелось бы узнать, о каокй-такой vs-магии здесь речь
Знаю, что для JVM-based языков у джетбрейнсов возможности работы с шаблонами - полные. Ну, то есть, иде всегда совершенно точно знает, какие ограничения и типы в каком конкретном месте, без "но" вообще.
Чисто 2 примера с одним и тем же проектом на cmake.
1)Вс код - норм структуру проекта парсило
Вижуал студия - часть файлов тупо не было видно(на последней версии студии все окей)
2) вс код, проект собиралс без проблем
Вижуалка - чет там себе запичала левое в .vs папку, и проект тупо переставал собираться. Сносишь папку, собираешь, все ок.
И на кой хрен такая даже потенциальная ебля на проекте?
Я был на проекте (легаси из 90х), где целый Дебиан был превращен де-факто в ИДЕ под конкретный проект (с вимом в качестве редактора).
И там были гигабайты объектно-ориентированнного кода на Pure C, еще и все это под CVS
Это, конечно, были не современные студия или штуки от джетбрейнсов, однако, жизнь упрощали порядком.
Но когда это какое-нить сетевое приложение на микросервисах, то тебе нужно и к докеру подключится, и к БД(локальной и на стейдже, а бывает и проде), и дебаггер с прокидыванием параметров и ENV переменных и лабиринты папок обходить. И на это всё еще нужно максимально быстро новых девелоперов садить. Тут уж без IDE я не знаю как.
Какие тебе нужны графики и сервисы в нормальной синглплеерной игре? Скажи лучше что кроме фронтэнда и UML в руках нормального программирования не держал.
Когда игру пишешь у тебя есть только время и потоки. И за время нужно успеть обсчитать логику, отрисовать кадр, обслужить звук и прочитать ввод. Если мультиплеер - то вместо обсчитать логику подставить синхронизацию с сервером.
Так как процессоры сейчас мощные, а 3D движки пишут редко (это математику ж знать надо, такому на курсе жабаскриптеров не учат) то времени у тебя дохуя, и логику можно хоть в луа без джита вынести.
Резюмируя - возьми LÖVE2D. любой редактор и посмотри как игры делают перед тем как в комментах пиздец писать. Твоего бэкграунда педвуз + курсы фронтэнда должно хватить. Может за умного в будущем сойдёшь.
- нет это, это как раз мышление, когда человек смотрит не то что на работу под другим взглядом, а на жизнь в целом. Постоянно находясь где-то в стороне, даже когда с ним ведешь разговор.
"Когда игру пишешь у тебя есть только время и потоки. И за время нужно успеть обсчитать логику, отрисовать кадр, обслужить звук и прочитать ввод. Если мультиплеер - то вместо обсчитать логику подставить синхронизацию с сервером."
- к чему это? Если тут про удобство шла речь, а не про количество времени для решения N задач в условный отрезок времени работы кода. К тому же IDE, та же лагучая студия, как раз таки помогает решить такие проблемы.
"Так как процессоры сейчас мощные, а 3D движки пишут редко (это математику ж знать надо, такому на курсе жабаскриптеров не учат) то времени у тебя дохуя, и логику можно хоть в луа без джита вынести."
- Из-за такого мышления иногда знатно подгорает, когда тот же луа используют неуместно, не понимая того что это в первую очередь скриптовый язык, а точнее дополнение к более мощной платформе. Это как на JS писать анимацию... а потом удивляются, а хули все так лагает. Но ладно, раскрою секрет, если для написания той жеигры использовать почти любой крупный движок, начиная с Unity и заканчивая Unreal, то если не использовать готовые ассеты а писать свои, придется очень много писать. Особенно если работать с такой технологией как Вулкан.
"Резюмируя - возьми LÖVE2D. любой редактор и посмотри как игры делают перед тем как в комментах пиздец писать. Твоего бэкграунда педвуз + курсы фронтэнда должно хватить. Может за умного в будущем сойдёшь."
- Олтичная комуникация, ничего не скажешь. Я не думаю что вы можете судить о моем образовнии и роде деятельности, ставя себя выше, даже не зная меня. Но пример показательный, когда в пример кидается низкопрофильный движок с минимум зависимостей. В то время когда в коментари приведенном выше, прямо уоминалось о работе с более сложными вещами где много зависимостей
"Какие тебе нужны графики и сервисы в нормальной синглплеерной игре?"
Который был задан в контексте твоего конкретного предложения
"Я бы хотел посмотреть на этого великого человека, который в редакторе может заниматся визуализацией всех графов и подтягивания сервисов."
На основании которого, как и остального содержания твоих комментариев, вполне можно сделать о твоем понимании темы, образовании и профессионализме.
Для поддержания беседы задам еще пару наводящих вопросов, на которые ты не ответишь.
Как использование готовых ассетов сокращает количество написания кода для больших движков?
Какой функционал требуется реализовать при использовании технологии вроде вулкан при использовании движка, по сравнению с применением OpenGL2+ или Direct3d9+?
Чем разработка игры под низкопрофильный движок принципиально отличается от реализации такой же игры под полнофункциональный движок?
-- Я имел в виду графы, а не графики. Это относится к прожорливости приложения и его дебага, те же зависимости в IDE. Но если говорим про игры, то вот банальный пример - граф состояний, банальная цепочка диалогов или других событий, который тебе может дать готовый движок. А реализовав его API, ты можешь все это расширять своими событиями
"На основании которого, как и остального содержания твоих комментариев, вполне можно сделать о твоем понимании темы, образовании и профессионализме.
Для поддержания беседы задам еще пару наводящих вопросов, на которые ты не ответишь.
Как использование готовых ассетов сокращает количество написания кода для больших движков?
Какой функционал требуется реализовать при использовании технологии вроде вулкан при использовании движка, по сравнению с применением OpenGL2+ или Direct3d9+?"
Продолжайте в том же духе, уверен у вас прекрасная дедукция. Но я пожалуй отвечу, из вредности и хвастовства.
"Как использование готовых ассетов сокращает количество написания кода для больших движков? " - наверное не нужно писать свою физику или создавать свои костыли с освещением? Многие движки берут и внедряют тот же havok и просто его расширяют для своих нужд.
"Какой функционал требуется реализовать при использовании технологии вроде вулкан при использовании движка, по сравнению с применением OpenGL2+ или Direct3d9+?" -- Свои контроллеры/сервисы для работы с ресурсами потоков и их синхронизации. Так как я избалован автоматической очисткой и прочими прелестями закулисной работы, вулкан для своего баловства я отложил на потом. Ибо там все предоставлено на низком уровне и моего понимания хватает разве что для работы с простым рендером. И то нужен ящик алкоголя и седативных
"Чем разработка игры под низкопрофильный движок принципиально отличается от реализации такой же игры под полнофункциональный движок?"
Тут не отвечу ибо разработка игр это скорее хобби и тут я много не отвечу. Хотя могу ткнуть палец в абстракцию, ибо она везде будет масштабироваться от сложности проекта
"Многие движки берут и внедряют" - Ты уж определись, что у тебя движок, а что у тебя ассет. Физика либо прикручена в самом движке, либо прикручивается через плагин. Вулкан точно так же. Плагин это не ассет. Ассеты относятся к игровому содержиому - модели, текстуры, тайлы, интерфейс, карты, это ассеты. Скрипты на инвентарь это ассеты. Физика - это не ассет. Сорян, но вопрос был на понимание термина. И ты не ответил.
"Свои контроллеры/сервисы для работы с ресурсами потоков и их синхронизации." - Ты хочешь сказать, что анриал не предлагает тебе встроенный функционал по управлению ресурсами и порядком отрисовки? А что он тогда вообще делает?
В движках вообще. и в крупных движках в частности - управление ресурсами это главный их функционал. Что бы включить другой рендерер на всех движках семейства анрилов надо просто выбрать другой рендерер в опциях. И, иногда, переписать шейдеры. Садись, два.
"ибо она везде будет масштабироваться от сложности проекта" - А вот тут почти правильно ответил, только не тот вопрос который задан. Это не отвечает на вопрос "Чем отличается разработка игры на разных движках". Правильный ответ - возможностями движка.
На предложенном мной LÖVE2D создать игру в среднем сложнее для программиста чем на жирных движках, потому что гораздо меньше функционала реализовано с завода, и гораздо больше надо делать ручками. Зато понимая того, что и как ты делаешь он даёт больше. Я его не зря посоветовал вместо написания собственного движка. И не для того что бы тебя ещё больше обидеть - после того, что с тобой природа совершила я буду в любом случае смотреться бледно.
Если вы считате себя тру програмистом, а всех остальных низкопрофильными фронтенд разразботчиками, даже не имея малейшого представления чем именно они занимаются в своей работе, то это уже ваши личные нюансы. Котрые к слову принижают ваш уровень как специалиста, ибо вы не можете в банальную коммуникацию, даже если вы отличный технический специалист в своей предметной области.
Но тем не менее я отвечу на интресный тезис -
"Физика либо прикручена в самом движке, либо прикручивается через плагин." - Вы правы но только от части, тот же UE оперирует такими понятиями как физические ассеты(объекты физики), которые могут быть скачены таки написанные и смоделированные ручками с написанием своих особенностей
Я отнюдь не считаю всех вокруг себя сколько нибудь ущербными - эта логическая ошибка возникает из за вашей проекции на меня вашего мышления. То что лично вас я считаю недостаточно профессиональным - извините уж, это не моя вина.
Если мои скромные познания английского меня не обманывают вот тут:
https://dev.epicgames.com/documentation/en-us/unreal-engine/physics-asset-editor-in-unreal-engine
говорится что физические ассеты описывают поведение конкретных объектов внутри игрового мира и включают такие понятия как объёмы коллизий, констрейнты и вполне возможно скрипты. И так как они являются аттрибутами объектов внутри игрового мира они вполне попадают под понятие ассета. Как и скрипты инвентаря, которые я приводил выше. Они не предназначены для изменения логики всего движка или для замены физического движка на какой нибудь другой.
То что на реакторе сидит элитный батальон мамкиных программистов я как то уже просёк и время от времени просто угораю. Тут же такие элитарии, что даже один банальный слой иронии распарсить не могут. Мой плюс тебе, на счастье.
2) Даже если ты просто синьёр, то рано или поздно кто-то уходит с проекта и нужно вводить в курс нового человека.
3) Если ты пишешь в одно рыло, то либо это твоя личная поделка, либо ты на больших нормальных проектах и не работал. Если только ты не Крис Сойер.
2. Даже если ведомый попадает ко мне в приказном порядке, его проблемы будут решаться индивидуально, в зависимости от его навыков, предпочтений и желания расти. Если я не имею отношения к найму этого человека, никто не может его повесить на меня против моей воли. А дрессеровать обезьян по типу "открывай иде, сюда нажимай, сюда не нажимай" это совсем не мой стиль. Я скорее откажусь от ведомого, а возможно и от работы, чем буду таким заниматься.
3. Здесь три логические ошибки. Во первых - не из одного моего утверждения нельзя сделать вывод, что я пишу в одно лицо. Я всё время говорил о работе в комманде.
Во вторых - в мире очень много маленьких проектов, которых мейнтейнят один два человека, и которые работают повсеместно. Количество разработчиков не говорит ни о качестве кода, ни о личных способностях программистов.
В третьих - размер проекта никак не коррелирует ни с вопросом выбора ИДЕ/редактора - линукс был написан преимущественно в редакторе, в то время как для notepad использовали Visual Studio - ни с возможностью совместного программирования.
Ну и на последок - ты, вполне логично, ошибся. Я имел опыт работы в команде, я имел опыт менторства и имел опыт организаторской работы. Потом я поимел это всё, и сейчас анэмплойед и пилю свои маленькие фан проекты в одну каску. Так что я видел эту кухню с разных сторон.
Программисты стреляют себе в ногу по приколу, потому что не боятся устранять последствия. Befunge с Malbolge придумали программисты. И придумали как с этой пулей в ноге жить. И гордятся этим.
А тот кто боится стрелять, потому что может в ногу попасть, и страдает, когда на стэковерфлове не те поправки написали - это и есть рукажоп.
Тюринга тоже залечили и до самоубийство правительство довело. Это не говорит о том что он был плохим математиком. Скорее о том, что в британии законы были хуйня. Друга твоего это не утешит. Тюринга впрочем то же.
Но если вы считате, что прописывать формы для сайтиков (пользуясь чужими фреймворками, языками, иде, библиотеками и браузерами) - вот оно настоящее программирование, вот он передний край прогресса - то флаг вам в руки.
у тя чо за моник? 160 даже в задрипанный 1080p прекрасно влезет с нормальным размером шрифта
если ты профессионал, у тебя должно быть нормальное рабочее место и современное оборудование, а не с калькулятора в проекте копаться
Выше правильно сказали: "стоит уважать коллег, которые будут читать и ревьювить твой код".
у всех должно быть нормальное рабочее место, на него и надо ориентироваться. если тебе вдруг понадобилась всякая экзотика - это твои проблемы
Вот ты и есть этот васян, который кричит, что его все угнетают. А сам заставляешь людей глазами по монитору километры наматывать.
когда ты в последний раз видел в продаже офисный моник меньше 1080p?
вот его и можно взять за бейзлайн
а если ты решил на полэкрана порнушку врубить, еще на четверть мессенджеры, а в оставшемся пространстве у тя иде - это какая-то хуйня, а не нормальная работа. поставь себе 2 моника
ревью можно по-разному делать, и тулзы это позволяют. хочешь - бок о бок, хочешь - одно под другим
это у тебя, готов поспорить, моник не стоит вертикально. а значит полно места вширь - ну так пользуйся им
и не вводи сам себе никаких дополнительных ограничений, ноги которых растут еще из vt100
лучше тот код, который форматировался осознанно. "вот это я хочу выделить, оно важное, а вот на это похуй"
а не когда строчки пилятся лишь бы как, только бы сраный линтер уже отъебался
и похуй, что это строка вида log.error("многабукав на которые всем похуй, важен сам факт наличия логирования")
Так делать не надо. Хотя бы потому, что не понятно, что пишется в логи. В итоге, когда видишь в логах ошибку, то не понятно, это вот в этом месте сломалось или где-то ещё. Приходится искать по тексту. Плюс с большой вероятностью такое сообщение об ошибке станет неактуальным, потому что его не обновят, потому что оно не перед глазами. Явное лучше неявного.
это сообщение обновят, когда увидят В ЛОГАХ, что оно какое-то не такое
похоже, ты уже понял, что отстаиваешь дурацкую позицию, но по инерции продолжаешь
> вот прям глазами ты будешь искать этот текст?
Сам придумал про глаза, сам опровергаешь.
> похоже, ты уже понял, что отстаиваешь дурацкую позицию
Похоже, для тебя все позиции делятся на твою и дурацкие.
любой нормальный человек воспользуется поиском, а в этом случае как раз проще искать цельную скопированную строку, а не разбитую на куски
так в чем проблема, которую ты пытался привести как контраргумент?
Ну знаешь ли, не все открывают код на весь экран. Некоторым панельки с файлами, вкладками, бд и другими нужны. 160 это очень много.
Просто лол. Подумаешь, аргументы функции не видны без скроллинга. Зато несколько байт на новой строке и выравнивании сэкономил.
есть код важный сущностный, а есть хуйня, которую мне практически никогда не интересно видеть полностью, а если вдруг стало надо - мне не в падлу проскроллить. зато всё остальное проще охватить взглядом
но нет! есть ебланы вроде тебя, которые пытаются ввести тупорылые ригидные ограничения. и это читаемость только портит
У меня две панельки - список вкладок и список файлов в проекте. Обе панельки всегда важны. Мне их что, каждые пару секунд открывать и закрывать?
В основном такая проблема возникает именно в строках, где вся строка важна. Например, в описании методов и вызовах. Если ты изучаешь какой-то класс, чтобы его использовать, тебе же важны все аргументы методов. Или когда смотришь на вызов метода, тебе же важны все аргументы.
Чел, если у тебя в коде есть строчки по 160 символов то херовый из тебя программист. Без вариантов. Тут даже не в мониторе дело.
читать код удобнее, когда законченный его кусок весь перед глазами. если вы жуёбки не заметили, моники растут вширь, а не в высоту. ничего на мысль не наводит?
и да, мне тоже приходится и из консоли сидеть, и на проектор код выводить, но я не стремлюсь его весь тут же подогнать под такие экзотические условия и закоммитить.
потому что, блядь, помню в каких типичных условиях работает большинство.
и это не 25*80
> вы заебали лесенки свои сраные делать из кода
Лесенки из кода -- это не про разбиение строки на несколько, а про много вложенных циклов/условий. И да, это признак того, что код пора разбить на функции или как-то иначе переписать для более простого чтения.
"всякая " +
"хуйня " +
"типа вот такой"
про вложенность речи не было, я не предлагаю искусственно превращать всё в однострочники
Мониторы в ширь растянуты чтобы фильмы смотреть. Доказано что читать удобнее и интереснее узкие тексты. По этому в книгах иногда текст печатают в 2 колонки. И кстати, сами книги в вертикальной ориентации.
а если печатать текст на развороте книги перескакивая через корешок - получается не удобно
это нерелевантные факты. много ты знаешь иде, которые код в 2 колонки выводят?
как только появилась потребность печатать листинги кода - о колонках забыли.
мб ты видел такие портянки с матричных принтеров
и вот тогда вводить ограничения на длину строк кода имело смысл - чтоб влезал и в моник и в принтер
но щас и код печетать перестали. а ограничения всё еще кочуют из проекта в проект, обрастая мифами, что кто-то доказал, что так лучше.
нет, это ограничения старого железа и софта
так вот, нихуя! никто ничо подобного не доказал, это следствие экономии при печати газет
при написании кода от колонок отказались сразу, ибо дичь. ограничения ширины поначалу имели смысл, исходя из тогдашнего железа, теперь тоже нет
Какой экономии? Что ты экономишь печатая колонками? Текст будет занимать один и тот же объём.
первые сайты тоже по привычке верстали так же, потом поняли, что теперь пустое место ничего не стоит, стали добавлять "воздух", что улучшает восприятие
Как экономишь, если текст будет занимать один и тот же объём?
Открой любой новостной сайт, там будут колонки. А когда открываешь статью, статья будет по середине, не на весь экран в 160 символов. Потому что так неудобно читать. Никто и никогда не пишет тексты в 160 символов в ширину.
ты наверняка видел справочные материалы всякие - доки, маны - вот их как верстают? без всяких ограничений на длину строки.
еще раз повторяю: никто никогда не доказывал, что колонками читать удобнее, были попытки это доказать, которые провалились
найдешь пруф - приходи. я заибался одно и то же повторять
Ты видишь то что хочешь. Они так делают потому что так правильно. Так все делают, никто от края экрана до края текст на сайтах не делает.
Документации которые я читал были отформатированы так же как и другие сайты.
Доказывали:
Dyson и Haselgrove "The Influence of Reading Speed and Line Length on the Effectiveness of Reading from Screen" (2001)
> For adults, it is suggested that medium line lengths should be presented (approximately 65 to 75 CPL)
всё как я говорю, лол, скролльте чаще - будет вам щастье
anyway, код - эт не совсем текст, другие токены, подсветка, регулярный синтаксис
всё сделано для того, чтобы можно было легко выхватить суть.
и вот я, автор, тебе еще упростил эту задачу, убрав на хуй не нужную второстепенную инфу за экран - что в этом плохого? но она всё еще легкодоступна через скролл
иде делает то же самое с коментами - сворачивает их с глаз долой, оставляя кнопочку с плюсиком. ну, если настроить.
это тоже плохо?
А почему коллеги это в сиай пайплайн не встроили? А тебя они в таком случае уважают, раз требуют от тебя символы считать? А таких коллег точно требуется уважать? Или мы будем дружно дрочить в кружочке и притворяться, что сейчас на дворе не 20-е годы 21-го века, тратя время на ручной энфорс гайдлайнов вместо написания кода?
кабы да, можно делать простые вещи из иде, и иногда тыкаться в консоли. ну или взять гуёвый инструмент, заточенный под конкретную. почему бы нет?
кроме того, тортойз не будет индексировать весь проект при открытии, когда ты там одну буковку поменял в блокноте
Некоторых функций в IDE ещё просто нет. Например rebase с выбором коммитов.
Потому, пользоваться на постоянку можно чем угодно, но с консольным управлением тулзами надо быть хотя-бы знакомым.
В TortoiseSVN, TortoiseGIT, в основном, на каждую команду в консоли тупо присрали по кнопке в интерфейсе. Интуитивности нет, всё равно надо читать мануал по VCS. Но тут ещё надо угадать, на какие кнопки повесили описанные в мануале команды. Так проще напрямую в консоли набрать эти команды! Так хоть история сохранится, копипастить ещё можно.
ИМХО черепахи интерфейс не дожали, вышло сложнее и неудобнее, чем в консоли.
А про саму прогу не знаю. Не сошлись характерами :)
Я к примеру пушу, коммичу, ищу коммиты и смотрю мелкие диффы в консоли ибо так удобнее чем запускать вс код.
Но большие коммиты или дифы, это только вс код, иначе это превращается в полотно текста. Да и правки часто вношу через него же.
У нас на проекте была другая хрень, часть разрабов сидела на vi, а мы на neovim. Первые говорили что неовим нахуйненужон, но когда им показали что он умеет на данный момент (там тонна плагинов накинута была) - "оо, круто, оо а это удобно/быстрее..." но после продолжали на vi сидеть и говорить что неовим нахуйненужон
Или в ситации, когда фикс простой но многословынй, можно не расписывать гайд, а просто скинуть что-то типа такого "git rebase -x 'git commit --amend -m"JIRA-69420 $(git log --format=%B -1)"' HEAD~3".
Я сам люблю кнопки и окошки, но вот конкрено для гита, лучше чем териминал интерфеса нет. Кроме блейма, блейм блейм удобнее в ui
Вместо того, чтобы указать, какой именно объект тебе нужен - нет, ты будешь, сука, перебирать For Each всю ёбаную коллекцию объектов...
А по-другому - хуй, никак.
Вот что мне вынесло мозг, так это отсутствие каких-либо циклов в Power Query. Точнее они там есть, и я даже смог их применить, но там всё настолько через задницу, что обновление коротеньких таблиц занимает около минуты.
Если что, я не программист, просто решил сваять в эксельке лист персонажа для ролевой игры и чёт психанул мальца
Вы хотя бы перемененные называйте правильно! *плач*
Видел еще больший холливар - на маке или на винде лучше писать андроид приложения из под Андроид студии. Постоянно срачи эти воочию наблюдал
А от IDE давно отвык. Например, у нас сборка и запуск включает создание образа диска и запуск в qemu (эмуляторе). Собирается Makefile, в котором примерно стописят разных целей. Поэтому хочешь не хочешь, а юзает консоль для запуска, это вам не одну из нескольких целей выбрать и f5 нажать. CLion умеет парсить цели из мейка, но когда есть всякое колдунство, то не знаю, насколько он справится.
Поэтому vscode
Однако это действительно единственное отличие между современным редактором и современной же IDE (после изобретения lang серверов)- в редакторе нет окошка где перечислены все исходники проекта. Всё. И этот факт не помещается в черепной коробке большинства хомячков у которых от консоли голова взрывается.