Comments 8
Инструмент интересный, вы молодец.
Но позвольте внести субъективно-конструктивную критику:
1) Почему только Windows, а не Linux?
2) Исходя из п.1, расскажите, что будет, если я создам сигнатурный блок, а потом удалю метод, который был этим блоком?
3) Представьте, команда пользуется вашим инструментом и вдруг/постепенно что-то случается, вы перестаете поддерживать этот плагин или команда меняется и отказывается от его использования. По итогу, в коде будет куча комментариев с непонятной и ненужной информацией(раньше это были маркерные комментарии), эта куча будет пахнуть, причем неприятно. Вы задумывались над тем, чтобы хранить всю мета-информацию в отдельном файле/бд?
Но позвольте внести субъективно-конструктивную критику:
1) Почему только Windows, а не Linux?
2) Исходя из п.1, расскажите, что будет, если я создам сигнатурный блок, а потом удалю метод, который был этим блоком?
3) Представьте, команда пользуется вашим инструментом и вдруг/постепенно что-то случается, вы перестаете поддерживать этот плагин или команда меняется и отказывается от его использования. По итогу, в коде будет куча комментариев с непонятной и ненужной информацией(раньше это были маркерные комментарии), эта куча будет пахнуть, причем неприятно. Вы задумывались над тем, чтобы хранить всю мета-информацию в отдельном файле/бд?
Спасибо за отзыв!
1) если все будет хорошо, то будет и линукс, и другие среды разработки.
2) ничего не будет. Сигнатурная нода будет висеть в дереве. Я думал о том чтобы сделать функции поиска висячих узлов дерева и висячих маркерных комментариев в коде, с тем чтобы с ними можно было что-то сделать.
3) с ними можно обходиться как и с любыми комментариями в коде. Например какой нибудь тег TODO или FIXME — многие часто используют их без всяких маркерных комментариев, такие мешать не будут.
Вся метаинформация (дерево, подробные описания) и так хранится в отдельном xml-файле, а в перспективе наверное будет множество xml файлов — возможно по принципу «один файл исходника == один файл метаинформации» и еще дополнительные с общей метаинформацией). В исходниках только маркерные комментарии. Если ими не пользоваться, а ограничиться сигнатурами, то в исходниках вообще ничего не будет храниться. Добавил пару строк про это в статью.
1) если все будет хорошо, то будет и линукс, и другие среды разработки.
2) ничего не будет. Сигнатурная нода будет висеть в дереве. Я думал о том чтобы сделать функции поиска висячих узлов дерева и висячих маркерных комментариев в коде, с тем чтобы с ними можно было что-то сделать.
3) с ними можно обходиться как и с любыми комментариями в коде. Например какой нибудь тег TODO или FIXME — многие часто используют их без всяких маркерных комментариев, такие мешать не будут.
Вся метаинформация (дерево, подробные описания) и так хранится в отдельном xml-файле, а в перспективе наверное будет множество xml файлов — возможно по принципу «один файл исходника == один файл метаинформации» и еще дополнительные с общей метаинформацией). В исходниках только маркерные комментарии. Если ими не пользоваться, а ограничиться сигнатурами, то в исходниках вообще ничего не будет храниться. Добавил пару строк про это в статью.
(3) На мой взгляд, проблемой не является. Инструмент предназначен для изучения и копания в коде, поэтому все маркерные комментарии либо вообще коммитится в основной код не будут, либо будут присутствовать только в отдельной ветке, посвященной какой-то задаче.
Сам часто думаю о подобном инструменте. Я бы еще добавил возможность поиска по всем файлам, с предпросмотром и навигацией по результатам поиска (аналог Find in path в IDE от JetBrains или FileLocator Pro).
Честно говоря нахожу ваш подход сам по себе весьма спорным, разве что он подходит лично вам или для экспериментов. Поэтому интересно было бы где-то в статье указать были ли вами рассмотрены какие-то варианты проставления меток в исходном коде от других «производителей», чтобы отталкиваться от того, что искали по таким-то критериям, но не нашёл и вот теперь предлагаю мой вариант.
Я при недолгом копании в VS marketplace накопал следующие плагины:
https://marketplace.visualstudio.com/items?itemName=GilYoder.Remarker-18580

https://marketplace.visualstudio.com/items?itemName=OmarRwemi.BetterComments

Или вот плагин помощнее: https://marketplace.visualstudio.com/items?itemName=vs-publisher-1305558.VsTeXCommentsExtension

Можно использовать в комментариях LaTeX.
Вот плагин, воплощающий моё желание процентов на 90:
https://marketplace.visualstudio.com/items?itemName=MsBishop.ImageComments

Отображение картинок в комментариях! Его бы допилить, чтобы он из буфера обмена мог картинки вставлять и этот процент стал бы равен 95 (можно взять такой функционал из плагина markdown editor: marketplace.visualstudio.com/items?itemName=MadsKristensen.MarkdownEditor — он умеет вставлять картинки из буфера обмена).
Вот, например, сразу понятно откуда я беру строку сравнения:

Чуть немного по самим тегам. Поскольку в вас не очень сложные ключевые теги, то посоветую вам присмотреться к синтаксическим анализаторам, например, к такому компоненту как antlr. Выходной формат у него может быть написан на разных языках, а т.к. такие компоненты на содержат интерактива с экраном, то пихать их можно в самые разные языки и среды.
Надеюсь, вы поняли, что это комплимент ))) Поставить свою задачу и довести до логичного конца — круто!
Я при недолгом копании в VS marketplace накопал следующие плагины:
https://marketplace.visualstudio.com/items?itemName=GilYoder.Remarker-18580

https://marketplace.visualstudio.com/items?itemName=OmarRwemi.BetterComments

Или вот плагин помощнее: https://marketplace.visualstudio.com/items?itemName=vs-publisher-1305558.VsTeXCommentsExtension

Можно использовать в комментариях LaTeX.
Вот плагин, воплощающий моё желание процентов на 90:
https://marketplace.visualstudio.com/items?itemName=MsBishop.ImageComments

Отображение картинок в комментариях! Его бы допилить, чтобы он из буфера обмена мог картинки вставлять и этот процент стал бы равен 95 (можно взять такой функционал из плагина markdown editor: marketplace.visualstudio.com/items?itemName=MadsKristensen.MarkdownEditor — он умеет вставлять картинки из буфера обмена).
Вот, например, сразу понятно откуда я беру строку сравнения:

Чуть немного по самим тегам. Поскольку в вас не очень сложные ключевые теги, то посоветую вам присмотреться к синтаксическим анализаторам, например, к такому компоненту как antlr. Выходной формат у него может быть написан на разных языках, а т.к. такие компоненты на содержат интерактива с экраном, то пихать их можно в самые разные языки и среды.
Надеюсь, вы поняли, что это комплимент ))) Поставить свою задачу и довести до логичного конца — круто!
Sign up to leave a comment.
CodeRainbow: интерактивное изучение и документирование кода