Микроконтроллеры

Есть проблема, что скорей профессиональные программисты мало пользуются такими программами. Какой-то функционал частично востребован, но часто сводится к обычному поиску. Потому, что надёжно такие программы в принципе работать не могут, для  правильного анализа кода нужно знать как запускается компилятор, много ньюансов. Из того, что я видел за несколько последних лет: 1) Visual Studio плюс, возможно, некоторые плагины для неё вроде Visual Assist; 2) Eclipse. Это наверное два основных доступных инструмента для работы с объёмными проектами. Причём, повторюсь, не факт что они правильно проиндексируют проект. И хуже того, если проект кросс-платформенный и собирается во многих разных конфигурациях. В основном из полезного там текстовый редактор, навигация по исходному коду (см. ниже), поиск, быстрое открытие файла по тычку мыши или по частично набранному имени в неизвестном каталоге (но Eclipse с этим проблемы). 3) vs-code от Microsoft. У неё хуже с индексом и навигацией по исходному тексту, но в целом "usability" на мой взгляд выше чем у Visual Studio. 4) vim + ctags Навигация по коду у Vim совсем плохая, что частично компенсируется возможностями редактора или нажатием Ctrl-Z и дальше запуском grep'а вручную. Как ни странно, таких коллег на удивление много, причём у некоторых даже ctags нет, но виртуозно владеют git grep, например (он быстрей обычного grep оказывается, не понимаю почему). Плюсом ctags или подходя с grep'ом является их нечувствительность к некорректности исходника (когда что-то недоредактировано, недописано, и что не может быть разобрано как корректный C++ код, что ломает парсер в Intellisence от микрософта или в Eclipse). или 5) vim + clang Навигация по коду лучше, но видел у одного человека, сложно настроить, так же сбоит как студия или Eclipse. 6) Emacs + что-то специфичное. Видел у одного человека... 7) Qt Creator. Видел у нескольких человек. Там есть какой-то базовый функционал навигации по исходному коду, но больше пользуются поиском. 8) Многочисленные прочие IDE. Как правило они все ломаются, зависают, очень сильно тормозят, что угодно ещё на больших проектах и пользоваться ими невозможно. Такие IDE рассчитаны на студентов и маленькие собственные проекты. Отдельно можно выделить NetBeans, но на большом проекте с которым я работал он также сломался и упал, разбираться я не стал. Большой вопрос, кстати, как IDE интегрируется в систему сборки. Ранние версии студии -- никак. Сейчас там появился makefile проект, и какие-то списки файлов, но по-моему не стоит траты времени. По сути можно сделать отдельный параллельный проект в студии и поддерживать его -- тяжело. Eclipse -- интегрируется по крайней мере с make и видимо с cmake. В процессе запуска сборки видит как запускается gcc, извлекает из командных строк опции компилятора и начинает после этого правильно парсить C++ код. Про другие IDE не особо знаю, но обычно не очень или скорей никак. Обычно подразумевается, что IDE заменяет билдсистему, что как-то не серьёзно. Особняком стоит vs-code, где не знаю как, но судя по всему какая-то эвристика. В прочем у микрософта в Intellisence в студии тоже. Иногда работает, иногда нет. Основной функционал который может предоставить редактор/IDE программисту: 1) Непосредственно редактор, в котором можно одновременно открыть и, что важно, одновременно видеть (функция split screen) на экране несколько файлов или один файл в двух разных местах. Например, декларацию и реализацию функции. Многие умеют, но именно с split screen у Eclipse долгое время были проблемы (не мог показать один файл в двух окнах), сейчас исправлено. 2) Подсветка синтаксиса, с черно-белым текстом работать тяжело. У всех есть. 3) Функция отмены при редактировании... очевидная вроде вещь, но у некоторых реализована плохо. Должны запоминаться последние десятки-сотни шагов и иметься возможность отмотать на полчаса назад, поместить текст в буфер обмена и отмотать снова вперёд. А не только отменить последнюю операцию, что иногда встречается. 4) Поиск. Это самая важная функция. Редактор должен уметь быстро находить заданную строку не только в текущем открытом файле, но и во всех файлах проекта (каталога) вообще. В принципе часто git grep может оказаться лучше редактора, но число найденных вариантов может быть слишком большим, и редактор позволяет (через функции описанные ниже) это множество сузить. Поиск разумеется должен работать по регулярному выражению, должен иметь возможность ограничивать пространство для поиска (файл, каталог, проект, весь солюшн). Результатом поиска должен являться не переход к первому найденному результату, а отдельное окно с котором потом работать можно (кликать мышкой и переходить на место где вхождение найдено). 5) Возможность быстро открыть файл по частично заданному имени. Когда программист знает уже наперёд, в каком файле искать, но искать сам файл глазами в огромном списке (нажимать плюсики для разворачивания пяти уровней каталогов...) -- не вариант. В Vim работает вариант :e **/*file*, в Visual Studio в командной окошко можно вводить команду "of", а вот в Eclipse по-моему с этим проблемы. В VS-Code тоже вроде через командное окно. 6) Возможность быстрого возврата назад, в тот файл и ту позицию курсора, откуда ушёл в результате использования функции поиска, функций перехода описанных ниже. Позиции должны запоминаться в стеке и нужно иметь возможность возвращаться на несколько уровней назад. Как история в веб-браузере. 7) Лично я редко пользовался и списком файлов, и Outline, но иногда бывает удобно подсмотреть, когда исходники совсем чужие. Должен быть Outline на уровне проекта, или на уровне файла, класса, в разных представлениях: в виде файлов, неймспейсов, в виде типов/классов/структур, макросов, переменных. В Visual Studie, Eclipse, VS-Code есть, в Vim -- нет. 8) Быстрый переход к декларации функции, класса, переменной... Visual Studio, Eclipse, VS-Code это сходу умеют. Vim умеет через ctags, и очень плохо (в C++ коде может найти штук 20 определений функции и выбирай глазами нужную версию). Быстрый возврат обратно, к месту перехода (как "назад" в веб-браузере). Если в редакторе данной функции нет, то можно пользоваться поиском. 9) Некоторые IDE различают декларацию и реализацию и позволяют переходить к декларации или к реализации. Первая тройка (Visual Studio, Eclipse, VS-Code) с этим проблем не имеет, Vim не различает и нужно выбирать глазами. В принципе это не важно, т.к. можно понять по расширению файла или отсутствию точки с запятой в строке. 10) Множественное редактирование. Точно есть в VS-Code, в Visual Studio вроде с плагинами. Когда допустим хочешь переименовать класс. И он сразу во всех строчках во всех файлах меняет точно так же, как меняется в той строчке где курсор (и это на экране одновременно всё показывается). В принципе функция может быть спорная, заменяется поиском/заменой по регулярному выражению. 11) Интерактивная поиск/замена по регулярному выражению, во многих файлах одновременно. У всех обычно так или иначе есть. В Vim в чистом виде функции нет, но там можно разными способами сделать примерно то же самое. В конце концов если что-то не может vim, это обычно делается через shell + vim. Отдельно важной функцией является поиск/замена в выделенных строках (например в пределах класса, функции и т.п.) 12) Поиск всех использований функции, класса, переменной... Такая функция есть в Eclipse и она не всегда работает, есть в Visual Studio и работает ещё реже, в VS-Code не помню, по-моему нет, в Vim нет и нужно пользоваться обычным поиском. Функция на самом деле крайне полезная, но и реализовать её на стороне редактора крайне сложно. Когда редактор видит какое-то имя, то ему непонятно в каком оно контексте встречается, нужно до конца правильно распарсить C++, что не всегда возможно. В итоге на функцию до конца не положиться и лучше обычный поиск/grep. 13) Автодополнение. Есть у практически всех, но не у всех работает корректно. Самый плохой вариант когда не работает вообще (Eclipse не смог распарсить C++), чем когда предлагает лишние варианты (Vim). 14) Подсказка по параметрам функций, типам переменных и т.п. Часто сделана так, что пользоваться невозможно, приходится отключать. В студии до конца не отключается (как и автодополнение, как и автоформатирование кода). В принципе заменяется в Vim функцией split screen и быстрому переходу к декларации (Ctrl-W, Ctrl-]). 15) Автоформатирование. Есть примитивное, когда только уровень отступа само выставляет, если слишком умное как в студии, с последним по-моему вообще код писать тяжело. Вручную в каждой строчке жать нужное число раз табы или пробел -- действительно тяжело. 16) Переход к началу/концу функции, хотя бы по парным фигурным скобкам, переход/подсветка парных скобок вообще, т.е. навигация по коду нужна не только по именам, но и по логическим единицам (в C++ удобно, что всё обрамляется в фигурные скобки). 17) Folding, сворачивание текста. Вместо того, чтобы делать split screen, может быть проще свернуть ненужные строки в одну (как вариант, как студия умеет, свернуть функции и показывать только их прототип). Vim умеет делать фолдинг по маркерам записанным в тексте, что может быть удобно (т.е. файл внутри состоит из блоков, каждый из которых можно раскрыть и так рекурсивно), но в основном для больших файлов, если придерживаться логики файл на класс/компонент, то не очень-то и нужно. 18) Изменение отступа для выделенного блока кода -- критически важная операция. Сюда же следует отнести и вообще любые групповые операции по редактированию. 19) Вдогонку: в Еclipse видел полезную функцию найти кто вызывает данную функцию и в обратную сторону, найти кого вызывает данная функция, т.е. call tree в обе стороны. Функция полезная конечно, но опять же не всегда C++ разобран правильно и положиться нельзя. 20) Возможность поставить mark/bookmark в тексте и вернуться потом в это место. Очень критически важная. 21) В некоторых редакторах есть уменьшенная копия текста (panning window) куда можно тыкать мышкой, иногда удобно действительно, хотя и не критично. Наверное из основного -- всё. Может быть ещё показ документации по F1 (Man в Vim). Раньше в студии с этим было хорошо, а сейчас наоборот. Маны в виме есть, а win32.hlp как подложить к студии не знаю. MSDN вроде не нужно ставить. Неудобно, что документацию в отдельном браузере смотреть нужно. Ну хотя бы на базовые вещи для win32 можно было встроить. Всякие диаграммы связей, диаграммы классов, UML-диаграммы которые нарисует IDE -- всё это полная ерунда. Они всегда не полные (C++ не до конца разобран правильно), представления о внутренней логике всё равно не дают, быстро превращаются в клубок, где всё связано со всем. Суть таких диаграмм, что они должны рисоваться вручную на бумаге и показывать основной функционал, а не пытаться впихнуть всё подряд. И опять же редактор не видит программу как компилятор (для этого есть слишком много разных причин, в основном неизвестны макросы препроцессора, логика работы может отличаться от компилятора, шаблоны в C++ ломают многие парсеры) и не может точно нарисовать эту диаграмму. А некоторых вещей даже и компилятор не знает, и они выясняются только в рантайме, пока не запустишь -- не узнаешь. И серебрянной пули здесь нет, нет красивого IDE которое вывернет весь код наизнанку и сделает из него что-то простое и понятное любому дураку. В давние времена был популярен Red Had SourceNavigator (он в принципе никуда не делся, можно найти), но только для C-кода, без C++. Это уже не редактор, а только средство для просмотра кода с разными вариантами навигации по коду. Если говорить про ПО для анализа, то кроме IDE есть ещё более специализированное ПО, но оно на то и специализированное, что рассчитано на применение системными программистами. Тот же clang скриптуется на питоне. Есть GCC-XML, где программа представляется в XML, из которого через xsltproc путём написания собственной функции трансформации можно выдёргивать нужную информацию. Можно писать плагины для GCC и Clang. Для C++ обычно сразу всё очень сложно и ничего нет. Есть cflow для построения графа вызовов функций (но тоже только для C и не учитывает вызов по указателям). Есть exhuberant ctags, и его аналог GNU global, позволяющие быстро найти заданную переменную, функцию, макрос... (только C). Ещё есть cscope, фактически это такой интерактивный аналог двух последних средств. Ещё есть web-средства для индексации исходников и просмотра их в разных разрезах в браузере. OpenGrok и т.п. Я особо никогда не интересовался, только пользовался. Примеры можно посмотреть по ссылкам: * https://code.woboq.org/#features * https://elixir.boo …om/linux/latest/source * https://opengrok.l …eoffice.org/xref/core/