File splitter add-ins for Visual studio
Что то искал и не могу найти.
Опять попался дурной "проект", есть исходники по 10 тысяч строк. Приходится вручную делать partial классы и перекидывать самые большие функции.
Может кто что встречал, а то ломит самому делать.
Такое пишется самостоятельно за пару часов.
Ну напиши 
, если за пару. Только консольное приложение не надо.
Там в файлах еще регионы есть, "препроцессор" директивы и комментарии для функций, как с ///, так и с //
Хочется всё иметь не выходя со студии. Вначале весь обзор по проекту, а после по выбранному файлу. Ну может еще части драг/дропом перетаскивать.
Только консольное приложение не надо.
-----
Привередливый какой... консольное ему видите ли не надо-ть...
части драг/дропом перетаскивать.
-----
Это у тебя уже есть и оно тебе не нравится.
Автоматом порезать по критерию - не больше ХХ строк - можно и не сложно.
А кучу редакторов городить вокруг примитива... фуй...
Ну если совсем так хочется - смотри DSL - оно как раз под это дело заточено.
файлах еще регионы есть, "препроцессор" директивы и комментарии для функций, как с ///, так и с //
-----
Почти пофиг.
Ты вырезаешь 1 из трех функций завернутых в регион. Как именно ты должен поступить с регионом? Просто выкинешь и все...
С комментариями и документацией - чуточку сложнее, но так же как регионом - что не так - скипай...
Регекспы под подобный парсинг вроде были.
Привередливый какой
ну так на кой из студии извращаться, все должно быть унутри.
Автоматом порезать по критерию - не больше ХХ строк
Это сильно упрощенная версия 
Ты вырезаешь 1 из трех функций завернутых в регион. Как именно ты должен поступить с регионом? Просто выкинешь и все...
не канает, у них "логика" в регионах. Если их убить вообще ничего понятно не будет.
Регекспы под подобный парсинг вроде были.
Зачем? У Рослина готовое синтаксическое дерево.
Да пофигу как, главное чтобы файлы не были по ХХ тысяч строк. Ставим какой то лимит и заполняем его функциями начиная с самых больших.
не канает, у них "логика" в регионах. Если их убить вообще ничего понятно не будет.
Ну тут либо два из одного, либо третье...
У Рослина готовое синтаксическое дерево.
------
И ты умеешь его консумить?
Я вот регулярно спрашиваю писателей компиляторов - Язык - останется тот же, ничего не меняем. Что надо заменить чтобы генерить другой код?
На этом все останавливается...
Ну тут либо два из одного, либо третье...
Когда нет регионов то 1, а когда есть, то с регионов.
И ты умеешь его консумить?
Сделал, как бы коллекцию "визиторов", пока особых проблем не было. Но искать решения, да нужно.
Хотя вроде ничего заумного и нет
https://habr.com/ru/company/pvs-studio/blog/301204/
Я вот регулярно спрашиваю писателей компиляторов
Не имею понятия, я этим не занимаюсь. По идее должно быть, что то типа кодогенератора
Поковырял немного Рослина - было интересно как они делали некоторые моменты.
Ну что могу сказать - вместо написания реакции на вполне распознаваемые ситуации предлагается писать код выполняющий распознавание ситуации. При том что анализ уже (по крайней мере - однажды) сделан.
Не особо нравится такой вариант.
Так по своей ссылке посмотри.
Я надеялся что они решили задачу путем подключения делегата в качестве функции свертки продукции, но - нет, ограничились деревом и возможностью ползать по нему.
Т.е. будет много лишнего кода для навигации, проверки последовательностей/контекста и, как следствие, будут ошибки, особенно там где недопонято или недопознано.
Но да - все же будет проще чем писать все с нуля самому.
путем подключения делегата в качестве функции свертки продукции
ну нифига себе загнул, я так не умею ругаться
ограничились деревом и возможностью ползать по нему
может какие то умные математики по нему и ползают.
Обычные дурные кодеры просто проверяют значения узла в "визиторе"
я так не умею ругаться
------
Ну так тебе и не надо.
проверяют значения узла в "визиторе"
-----
Так не только узел проверять придется.
Проверять придется еще и некоторое количество предыдущих... и, возможно, последующих... узлов. Потому - навигация будет...
И сколько надо проверять сильно зависит от языка и от того что именно и как с него переведено в дерево.
И это при том, что все это уже делалось чтобы построить дерево и будет повторятся при изменениях в файле.
Самым правильным было бы взять грамматику языка - прогер язык в любом случае должен знать и грамматику как-то понимать - и дать возможность обрабатывать свертку (т.е. замену цепочки символов в стеке одним символом) конкретных правил.
Но это - сложно (в основном для понимания) и имеем то что имеем.
Проверять придется еще и некоторое количество предыдущих... и, возможно, последующих... узлов
Ну тебе постоянно требуются какие то извращения
Самым правильным было бы взять грамматику языка
Всё время удивляюсь отчего в Микрософте все такие тупые 
Вот попалось, может что полезное найдешь
https://docs.microsoft.com/en-us/dotnet/csharp/roslyn-sdk/...