В предыдущей статье имел наглость использовать CLion в качестве IDE. И тут же прибежал человек с вопросом: ой, проприетарная платная поделка, продался, зажрался, итп. Справедливости ради, на Хабре такой комментарий был всего один, но в реальности их тысячи. Например, крайний действующий аккаунт на ЛОРе, у меня зарегистрирован с 2010 года, и в почти каждой дискуссии с участием какого-то несвободного софта начинается этот ад. Понятно что никому я ничего не докажу, но редким бредущим мимо может помочь.
Статья условно делится на две части: социально-мотивационная и техническая (как собирать CMake в Windows под различными IDE).
Откуда всё пошло
В основу статьи лёг вот этот комментарий из прошлой статьи: "Если подкаст для начинающих и непрофессионалов, то почему не учли лицензию IDE :(" и далее по тексту.
Статья сделана по результатам стрима на Твиче и вашего фидбека на нём. Запись есть на YouTube. Эта статья — не расшифровка подкаста, а продукт его осмысления.
Исходный посыл
Вначале, давайте проверим валидность исходного предположения: софт — это дорого. Если зайти на сайт, то окажется, что CLion стоит 8.90 баксов в месяц. 580 рублей. Понятно, что для человека, который не зарабатывает программированием на жизнь — это иногда может показать приличной суммой, которую можно потратить на что-нибудь более полезное. Купить поесть, например.
Для профессионала всё совсем по-другому, но давайте вот оставим эту тему. Журналист отличается от работника отдела маркетинга компании-производителя софта или игры тем, что он не продвигает политику Партии, не делает шаги для продвижения продукта. Он говорит как есть. Как это всё на самом деле, как журналист по-настоящему видит вопрос. То же самое и с настоящими евангелистами.
Сущность явлений, и лет вереница,
Лица друзей, и маски врагов,
Ясно видны и не могут укрыться
От взора поэта — владельца веков.
Свет дальних звезд и начало рассвета,
Жизни секреты и тайны любви,
В миг вдохновения солнцем согретый —
Все отражается в душах поэта —
В зеркале мира…
(с) Константин Никольский, «Зеркало Мира»
Если действиетльно интересно, как CLion увеличивает ваш доход — вы найдете к кому обратиться, а мы тут о другом.
Типология
Вместо этого рассмотрим группы людей, которых максимально бомбит от закрытого софта.
Как вы уже поняли, я нифига не социолог, и имею только ту типологию, которая выработалась в жаре форумных разборок. Она имеет только то преимущество, что отнести человека к какой-то группе можно практически не включая мозг, посмотрев на первые два комментария.
Итак, люди бывают:
- Борцы за свободу и опенсорц
- Честно заблуждающиеся
- Животные
Варианта неправоты автора предлагаю не рассматривать. Я — это другое дело.
Борцы за свободу и опенсорц
Самые чистые и светлые — это борцы за опенсорц. Я и сам из тех, кто услышав слово "Linux" постоянно поправляет, "не Linux, а GNU/Linux". Проблема в том, что реальный мир ни разу не чёрно-белый. У нас есть некое количество свободы, и это — ресурс, который в случае необходимости можно использовать. Как пошутил (или нет) кто-то из менеджмента Mozilla, "зачем нам кредит доверия, если мы не будем его тратить?".
Пример: был такой человек, Мигель де Иказа. Он сделал Gnome и приложил руку к формированию дестопного GNU/Linux таким, как мы его знаем. А потом его выпихали из сообщества, а Столлман назвал его "предателем свободы":
«Miguel de Icaza, по существу — предатель Free Software community. <...> Проект нацелен на обустройство функционирования якобы „опенсорсных“ программ на платформе Windows; тем самым бесценное время разработчиков уводится от свободных платформ»
И где теперь Мигель? Он и его команда работают бок о бок с одним из величайших проектов последних лет — переносу .NET на GNU/Linux под пермиссивными лицензиями. Он верно потратил своё время.
На стриме я убил не менее двадцати минут на то, чтобы запинать CMake под Visual Studio Code. Не получилось. А в бесплатной, но несвободной Visual Studio, получилось с первого раза. Это именно то, что мы так часто получаем при попытках использовать свободный софт: в опенсорце, по понятным причинам, нет времени продумывать end-to-end сценарии и заботиться о продукте целиком. Спасибо разработчикам уже за то, что сделали хоть что-то. Но для нас как для пользователей всё равно остаётся морально-этический выбор: либо выбрать свободу и потратить на запинывание свободного софта много времени, или напротив — потратить нашу свободу на покупку времени, которое можно потом пустить на какие-то добрые дела.
Поскольку этот вопрос выходит за рамки решаемости техническими вопросами, здесь и закончим. По-настоящему идейный человек верен своей идее.
Животные
О, а вот от этой категории меня бомбит.
"Специфическими особенностями человека, отличающими его от других животных, являются прямохождение, высокоразвитый головной мозг, мышление и членораздельная речь. Человек изучает и изменяет себя и окружающий мир, создаёт культуру и собственную историю." (с) Википедия.
К сожалению, в разговоре об IDE зачастую оказывается, что собеседник не способен к самостоятельному мышлению, вместо членораздельной речи мычит "а мне и так норм" и жрёт что дают. Из-за прямохождения его легко спутать с человеком, но не ошибитесь.
На этих существах ездят все, кому ни попадя. В играх им продают лутбоксы и DLC с ностальгической музыкой. В редакторах их сажают на разные анально оккупированные штуки, имеющие целью привязать пациента к конкретной среде, экосистеме, и так завендорлочть, что никакого феназепама не нужно. Они всё съедят. "А мне и так норм."
Важно добавить, что ездят по ушам не только маркетологи, но и просто тролли, либо натуральные клинические шизики. Шизиков много, вы не поверите сколько.
Например, помните манифест, который недавно выложил Никитонский (точней, его перевод на Хабр): Моё разочарование в софте? Как у меня от него бомбит. Искренне надеюсь, что Никитонский это всё писал чтобы знатно потролить, а не на самом деле.
Глядите какие там тезисы:
- Всё невыносимо медленно — современный телефон мощней компов, которые отправляли людей на Луну;
- Всё ОГРОМНОЕ — Андроид весит 6 гигабайт;
- Всё гниёт — старые девайсы не работают или работают плохо;
- В программировании хаос — посмотрите на графы зависимостей в npm и left-pad.
Троллинг троллингом, а кому-то может быть невдомёк, что размер исходников "что привели человека на Луну", то есть Аполлона-11, такой, что автор вряд ли бы захотел их читать.
Что современные операционки определяют любое оборудование и имеют в себе всё на любой случай жизни. Что тормознутость девайсов привела к чудесной ситуации, когда мерсссские капиталисссссты почеаслись и разивили железо до современного уровня, благодаря чему у нас в кармане и лежит мегадевайс на все случаи жизни. Даже полотенца не надо, оно есть в Google Play. Упомянутый npm позволяет в час обычному человеку писать невообразимой сложности вещи, которые раньше заняли бы годы.
И вот всем этим товарищам, которые "жрём что дают", внезапно в голову начинают прилетать мега-идеи из списка выше. Давайте распространим на IDE:
- У приложений на Electron (Visual Studio Code, Atom) буковки появляются на экране слишком медленно, то ли дело vim или emacs;
- Eclipse IDE тормозит;
- Вообще, тормозит Java — вместе со всем, что на ней написано, включая NetBeans, IDEA и Clion;
- Любые IDE тормозят жрут проц просто так;
- Проприетарщина — зло;
- Список можно продолжать.
Этого списка уже хватит, чтобы капитально съехать крышей. Не верьте всякой фигне. Если vim лучше Eclipse (или наоборот) в некоторых кейсах, то это точно не потому, что вимеров соседи облучают микроволновкой, а эклипсеров ночью похищают пришельцы.
К сожалению, в результате долгих сетевых диванных войн было в точности установлено: диалог тут можно не вести. Человеку — человеческое, а животному — животное. Так устроена жизнь. Вероятность, что кто-то прочитает эту статью и одумается крайне мала, immolate improved.
Честно заблуждающиеся
Теперь мы закончили с крайностями: особо умными из секты Столлмана с одной стороны спектра, и не очень умными животными с другой, давайте поговорим об обычных людях.
Первое заблуждение в том, что мы каким-то образом прибиты гвоздями к IDE. Это пошло с тех времён, когда люди использовали какие-то Delphi 7 и древние версии Microsoft Visual Studio. Говорят, в новой Вижуалке всё стало хорошо с проектными файлами. Привет-привет, сейчас на дворе 2018 год, рабства больше нет.
Чтобы избавиться от рабства нам свыше дан CMake: тулсет из кроссплатформенных опенсорсных утилит, который позволяет собирать, тестировать и паковать приложения.
Это всё ещё ничего не говорит новичку и руки тянутся к IDE. Всё это от страха и непонимания происходящего. Я сам родом из джавы, и поэтому хорошо знаю, как расширяются глаза человека, в первый раз увидившего pom.xml.
Давайте разберёмся, из чего состоит созданный в прошлый раз проект, и как его построить во всевозможных разных IDE.
Состав файлов:
Шейдер у нас компилируется прямо в рантайме, функцией D3DCompile. Работает D3DCompiler из DirectX SDK (который теперь Windows SDK). Никакого IDE для его сборки не нужно.
main.cpp — это единственный файл, который надо собрать. И собирается он с помощью информации, которая целиком и полностью находится в CMakeLists.txt.
В обратную сторону: есть CMakeLists.txt, который говорит нам, что именно мы собираемся скомпилировать. В нём прописана сборка main.cpp. Этого хватает, чтобы скомпилировать проект. После компиляции получается exe-файл, который после запуска собирает и шейдер, и показывает его на экране. Всё предельно просто, IDE в этой цепочке не участвует и может быть любым.
IDE не обязательна. Вообще. Что тут непонятного?
Сборка
Подготовительные моменты
Как всегда, подготовка занимает чуть ли не большую часть процесса. Нужно уяснить несколько вещей.
Предполагается, что всё делается на основе Msys2, который мы устанавливали в прошлый раз. Если это не так, расхлебывать придется самостоятельно :)
Как установить CMake и Ninja
Чтобы мочь что-то собрать, необходимо установить CMake, если вы это ещё не сделали.
- Качаем с сайта: https://cmake.org/download. У меня cmake-3.12.2-win64-x64;
- Распаковываем и добавляем в виндовую переменную окружения PATH путь до места, где лежит cmake.exe;
- Качаем с сайта генератор ninja самой свежей версии;
- Распаковываем и тоже кладём куда-нибудь в PATH.
Как редактировать PATH, чтобы не поехать кукухой
Первый способ всем известен: win+pause -> Advanced system settings -> Advanced -> Environment variables. К сожалению, даже в Windows 10, в которой добавили редактор переменной PATH, это всё ещё не очень удобно.
Если вы часто пердолитесь с PATH, использование стандартного окна редактирования очень действует на нервы. Советую использовать Rapid Environment Editor — он бесплатный и сильно экономит нервы.
Как подключать DLL из MinGW в режиме разработки
Чотбы приложуха запустилась, нужны dll файлы как минимум из mingw64\bin.
К сожалению, я так и не смог найти действительно удобного решения для подбрасывания библиотек из MinGW в PATH. Если какой-то мудрец в комментариях можект рассказать, буду премного благодарен.
Сейчас самым простым кажется подкладываение bin-директории MinGW прямо на первое место в PATH. (В случае Visual Studio, можно и просто набросать библиотек в каталог сборки.) К сожалению, у этого способа есть огромный минус: часть софта в Windows начинает отваливаться сразу же после модификации PATH. Например, у меня перестал запускаться Overwatch, а это совершенно фатальная штука.
Если вы так же, как и я, живёте в компьютере, а не только включаете его в рабочие часы, предлагается следующая схема: перед началом программирования добавлять MinGW в PATH, а после — убирать. Для облегчения процесса нужно сделать два батника, которые можно запускать двойным щелчком:
before.bat:
setx path "Z:\msys64\mingw64\bin;%path%"after.bat:
setx PATH "%PATH:Z:\msys64\mingw64\bin;=%"
Как подключать DLL в режиме "тестового релиза"
Ясно, что предыдущий способ работает только пока mingw64\bin находится в PATH, то есть только на компьютере разработчика. Да и там даже, не всегда хочется уродовать PATH. Если же это запустит обычный человек (или мы сами после запуска after.bat), то произойдет нечто вроде:
Самый простой способ решить эту проблему — подложить нужные dll рядом с исполняемым файлом. Но для этого нужно узнать, какие dll используются!
У нас уже есть для этого некие утилиты производства Microsoft.
- Посмотреть полный список работающего приложения можно было бы с помощью ListDLLs, но оно не показывает то, что ещё не загружено.
- Если сделать Tools -> Visual Studio Command Prompt,
dumpbin /dependents "Z:\game\build\Mingw64-Debug\src.exe", то оно покажет только dll самого первого уровня. Иначе говоря, если докинуть только то, что подсказывает dumpbin, то после запуска всё ещё будут ошибки — просто они будут про другие DLLки.
Чтобы побегать по зависимостям в глубину, есть вот такой скрипт, который можно выполнять прямо из командной строки (msys2, cygwin, итп — достаточно чтобы там внутри был установлен python2/3 и objdump).
- Качаете скрипт mingw-bundledlls,
- Кладёте рядом с экзешником,
- В текстовом редакторе в массив
blacklist = [добавляете наши кусочки DirectX:d3d10.dll, d3d11.dll, d3dcompiler_43.dll, chmod 755 ./mingw-bundledlls,- Чтобы посмотреть использованные dll:
./mingw-bundledlls ./src.exe(ну, любой экзешник, который вам более интересен), - Чтобы автоматически скопировать и положить рядом:
./mingw-bundledlls --copy ./src.exe - PROFIT: экзешник запускается и просто так, двойным щелчком по exe-файлу, и из Visual Studio.
Есть ещё разные хитрые способы подрядить CMake сам копировать dll, но если начинать углубляться в вопросы дистрибуции, то так можно это статью вообще никогда не закончить.
Сборка вручную
- before.bat
- Пуск -> Выполнить -> cmd.exe
cd /d z://game/srccmake -G "Ninja" -D EXECUTABLE_OUTPUT_PATH="bin" -D CMAKE_CXX_COMPILER="Z:/msys64/mingw64/bin/g++.exe" -D CMAKE_C_COMPILER="Z:/msys64/mingw64/bin/gcc.exe" .- ninja
- Запускаете сгенерированный в bin файл сразу, или подкладываете dll по инструкции выше и выполняете after.bat
Мы докзали, что не привязаны к IDE вообще.
Сборка в Visual Studio
Но всё-таки, разрабатывать без IDE — не дело. В прошлый раз мы уже собрали тестовое приложение с помощью CLion. Но это ведь платная проприетарщина и зашквар, верно? Забудем. Теперь только свободка.
В Visual Studio последовательность необходимых действий супер простая.
- before.bat
- Запустить Visual Studio;
- File -> Open -> CMake;
- Выбрать CMakeLists.txt;
- Вижуалка некоторое время думает и отображает проект;
- Главное меню -> Cache -> Generate -> имя проекта;
- Смотрим на Output и исправляем ошибки (например, у меня ругалось на версию CMake, пришлось опустить до 3.11 вместо 3.12);
- Главное меню -> CMake -> Change CMake Settings (выбираем MinGW64-Debug);
- В проекте автогенерируется файл CMakeSettings.json. Указываем там путь до MinGW (у меня это в предыдущем видео был "Z:\msys64\mingw64"), сохраняем файл;
- Главное меню -> Cache -> Generate -> CMakeLists.txt;
- Главное меню -> Cache -> Generate -> имя проекта;
- Если всё правильно сделали, в меню Select a valid startup item (рядом с зеленой стрелкой запуска приложения) появится пункт с именем проекта;
- Запускаем.
Как и в случае с консолью, можно запустить прямо так (помня, что MinGW находится в PATH), либо выполнить after.bat и подложить необходимые DLL по инструкции. DLL нужно класть прямо в каталог, куда собирается приложение. Его можно указать в параметре buildRoot в файле CMakeSettings.json.
Итак, господа, самое главное: из Visual Studio всё отлично компилируется и запускается. Мы докзали, что не привязаны к коммерческой IDE.
Сборка в Visual Studio Code
К сожалению, Visual Studio всё ещё остаётся несвободным закрытым ПО. Нужно перейти к чему-то более свободному, и это Visual Studio Code.
Вначале забавный майндфак. Если запустить VSCode на мониторе с большим масштабированием (я дома сижу за телевизором, например), то интерфейс VSCode превратится в кашу. Чтобы этого не происходило, нужно запускать его с ключом --force-device-scale-factor (сделать ярлычок на рабочий стол, или что-то такое).
К сожалению, менеджмент PATH для VSCode я так и не осилил, поэтому единственный способ запуска — это модификация PATH с помощью before.bat и ещё один хак, который я опишу ниже.
Дальше надо настроить VSCode.
- Устанавливаем CMake Tools: View -> Extensions -> в поиск вписать "CMake Tools", нажать install напротив пакета, который сделал автор vector-of-bool.
- View -> Explorer -> Open Folder (выибраем директорию с нашим проектом);
- Command Palette (CP, шорткат Ctrl+P) -> "> CMake: Scan for Kits";
- Выбрать наш "GCC 8.2.0", пусть до которого ведёт в правильное место, где установлен msys2 или что вы там используете;
- File > Preferences > Settings;
- Перейти на вкладку User Settings;
- Щелкнуть по трём точкам в верхнем правом углу панели, и из меню выбрать "Open settings.json";
- Добавить следующие опции:
"cmake.configureOnOpen": true,
"terminal.integrated.shell.windows": "D:/msys64/usr/bin/bash.exe",
"terminal.integrated.shellArgs.windows": [
"-i"
],
"terminal.integrated.env.windows": {
"PATH": "/mingw64/bin;/usr/local/bin;/usr/bin;/bin;Z:/msys64/bin/;Z:/msys64/usr/local/bin;Z:/msys64/usr/bin;Z:/msys64/bin;Z:/msys64/mingw64/bin/;%PATH%"
},
"cmake.buildDirectory": "${workspaceRoot}/build/${buildType}",
"cmake.clearOutputBeforeBuild": true,
"cmake.generator": "Ninja",
"cmake.cmakePath": "C:\\my\\opt\\cmake-3.12.2-win64-x64\\cmake-3.12.2-win64-x64\\bin\\cmake.exe",
"cmake.mingwSearchDirs": [
"Z:/msys64/mingw64",
],
"cmake.preferredGenerators": [
"Ninja"
],
"cmake.loggingLevel": "debug"- Сборка должна произойти автоматически, и билд сложится в директорию
build. Если этого не произошло, нужно мышкой клацнуть по кнопкеBuildс шестерёнкой в статусной строке.
Понятно, что там нужно напрямую указать путь до mingw и cmake. "Но у меня же PATH!" Просто укажите, пожалуйста, это решит целый комплекс проблем.
Есть, впрочем, один эксклюзивный способ не поганить себе PATH.
"cmake.generator": "MSYS Makefiles""cmake.preferredGenerators": [ "MSYS Makefiles"]- Проверьте что MinGW нет в PATH (after.bat);
- Проверьте что удалили директорию build в проекте.
- Запустите консоль Msys2;
export PATH=/z/msys64/mingw64/bin;$PATH(можно потом будет вписать в какой-нибудь"~/.bashrc")- Из неё запустите VSCode, например так:
"C:\Users\olegchir\AppData\Local\Programs\Microsoft VS Code\Code.exe" - И дальше всё как раньше. Должен нормально сгенерироваться файл.
- При попытке немедленно запустить его из Проводника двойным щелчком мгновенно приведёт к ошибкам поиска DLL — это значит, что всё верно, внутри VSCode у нас действительно используется специальный PATH, а вне его — нет.
Итак, мы доказали что в свободном IDE мы тоже жить вполне себе можем.
Итоги
Резюмируя, если вы нормальный человек, то можете пользоваться CMake, MinGW и в ус не дуть. Всё свободно переносимо между IDE, всё просто работает. Мы можем в любой момент использовать любую платную, закрытую, несвободную IDE, и нам за это ничего не будет. А вот все остальные будут страдать, и поделом.
В будущих статьях будет учитываться ваше мнение. Вы можете прямо во время стрима на Твиче завать вопросы и предлагать предложения в комментариях. Будут ли вообще эти статьи — зависит от того, насколько яростно вы наяриваете стрелочку вверх под этим комментарием.
олег родился в интернете
в почтенной геймерской семье
питался лайками и в гугол
за двойки ставили его© Александр Раевский
Комментарии (51)
superputin
03.10.2018 15:27-2Проблемы тех, кто пользуется cmake. Нормальный make CLion не поддерживает.
Revertis
03.10.2018 16:20По хардкору за IDE, Cmake, и моё разочарование в животных
Чем вам так не угодили предлоги «о» и «про», что вы стремитесь этим нелепым и тупым «за» их заменить? Неуважение к читателям? Чтобы они не сразу поняли смысл?olegchir Автор
03.10.2018 16:47Давайте демократически устроим здесь голосование. С одной стороны, кажется что выражение «топить за X» прочно вошло в разговорную речь. С другой стороны, ну может у меня круг общения такой.
Если этот комментарий наберет 25 плюсов я поменяю «за» на что-нибудь другое. На «про IDE», скорей всего.
berez
03.10.2018 16:48+1Как установить CMake и Ninja
Главное — зачем.
Допустим, с CMake все понятно — это кроссплатформенная замена autoconf. А вот зачем нужен ninja — не совсем ясно. MSys вроде как идет с утилитой make, под которую CMake вполне себе умеет генерировать файлы: cmake -G «UNIX Makefiles». Если отказаться от сурового опенсорца и собирать MSVC компилятором с тамошней утилитой nmake, то CMake и такое умеет: cmake -G «NMake Makefiles».
А в чем смысл юзать ninja? Непонятно.
Если вы так же, как и я, живёте в компьютере, а не только включаете его в рабочие часы, предлагается следующая схема: перед началом программирования добавлять MinGW в PATH, а после — убирать. Для облегчения процесса нужно сделать два батника, которые можно запускать двойным щелчком:
Все это уже придумано до вас. Если интересно — замарайте руки установкой visual studio community и посмотрите, как там реализован developer command prompt. По факту — это батники, которые запускаются по щелчку и выставляют огромную кучу всякого полезного. Более того, в зависимости от аргументов тамошние батники умеют выставлять окружение для разработки под разные платформы (x86, x64, arm). Самый цимес — все это выставляется только внутри запущенной консольки и не уродует систему.
Т.е. если вам действительно хочется собирать проекты из командной строки, можно разложить по десктопу батники: «g++ x64», «g++ x86», «msvc x64», «msvc x86» и т. п. Ткнул — открылось окно консольки, где все уже настроено для запуска нужной версии компилятора с нужными путями.
Тогда можно одновременно собирать, например, 32-битные и 64-битные бинари в разных окошках.
Но всё-таки, разрабатывать без IDE — не дело.
Заблуждение.olegchir Автор
03.10.2018 17:03> Заблуждение.
А вот можете это подробней раскрыть? Выше по трэду меня picul пытается отшлёпать по заднице, и в суровой битве нужны суровые аргументы!
> Если интересно — замарайте руки… developer command prompt.
Да, в этом надо будет обязательно покопаться.
> Главное — зачем.
Цель статьи была показать, что ты не завендорлочен на конкретное несвободное коммерческое IDE. Многие отказываются использовать такой софт сразу же с порога, потому что «если мы подсядем на X, то потом уже не слезть, а вдруг вендор будет нами крутить как хочет». А тут сразу ясно, что как только вендор решит вами покрутить, вы отправите его в длительное пешее эротическое путешествие и просто перепрыгните на любое конкурирующее решение из громадного спектра.
Ну и в частности, это моя попытка самооправдания. Потому что вместо того, чтобы следовать слову Столлмана и использовать только свободное ПО, в дальнейших выпусках будет в основном CLion и MSVS. Что несколько зашкварно, конечно.berez
03.10.2018 18:21+4Цель статьи была показать, что ты не завендорлочен на конкретное несвободное коммерческое IDE.
Я понимаю. Непонятен конкретный выбор ninja в качестве системы сборки. CMake — это прекрасный инструмент, практически не имеющий альтернатив, если проект кроссплатформенный. CMake умеет генерировать файлы под практически все системы сборки (включая msbuild). Посему остается непонятным, зачем нужно вводить дополнительный инструмент и какие преимущества он дает.
А вот можете это подробней раскрыть?
Если совсем подробно, то нужна будет целая статья. А то и не одна.
Если вкратце — то по моему личному опыту и мнению, разработка в IDE способна снизить самодисциплину. А она очень важна, когда речь идет о качестве кода.
Поясню, о чем речь. Когда программист пишет код, он пишет его в первую очередь для других программистов. Именно для того, чтобы код легче читался и понимался, придуманы тонны coding style guide'ов. Соблюдение всех этих правил и требует от программиста самодисциплины.
IDE слишком многое делает для и за программиста. Довольно часто это приводит к тому, что программист в упор не понимает, зачем нужно правильное оформление кода. Зачем лишние пробелы? Все же и так хорошо видно — IDE подсвечивает! Зачем разбивать длинные строки, ведь в IDE же все автоматически переносится? Да еще и экран у меня широкий — мне удобнее, когда весь код в одну строчку! Зачем разносить по файлам разные функции — IDE же предлагает их все в одном файле создавать! И так далее.
Неполный перечень примеров из реальной жизни:
— чувак в упор не понимал, почему функция с 20 аргументами — это плохо. «Все аргументы же в подсказках описываются, когда код вводишь!».
— другой товарищ в упор не понимал, зачем нужно разбивать на несколько файлов исходник в 200 Кб. При том, что там содержались функции, абсолютно друг с другом не связанные логически. «А чо, вот же слева есть навигатор — любая функция там легко находится, и не надо весь файл скроллить!».
— еще один гражданин упорно писал код строками длиной в 200-300 символов, да еще и с комментами на русском языке. «У меня же все видно!». Его не смущало даже то, что комментарии при коммите превращались в фарш, ибо сервер стоял в Германии и не умел работать с кириллицей. Попытки достучаться до здравого смысла наталкивались на железобетонную стену: «у меня все нормально, проблема на той стороне».
Это все, конечно, мелочи. Но с вышеупомянутыми гражданами проблемы были и посерьезнее: коммиты, которые ломают билд; нежелание осваивать новые инструменты, если они не интегрированы в их IDE; конфликтное поведение и «закукливание» в ответ на любую критику.
Я не утверждаю, что все беды от IDE. Но в некоторых случаях «прикипание» к IDE может привести к обострению проблем у асоциальных и аутичных личностей, а следовательно — к снижению качества их работы.
Помню, один знакомый товарищ намучился с такими вот «вижулятниками» и пошел своим путем: перешел на консольный vim, отключил подсветку синтаксиса и автоматический перенос строк. На его код было любо-дорого взглянуть. Потом, правда, все равно уволился. :)Antervis
03.10.2018 19:05+2IDE это в первую очередь инструмент, и чем он лучше, тем производительнее сотрудник. На мой взгляд вам не хватало гайдлайнов/ревью/прекоммитных проверок. Когда сервер тупо не дает коммитить всё что не по код-стайлу, волей-неволей придётся переделывать — с ним то не поспоришь.
berez
03.10.2018 22:23IDE это в первую очередь инструмент, и чем он лучше, тем производительнее сотрудник.
Это заблуждение.
Производительность программиста — не в том, чтобы как можно быстрее накодить побольше строчек кода, а в том, чтобы код получился работоспособный и качественный. IDE не помогает ни с первым, ни со вторым.
Даже хуже: подсветка синтаксических ошибок в IDE создает у некоторых граждан иллюзию, что они могут написать корректный код без использования компилятора вообще. Когда в наш проект (на линукс) пришли такие вот IDE-кодеры с вижуал студией, они файлы так и правили по привычке в винде, в студии. И коммитили прямо оттуда, ни разу не удосужившись собрать сборку под линуксом. Ненуачо, ошибок же нету!
К сожалению, рычагов воздействия на них не было (такой вот был местный колорит).
К счастью, продолжалось это недолго по очевидным причинам.Antervis
04.10.2018 11:32Производительность программиста — не в том, чтобы как можно быстрее накодить побольше строчек кода, а в том, чтобы код получился работоспособный и качественный. IDE не помогает ни с первым, ни со вторым.
Во-первых, «производительность» это про «быстрее = лучше» если не в ущерб корректности/качеству. IDE позволяет писать код быстрее и как правило не в ущерб качеству.
Во-вторых, синтаксические ошибки — тоже ошибки. И другие, которые можно диагностировать на раннем этапе.
Когда в наш проект (на линукс) пришли такие вот IDE-кодеры с вижуал студией, они файлы так и правили по привычке в винде, в студии. И коммитили прямо оттуда, ни разу не удосужившись собрать сборку под линуксом. Ненуачо, ошибок же нету!
Это проблема халатности сотрудников. Вы же не думаете всерьез что в блокноте конкретно они будут писать лучше, корректнее и быстрее?
А еще налицо проблема инфраструктуры. Ничто не мешает вам использовать IDE с clang'овскими диагностиками и компилить самим clang'ом. Ничто не мешает вам использовать IDE, настроенную на удаленную сборку/запуск/отладку. Ничто не мешает вам настроить автосборку и тестирование. А еще ничто не мешает вам, в конце концов, запретить использование VS на linux-проекте. Другие IDE то в чем повинны?berez
04.10.2018 15:05+1Во-первых, (...)
Во-вторых, (...)
Да-да, все так, все так. Если рассматривать сферического программиста в вакууме.
На практике программисты, как известно,прямоугольные,со своими привычками и иллюзиями. И именно на практике выяснилось, что привычки выросших в IDE программистов бывают, мягко говоря, странными и контрпродуктивными.
Это проблема халатности сотрудников. Вы же не думаете всерьез что в блокноте конкретно они будут писать лучше, корректнее и быстрее?
Это не халатность, а скорее протест. Люди искренне не понимали требований.
Что касается блокнота — вы не поверите, но были и такие эксперименты. До конца дошли очень немногие. Тем не менее — код получился лучше, корректнее и читабельнее. Естественно, что скорость была никакая — но не потому, что товарищи резко разучились находить кнопки на клавиатуре. Просто очень много времени ушло на объяснения очевидных вещей: «вот тут у тебя — видишь? — все в кучу слеплено. А если пробельчиков добавить — сразу становится понятнее».
А еще налицо проблема инфраструктуры. Ничто не мешает вам использовать IDE с clang'овскими диагностиками и компилить самим clang'ом.
Это уже не относящиеся к обсуждаемому вопросу мелочи. Лично я считаю, что исходники должны быть отвязаны от любого рода IDE. А это значит, что даже если косоглазый китаец откроет их допотопным vi'ем в текстовой консольке 80х25 — он должен увидеть вполне читаемый код, а не уходящую за край экрана мешанину без единого пробела.
Что касается особенностей моей тогдашней работы — как бы вам объяснить-то покорректнее… Проблема инфраструктуры шерифа (сиречь руководство) не колыхала совершенно. Руководство было в далекой и влажной стране, все офисы были типовыми, вся разработка велась на серверах, которые стояли за много тыщ километров от машины разработчика. На машинах разработчика — винда. Так положено.
Вариантов запустить IDE было ровно два:
1. Поднимаем на винде X Window Server. Пробрасываем на него коннект с серверной машины. Запускаем там Eclipse (или Emacs, или gvim). Уходим пить кофе. К нашему приходу, если повезет, окошки дорисуются.
2. Ставим на локальной машине студию (или Eclipse, или еще что). Ставим в нее плагин, чтобы можно было брать исходники по FTP (другого на серверах нет). Компилять, естественно, не получится. Мучаемся так.
А так, конечно, ни-че-го не мешало нам использовать IDE. :)
Другие IDE то в чем повинны?
Ни в чем. И вижулятина тоже ни в чем не виновата. Я вообще не об инструменте, а о влиянии молотка на неокрепшие умы.
olegchir Автор
03.10.2018 19:12А вот вы своими словами можете аргументировать, чем функция с 20 параметрами плохая, если всё равно есть посветка в IDE? :-)
Сорян что на такой обширный комментарий отвечаю так коротко, но надо как-то употребить слона по кусочкамberez
03.10.2018 22:38+1IDE с подсветкой вовсе не обязательно будет у тех, кто потом будет поддерживать этот код. А без подсветки разобраться в вызовах такой функции малореально. Особенно если кто-то удалил, скажем, один аргумент из середины списка или перепутал порядок аргументов. Компилятор вовсе не обязательно в таких случаях выдаст ошибку (типы данных можно и подпривести к нужным, а некоторые аргументы могут иметь значения по умолчанию).
Ну и — очевидно — чем длиннее список аргументов, тем больше вероятность, что программист что-нибудь напутает при вызове.
kurono267
03.10.2018 19:53+1Почему в статье указана цена CLion за месяц использования для бизнеса. Для индивидуального использования цена 8,90$ в месяц, и если уж говорить о цене то единственный вариант именно купить ее для «вечного» использования текущей версии, это оплатить год подписки, и это уже 89,90$, либо если говорить о помесячной оплате 106,8$.
olegchir Автор
03.10.2018 19:56Потому что я идиот. Поправил стоимость. Да, теперь она выглядит нормальной даже для обычного человека.
robert_ayrapetyan
03.10.2018 22:54Цену поменяли, а посыл нет. Ведь теперь человек уже 24 раза может пойти в магазин купить поесть!
sborisov
03.10.2018 20:07+1Ну на самом деле Cmake та ещё штука, использую его тоже из-за Clion. Но вот скажем статически слинковать с Qt, программу, да ещё и со static_runtime, подвиг ещё тот, динамически всё линкуется и собирается прекрасно, но вот шаг в сторону и начинается квест.
Второй пример- добавить иконку к bundle в OS X, в qmake это 2 простых строки, в cmake гораздо больше, и это все очень плохо покрыто документацией.olegchir Автор
03.10.2018 20:45Вот интересно, почему они типичные паттерны использования не впиливают в свою систему. Вот это копирование DLL. Или иконка в бандле OSX. Этим же, по идее, занимаются примерно все.
Ariox41
03.10.2018 23:37+1Участвую в разработке довольно большого проекта с использованием qmake (QtCreator), и мечтаю о дне, когда целевая ОС обновится и будет поддерживать CMake 3+. У CMake, конечно, хватает недостатков — но вылезают они в основном при использовании нестандартных инструментов, и решаются путем написания собственных скриптов, ну или поиском на форумах. Справляться с недостатками qmake куда сложнее — в лучшем случае придется наплодить кучу pri-файлов и вручную подключать их во всех дочерних модулях, но и это не всегда помогает. Возможно, «я просто не умею его готовить», но с CMake у меня проблемы возникают реже и решаются быстрее. Правда, в крупных проектах я его пока не использую — возможно, еще передумаю.
robert_ayrapetyan
03.10.2018 21:14+1>Если зайти на сайт, то окажется, что CLion стоит 19 баксов. 1245 рублей
Ха, а если зайти под амер. айпишником, то 90… Некрасиво как-то.
klubben
04.10.2018 10:56Ок, с ИДЕ понятно, но почему виндовс и директ икс?
olegchir Автор
04.10.2018 20:14Боюсь не разобраться с графикой под GNU/Linux.
Более того, объем аудитории будет примерно столько же, сколько игрунов на GNU/Linux — около нуля, а нужна массовость.
Можно попробовать GNU/Linux, но только когда будет понимание вопроса.klubben
04.10.2018 20:59Тут скорее вопрос в директ икс.
Можно сразу использовать SDL, а когда появится понимание вопроса будет намного проще портировать под другие ОС.
П.С. Игрунов может быть и мало, но они есть, а т.к. игр тоже мало — образуется ниша, которую можно занять.olegchir Автор
05.10.2018 13:28Я чот даже и не вспомню никого кроме Hommade Hero, кто такое делает :( А хотелось бы!
picul
Очень любопытная картина: после сообщения о том, что Вы пришли в область, в которой ничего не смыслите, Вы сразу же классифицировали всех несогласных с Вашими решениями на три не очень приятные категории. Вы не рассматриваете четвертую категорию — тех, кто уже крутится в данной области, и лучше знает, что больше подойдет для задачи?
Если бы Вы выбрали IDE, которая используется как раз для разработки десктопа под Windows, в этой статье вместо двадцатиминутной возни с CMake в VS Code Вы бы уже писали игрушки.
olegchir Автор
picul
Это к чему?
И VS Code — это не та IDE, которую используют для десктопа под Windows.
olegchir Автор
Какую IDE используют для декстопа под Windows?
picul
Насколько я знаю, обычно используют VS. Community edition безусловно-бесплатная, имеет очень развитый функционал, не лагает, ну а для профилирования и компьютерной графики там вообще все шикарно (по сравнению с другими IDE). Но, насколько я понимаю, все это перекрывается одним большим минусом — ее сделали не в JetBrains?
SidMeier
Я использую VSCode… За соседним местом юзают SublimeText, ещё неподалёку пару vim'еров и FAR'еров, ну иногда вижу VS…
picul
Для разработки desktopa под Windows? Ну мне честно не понятна Ваша мотивация. А остальное что Вы назвали — это вроде вообще редакторы, а не IDE.
SidMeier
Просто используется своя система сборки + большой проект. CLion'ы и прочие его не могут понять, VS слишком тормознута(на мой взгляд). VSCode + некоторый набор плагинов = неплохой инструмент, который мне позволяет писать + компилять/дебажить под 3 платформы сразу(Win, Lin, Mac)…
Ну и расскажите мне что такое IDE если не редактор с плагинами? :)
olegchir Автор
А можно подробней про набор плагинов? Ну, если это не какая-то коммерческая тайна, конечно. (Что вполне может быть, судя по фразе «большой проект»). И если это какая-то загадочная вундервафля, то нафига она :-)
SidMeier
Ничего специфичного, на самом деле.
Основная магия в конфигах плагинов(их придётся как минимум изучить) + умение и желание заставить это всё работать.
picul
Ну, если и сборка кастомная, и плагинов по-находили, то VS Code может быть и неплохой инструмент. Но все это у Вас есть только потому, что кто-то когда-то потратил уйму времени на то, что бы все это сделать. И в этом отличие Вашего понимания IDE от моего. ИМХО IDE — это Integrated Development Environment, то есть после ее запуска я должен иметь возможность редактировать/компилировать/запускать/дебажить/в случае VS еще и мало-мальски профилировать CPU и дебажить графику. Максимум что нужно сделать — пару настроек на вкус и цвет.
SidMeier
IDE на мой взгляд плохо масштабируются:
1) не умеют из коробки компилировать/отлаживать кроссплатформенные проекты, Вам придётся тратить время на то, чтобы заставить их это уметь.
2) многие не умеют из коробки в мультиязычность, иногда умеют но не в то подмножество, что необходимо
3) привязывают проект к себе — создают всякие воркспейсы, солюшены и прочее
4) в силу особенностей строения человеческого мозга не могут угодить всем сразу — заметно если над проектом работают больше двух человек, особенно заметно если больше 200…
В итоге имеем что несмотря на все преимущества не покрывают всех требуемых при масштабирование сценариев и вместо них начинают использоваться модифицируемые редакторы, которые из коробки дают терминал для запуска консольных утилит, возможность добавить подсветку + автокомплит для любого необходимого множества языков и расширяемы плагинами для отладки.
picul
1) В VS 17 вроде есть Linux Toolkit. Ну и вообще вряд ли Вы потратите больше времени с IDE, чем с обычным редактором.
2) VS умеет в C++, C#, Python, JavaScript, это то что я с ходу назову. Вроде норм мультиязычность.
3) Что в этом плохого?
4) Ну такими темпами и язык программирования то наверняка не всем по душе) И операционка/политика компании/положение звезд на небе. Отчасти поэтому смотрят и в сторону популярности IDE среди программистов, и VS Code там не на первом месте.
Вообще, если у Вас кроссплатформенный проект с тонной условностей вроде своей build-системы и каких-то редких диалектов языков, то VS и впрямь может быть не лучшим выбором. Но согласитесь, что автор проблемы может испытать только в четвертом пункте)
olegchir Автор
> 3) привязывают проект к себе — создают всякие воркспейсы, солюшены и прочее
> 3) Что в этом плохого?
Собственно, в этом и был смысл всей статьи. Что есть способ сделать так, чтобы не быть завендорлоченным на конкретное решение.
Чем это плохо? Тем что вендор начинает вертеть тобой как хочет, как хвост собакой. Если же ты ни от чего не зависишь, а используешь свободный кроссплатформенный софт, то как только вендор начал трепыхаться — ты прокручиваешь его на оси и отправляешься в любые конкурирующие решения.
Как вы поняли, я сам не крестовик, а джавист. Имеется огромный опыт вот в этом. У нас даже Java — это в первую очередь набор спецификаций, относительно которых разные вендоры производят библиотеки и виртуальные машины, удовлетворяющие этим спецификациям. Спецификация — первична, конкретное решение — вторично. Очень удобно. Ты свободен как птица выбирать самое выгодное решение.
picul
Ну VS уже больше 15 лет существует, никто никем не вертит. А даже если начнет — да, придется один раз конвертировать solution VS в solution чего-то другого, но Вы это сделаете один раз, причем, скорее всего, не вручную, а автоматически. С другой стороны, Вам не придется все тестить в десятке IDE и мучиться с CMake.
olegchir Автор
Ну как не вертит. Никогда не было такого, что Microsoft вводило фичи, которые тебе не нравятся? В MSVS всё всегда идеально?
picul
Конечно, не идеально. Но по сравнению с другими — просто замечательно.
SidMeier
1) VS17 не пробовал — для линукса на винде есть wsl, вот его использую активно.
2) Но не умеет в Go, а он тоже нужен.
По остальному чуть более широко:
Я заметил что все достаточно большие проекты рано или поздно приходят к виду папочки с кодом, ресурсами и тулчейном/скриптами под тулчейн — так оказывается удобнее развиваться и расти. Я думаю можно взять в качестве примера любой известны opensource проект — там внутри будет папка с кодом, список зависимостей и набор команд, которые надо ввести в консоль чтобы проект собрать (аля make && make install).
Вводя дополнительные ограничения в виде требуемой IDE для сборки или чего-то вроде вы во первых создаёте дополнительные точки отказа (а вдруг с этой IDE что-то случится) которые вы слабо контролируете + увеличиваете порог входа для нового человека в разработке.
В итоге простая папочка с кодом и скриптами открывается любым адеквватным редактором, который помогает с подсветкой, автодополнением и подсказками, да хоть и без них, а консоль позволяет ввести нужный набор команд, чтобы получить изменённую программу и тестировать её.
Но если проект небольшой, или в ранней стадии развития то да, использование правильной IDE может дать ощутимый пинок, забрав на себя львиную долю проблем по управлению сборкой, отладке и тестированию.
Кстати в этом плане современные IDE, тот же CLion, пытаются открывать вот такие папочки с кодом если сборка построена распространённых системах(вроде того-же make и CMake), что у них неплохо получается, но всё равно они по прежнему не подходят для гигантских проектов с миллонами loc и кастомной сборкой.
olegchir Автор
Какие функции VS наиболее полезны для компьютерной графики? Там есть что-нибудь про поиск пути и коллизии? В аргументации можно воспользоваться возможностями Enterprise Edition, если они помогут. Заранее спасибо.
picul
Что имеется в виду?
olegchir Автор
Имелась в виду ирония. А отладчик DirectX обязательно гляну, спасибо! Если есть список вещей, на которые ещё стоит посмотреть — можно его сюда написать, например)
picul
Ну когда нибудь еще Performance Profiler пригодится, но тут нужно что бы было что профилировать.