Где у вас расположена панель с результатами Find Usages?
снизу
Где есть свободное место, там и появляется. Это же emacs.
она там тонкая, обзор маленький. На отдельном мониторе она развернута на весь экран. После того, как попробовал такое, то пользоваться узенькой панелькой совсем тоскливо.
Где есть свободное место, там и появляется. Это же emacs.плавающая не удобно, должно быть на автомате куда смотреть
Ну это кто как привык. Если уже несколько лет работаешь за один и тем же редактором, то привыкаешь к его способу отображения информации.
снизу, всплывающая - строк на ~15
она там тонкая, обзор маленький. На отдельном мониторе она развернута на весь экран.Немного вброшу - если постоянно требуется панель Find Usages, развернутая на весь экран, то с кодом что-то не так.
Немного вброшу - если постоянно требуется панель Find Usages, развернутая на весь экран, то с кодом что-то не так.Нечеткий рефакторинг как без нее делать?
Где у вас расположена панель с результатами Find Usages?Использую git grep. Нет панельки "Find Usages" — нет проблем.
результат куда выводится?
Немного вброшу - если постоянно требуется панель Find Usages, развернутая на весь экран, то с кодом что-то не так.Почему?
В консоль, очевидно
В консоль, очевидноКак ты потом переходишь из консоли к файлу, в котором найдена строка?
<double_click>:e <Ctrl+;><CR>
UPD: <Ctrl+;> это кастомный шорткат делающий "sh -c 'xsel | xvkbd -xsendevent -file -'"
UPD: <Ctrl+;> это кастомный шорткат делающий "sh -c 'xsel | xvkbd -xsendevent -file -'"
> она там тонкая, обзор маленький. На отдельном мониторе она развернута на весь экран. После того, как попробовал такое, то пользоваться узенькой панелькой совсем тоскливо.
Я тебе правильно понял, что ты хочешь найти такое место на этом мониторе, чтобы результаты в итоге были развёрнуты на весь экран?
Я тебе правильно понял, что ты хочешь найти такое место на этом мониторе, чтобы результаты в итоге были развёрнуты на весь экран?
А я в паре проектов использовал самописную утилиту, которая эти usages вставляла прямо в код - в специального вида комментарии перед функцией. Т.е. помечаю нужную мне функцию/метод спецкомментарием, запускаю свою утилиту, она меняет исходник, вставляя в комменте выше все вывовы как они присутствуют в коде с указанием мест, плюс таймстемп когда это было сгенерено. IDE замечает, что файлы поменялись, и перезагружает их. Получается во-первых на виду, а во-вторых эдакая документация, потом проще думать об изменении кода, когда сразу видишь, как он используется. Делалось это лишь для небольшого числа важных функций, конечно.
В консоль, очевидноОкно Find Usages имеет несколько режимов просмотра, в том числе, в режиме дерева с группировкой по сборкам, классам, методам. Удобно часть схлопнуть, часть открыть. Переходить на сам код иногда и не надо.
Текстовая консоль, это не то что надо.
А кто-нить объясните что это за find usages и зачем оно нужно?
А кто-нить объясните что это за find usages и зачем оно нужно?Поиск всех мест, где упоминается данная функция (класс, переменная, поле и т.д.). В отличии от простого поиска ищет на основе семантики, соответственно правильно различает, когда одно и тоже название используется в разных местах. И показывает только те места, которые действительно используют эту функцию.
Полезно, когда хочется поменять ответственность функции или класса. Позволяет быстро вспомнить как функция уже используется, и аккуратно поменять саму функцию и все места ее использования.
понятно
я обычно для этого grep-ом пользуюсь)
я обычно для этого grep-ом пользуюсь)
Греп становится сложнее, если у нас есть классы Buratino и Pinocchio и у обоих есть метод plantMoney.
я обычно для этого grep-ом пользуюсь)При высокой зависимости значения имени от контекста (например, при использовании ООП) - очень неудобно получается. Имена часто переиспользуются и простой поиск выдает кучу лишнего.
При высокой зависимости имени от контекста (например, при использовании ООП) - очень неудобно получается. Имена часто переиспользуются и простой поиск выдает кучу лишнего.
Греп становится сложнее, если у нас есть классы Buratino и Pinocchio и у обоих есть метод plantMoney.У меня в этом бывает необходимость довольно редко, к грепу прибегал всего десяток другой раз в жизни
Если вдруг где-то что-то забыл, то ведь отладчик ругнется стектрейсом, покажет место, разве нет?
Если вдруг где-то что-то забыл, то ведь отладчик ругнется стектрейсом, покажет место, разве нет?Часто - да, но в ряде случаев - нет (если старая и новая сигнатуры формально совпали/похожи, но по смыслу уже делается другое)
ps
Для начала ругнется компилятор. Или у тебя динамика?
Для начала ругнется компилятор. Или у тебя динамика?почти всегда да
У меня в этом бывает необходимость довольно редко, к грепу прибегал всего десяток другой раз в жизниНу да …
и ошибается редко тот, кто редко что-либо делает.
Ну да …
и ошибается редко тот, кто редко что-либо делает.
Окно Find Usages имеет несколько режимов просмотра, в том числе, в режиме дерева с группировкой по сборкам, классам, методам. Удобно часть схлопнуть, часть открыть. Переходить на сам код иногда и не надо.Группировку по сборкам и классам я тоже могу сделать, добавлением еще одного grep-а (хотя и не понимаю, зачем это так сильно нужно). А вот что если, например, надо узнать какие из этих usage-ей добавил Вася Пупкин после 17 января? Я добавлю к pipe-у еще пару комманд и получу нужную инфу. Ты же со всеми этими режимами просмотра будешь сосать лапу, т.к. из окошка, наверное, даже скопировать ничего нельзя.
Текстовая консоль, это не то что надо.
Ну да …Позволь поинтересоваться, ты чем-нибудь кроме рефакторинга занимаешься?
и ошибается редко тот, кто редко что-либо делает.
почему ты решил, что Find Usages и Select-String grep друг-другу противоречат, а не дополняют? 
> Если вдруг где-то что-то забыл, то ведь отладчик ругнется стектрейсом, покажет место, разве нет?
Чтобы ловить ошибки в рантайме, нужны либо стальные яйца, либо ну очень крутое покрытие тестами.
Чтобы ловить ошибки в рантайме, нужны либо стальные яйца, либо ну очень крутое покрытие тестами.
Греп становится сложнее, если у нас есть классы Buratino и Pinocchio и у обоих есть метод plantMoney.ОК, признаюсь, когда такая ситуация возникает, и прямо вот очень сложно разобраться где-что, я иду в корпоративную web-версию поиска по коду, в которой по клику на идентификатор выводится Find usages и прочее. Но это происходит не чаше 2 раз в месяц.
Кстати, а может кто-нибудь рассказать, есть ли хороший семантический find usages для плюсов в VS?
Да и под linux интересует, есть ли что-нибудь адекватное, не завязанное на конкретную IDE? Типа ctags, но с семантикой.
Чтобы ловить ошибки в рантайме, нужны либо стальные яйца, либо ну очень крутое покрытие тестами.динамика - не всегда рантайм
а так да, юнит-тесты, отлов исключений, отладочная печать - как всегда зависит от задачи
почему ты решил, что Find Usages и Select-String grep друг-другу противоречат, а не дополняют?Что-то мне подсказывает, что в случае ТС это не так.
Что-то мне подсказывает, что в случае ТС это не так.и что же это, что тебе подсказывает?
т.к. из окошка, наверное, даже скопировать ничего нельзя.можно
А вот что если, например, надо узнать какие из этих usage-ей добавил Вася Пупкин после 17 января? Я добавлю к pipe-у еще пару комманд и получу нужную инфу.плагин к решарперу тоже без проблем написать
можнокак?
Позволь поинтересоваться, ты чем-нибудь кроме рефакторинга занимаешься?а причем тут рефакторинг? Find Usages используется для навигации по коду. Навигация по файлам менее удобная, я ей почти не пользуюсь.
в решерпере
на этой панеле на тулбаре кнопка Export
можно даже в XML экспортнуть
на этой панеле на тулбаре кнопка Export
можно даже в XML экспортнуть
* Ты называешь консоль "текстовой консолью".
* Ты спрашиваешь, куда идет вывод git grep.
* Ты пишешь на C# под Windows.
* Паре консольных комманд ты предпочтешь плагин для плагина для IDE.
* Ты спрашиваешь, куда идет вывод git grep.
* Ты пишешь на C# под Windows.
* Паре консольных комманд ты предпочтешь плагин для плагина для IDE.
Find Usages используется для навигации по коду. Навигация по файлам менее удобная, я ей почти не пользуюсь.Отсюда и вопрос пошел. Навигация по коду — самая частая операция при работе с кодом. Поэтому и нужно крайне удобное место для этой панели.
А вы как навигируетесь по коду? Пишите каждый раз регулярное выражение? Это же черепашьим шагом. Это примерно как считывать информацию с перфокарт, да, можно, но менее удобно.
В Visual Studio есть стандартный поиск с использованием регулярных выражений.
Всё же, распиши логическую цепочку, как из этих пунктов следует, что я не пользуюсь текстовым поиском?
Всё же, распиши логическую цепочку, как из этих пунктов следует, что я не пользуюсь текстовым поиском?
> А вы как навигируетесь по коду?
Мы не навигируемся, мы ходим.
Просто нажимаем M-.
---
Escape-Meta-Alt-Control-Shift
Мы не навигируемся, мы ходим.
Просто нажимаем M-.
---
Escape-Meta-Alt-Control-Shift
А вы как навигируетесь по коду?Если использовать подход - код пишется раз и навсегда и больше не меняется, то по коду навигироваться не надо. )
нажимаем M-.что эта команда делает?
Если использовать подход - код пишется раз и навсегда и больше не меняется, то по коду навигироваться не надо. )это кодирование в корзину что ли?
Навигация по коду — самая частая операция при работе с кодом.Если не работа с кодом, а медитация на код получается
это кодирование в корзину что ли?Например, водопадная модель разработки или ее аналог.
как из этих пунктов следует, что я не пользуюсь текстовым поиском?Я этого не говорил. Я писал, что твое окошко бесполезно, если надо сделать что-нибудь, что разработчики окошка не предусмотрели. А в "текстовой консоли", которая "не то что надо", можно без лишних усилий делать вещи, для которых тебе нужно писать плагин для плагина для IDE.
А вы как навигируетесь по коду? Пишите каждый раз регулярное выражение?У меня основные сценарии навигации это нечеткий поиск по путям файлов и переход к definition/ declaration по символу под курсором. Find usages нужен намного реже.
это нечеткий поискв чем причина нечеткости?
переход к definition/ declaration по символу под курсоромтвой редактор это делает, а find usages нет? Очень странно, find usages это же просто обратный проход по тому же графу, что и для go to definition. Если твоему редактору известен граф, то почему он не предоставляет навигацию в обе стороны?
в чем причина нечеткости?Может неправильно назвал. Имел в виду такой поиск, когда буковки запроса не обязательно должны идти подряд в результате.
В каких сценариях такое появляется?
Может неправильно назвал. Имел в виду такой поиск, когда буковки запроса не обязательно должны идти подряд в результате.Вообще, это аццки удобная фича. swank-сервер (напр. slime) делает такой поиск по всем известным именам и по желанию редиректит на соответствующее место в коде.
твой редактор это делает, а find usages нет? Очень странно, find usages это же просто обратный проход по тому же графу, что и для go to definition. Если твоему редактору известен граф, то почему он не предоставляет навигацию в обе стороны?Не совсем. Чтобы сделать go to declaration и autocomplete для плюсов, достаточно информации полученной из одной единицы трансляции (читай cpp файл и все его include-ы рекурсивно). Для этого я использую плагинчик, который использует метаинформацию полученную из libclang.
Для find usages же нужна информация со всех единиц трансляции проекта вместе взятых. Я бы не возражал, если бы такой плагин существовал, но его нет, т.к. написать подобный плагин для текстового редактора это супер тяжелая задача.
Почти всегда, когда надо открыть файл. Например, есть у тебя файл InputStreamUnittest.java, который находится на 7-ом уровне вложенности директорий. Пишешь что-то вроде "inpustunitja" и нужный файл уже на первом месте в выдаче.
Почти всегда, когда надо открыть файл.В процессе какого сценария появляется задача открыть исходный файл по имени взятому из своей памяти?
ну обычно хоть что-то про проект над которым работаешь ты помнишь. И искать по куче вложенных структур родимый QuoteDocumentsWorkflowDefinitionsProviderTests.cs, проще всего нажав Ctrl+T Quot Docu Tes
В процессе какого сценария появляется задача открыть исходный файл по имени взятому из своей памяти?Кажется, это стандартный сценарий, не? Есть задача «добавить фичу X», ты вспоминаешь, что связанный с этим код лежит в классе /файле (…с названием, кажется…) FooBar, открываешь его, дальше уже копаешь.
В идее, например, есть охуительный хоткей, который показывает попап нечёткого поиска по файлам, работай в обычной линуксовой консоли C-Space, я бы уже давно его впилил себе в вим.
ты вспоминаешь, что связанный с этим код лежит в классе /файле (…с названием, кажется…) FooBarзачем этим захламлять свою память?
добавить фичу X
Есть описание фичи. Из этого описания берешь либо ключевое слово (прям кописастом), либо место на форме (если фича на форме), а дальше уже навигация по коду. Зачем помнить какие-то названия? Нормальный по размеру проект все равно не в одну человеческую память не влезет.
Легче сказать, когда она не возникает.
* Увидел описание бага, понимаешь что проблема скорее всего в файле xxx.
* Работаешь над фичей какой-то затрагивающей 10-ок файлов по всему репозиторию. Их имена более-менее в кэше памяти находятся, нужно перидически по ним перемещаться.
* Нужен тебе полный путь к файлу для того, чтобы include сделать, а ты его не помнишь, а файла имя примерно помнишь.
* Точно не помнишь, как называется файл, который тебе нужен, но есть какие-то обрывочные воспоминания. Попробовал так и сяк — файл нашелся.
* Забыл как назывался класс или вызов, который использовал в другом месте, но помнишь в каком файле было дело.
Я не пойму, а ты как файлы открываешь?
* Увидел описание бага, понимаешь что проблема скорее всего в файле xxx.
* Работаешь над фичей какой-то затрагивающей 10-ок файлов по всему репозиторию. Их имена более-менее в кэше памяти находятся, нужно перидически по ним перемещаться.
* Нужен тебе полный путь к файлу для того, чтобы include сделать, а ты его не помнишь, а файла имя примерно помнишь.
* Точно не помнишь, как называется файл, который тебе нужен, но есть какие-то обрывочные воспоминания. Попробовал так и сяк — файл нашелся.
* Забыл как назывался класс или вызов, который использовал в другом месте, но помнишь в каком файле было дело.
Я не пойму, а ты как файлы открываешь?
Я не пойму, а ты как файлы открываешь?файлы и структура кода это разные вещи, проще "открывать" элементы кода
зачем этим захламлять свою память?
Зачем помнить какие-то названия? Нормальный по размеру проект все равно не в одну человеческую память неА чем ты захламляешь свою память? Мне вот знание, что и как устроено, экономит кучу времени, поскольку в 98% случаев не нужно перелопачивать Find Usages.
влезет.
Я не пойму, а ты как файлы открываешь?Обычно по "ссылкам" ходишь, да и всё - с помощью go to definition, find usages и т.д.
Увидел описание багаОпределил на каком стыке он появляется (gui, cli, меж-процессный), открыл код стыка - а это какой-то из основных файлов, и далее go to definiton раз за разом, локализуя участок ответственный за ошибку.
или еще лучше - формируешь последовательность действий или тест, которые проявляют ошибку. Дальше запускаешь отладчик и методом двоичного поиска, используя кнопки "зайти внутрь"/"пропустить" выскакиваешь на причину ошибки.
Я этого не говорил. Я писал, что твое окошко бесполезно, если надо сделать что-нибудь, что разработчики окошка не предусмотрели. А в "текстовой консоли", которая "не то что надо", можно без лишних усилий делать вещи, для которых тебе нужно писать плагин для плагина для IDE.В visual studio есть очень крутое API для работы с кодом, я видел его тут
http://www.youtube.com/watch?v=8V2RXbLEOwI
Вкратце, там структура проекта представлена как файловая система. Можно сделать cd в файл с C# кодом, написать ls, и получить список классов в файле. Потом с этими классами можно работать через API, на видео чувак добавляет комментарии через API. Можно писать любые запросы через powershell.
Я сейчас понял, что я совсем не рассматриваю код через призму файлов. В голове держится только картинка кода, и связи между кодом. Кто кого использует, кто кого вызывает, кто от кого зависит, кто из чего состоит и т.д.
Файлы IDE уже сама подсовывает.
Файлы IDE уже сама подсовывает.
Есть описание фичи. Из этого описания берешь либо ключевое слово (прям кописастом), либо место на форме (если фича на форме), а дальше уже навигация по коду. Зачем помнить какие-то названия? Нормальный по размеру проект все равно не в одну человеческую память не влезет.Почему на джаве, в которой стандартом является тотальное использование IDE, пишут такое говно? Казалось бы, наоборот, такие мощные инструменты, должны хорошие программы получаться?
Enterprise же. Т.е. она фактически изначально заточена и развивается под то, чтобы толпа человек, лично не заинтересованных в результате, выдала все-таки на гора удобоваримый продукт. )
Отсюда кондовость, громоздкость, фабрика на фабрике и т.д.
Отсюда кондовость, громоздкость, фабрика на фабрике и т.д.
Enterprise же. Т.е. она фактически изначально заточена и развивается под то, чтобы толпа человек, лично не заинтересованных в результате, выдала все-таки на гора удобоваримый продукт. )Мне кажется, до появления джава-программистов у энтерпрайза не было такой плохой репутации. То есть не джава плохая, потому что энтерпрайз, а энтерпрайз плохой потому что там джава.
Мне кажется, до появления джава-программистов у энтерпрайза не было такой плохой репутации.Это ты про Cobol, PL/I и т.д.? )
Давай посмотрим шире - когда это у больших компаний не было плохой репутации? Не только в ПО, но и в другой деятельности. Всю жизнь большие компании пинают за плохие продукты - за низкое качество, громоздкость, не актуальность текущим запросам и т.д.
Почему на джаве, в которой стандартом является тотальное использование IDE, пишут такое говно? Казалось бы, наоборот, такие мощные инструменты, должны хорошие программы получаться?Главная проблема — в Java всё пропитано объектно-ориентированным моделированием. Пропитано буквально всё от языка, до мозгов большинства членов java-комьюнити.
Определение объектно-ориентированного моделирования:
One powerful design strategy, which is particularly appropriate to the construction of programs for modeling physical systems, is to base the structure of our programs on the structure of the system being modeled. For each object in the system, we construct a corresponding computational object. For each system action, we define a symbolic operation in our computational model.
http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-19.html...
Поскольку энтерпрайз это в большей части не реальные физические системы (банковский счет это же не реальная физическая сущность), то, по сути, происходит следующее. Человек нафантазирует объекты и потом отображает их в коде. Условие задачи сначала отображается в фантазию человека, а потом фантазия отображается в код. Такое двойное отображение и является главной причиной того, почему программы получаются плохие.
Условие задачи сначала отображается в фантазию человека, а потом фантазия отображается в код.А бывает как-то по-другому?
А бывает как-то по-другому?Да, бывает. Условие задачи отображается на код. В реальности условие задачи часто неполное и местами противоречивое, поэтому в процессе отображения его на код условие уточняется, дополняется, устраняются противоречия и логические несостыковки.
Да, бывает. Условие задачи отображается на код.AI что ли?
Иначе я не могу себе представить прямое отображение.
AI что ли?Почему обязательно AI? Прямое отображение делает человек.
Иначе я не могу себе представить прямое отображение.
Человек не робот, он не может делать прямое отображение.
еловек не робот, он не может делать прямое отображение.робот тоже не может
Да и под linux интересует, есть ли что-нибудь адекватное, не завязанное на конкретную IDE?Правильный спартанец сам такое напишет на awk.
Я делал как-то, находило...
Оставить комментарий
6yrop
У меня она была на втором мониторе. Сейчас хочу вернуться к одному монитору. Не могу найти удобное место для этой панели. Где она у вас?