Это и есть на данный момент фичи отладки, но там у них другое назначение. Там они нужны для проверки выражений, находящихся близко к точке останова, а не для того чтобы ходить по всему проекту и выполнять выражения в произвольном порядке
Подсказка нужна для того, чтобы узнать, что указатель это указатель, а не какая-то там звездочка. Все, в этом суть. Ну и дать ссылку на страницу с полной документацией. Там уже можно подробно прочитать что-то, и взять примеры. А дальше в ход идет практика, трудности которой и их решение описаны в пункте 2.
А в php/js такого нет. И наверняка не только в них. То есть единым стандартом это не является. И это просто исходники, папки с файлами. Которые предназначены для другого (как я понимаю, это видимо stubs для быстрой документации и автодополнения, которые в том же php накиданы линейно по файлам). Может и можно этим списком пользоваться для того чтобы сориентироваться, но с натяжкой. Потому что он на это не заточен
Понятное дело что он должен быть разложен по иерархии, иначе от него толку не будет. А насчет того, чтобы это было в IDE, такого не видел. Ну если вы не имели ввиду пакет Java OpenJDK, который и использовался для гифок. Но это просто пакет из папок и файлов, где дополнительно отображаются классы и функции из этих самых файлов. Специально туда никто не полезет ради этого. И это именно в Java так, в других языках по другому.
Документация далеко не всегда разложена иерархически, а даже если и так - то далеко не всегда ее можно сходу найти. А если не найти, то может быть сделан вывод, что ее нет и вовсе. Так было со мной например, когда я в первый раз искал документацию по Java, зашел на сайт, и не смог найти, где же там описание функций. Мне тогда повезло, что я знал с чего начать, загуглил функции для работы со строками, и попал на страницу, где они были (вроде эта была). А если не знать с чего начать, то на этом все и закончится
На php.net к примеру список тоже есть, но опять же он там находится в неочевидном месте, и тоже нужно знать с чего начать. А даже если его и найти, то по нему еще и не вдруг поймешь, что это он - вот страница с ним
Гарантии того, что с ходу получится найти доки (либо функции в них) на такой-то язык - нет. Также как и нет гарантии того, что они структурированы, и получится быстро по ним пробежаться, и понять, что есть в языке
Если IDE сможет определить статическим анализом, какой из классов наследников возвращается в строке 37, то можно было бы сразу отправлять в этот класс. Но так как там тип указан Figure (родительский класс), и предполагается, что может быть получен любой дочерний, то тут скорее всего все по старому, то есть дать программисту выбрать самостоятельно, куда идти
В данном случае он перешел из класса, который не является наследником класса Figure, так что здесь будет по старому - IDE его никуда не отправит, а выведет список методов из классов наследников.
Ну это так сейчас происходит. Фича из пункта 7 предназначена для случаев, когда переход был из класса-наследника
Так список в первую очередь несет обзорную функцию, а не поисковую. Он предназначен для ответа на вопрос "а что здесь вообще есть?". Чтобы это можно было узнать, когда делаешь первые шаги с каким-то языком программирования. И сразу перепробовать все что интересно. А заодно и не упустить что-нибудь. А то спустя несколько лет работы с языком, до сих пор обнаруживаешь встроенные функции, о которых раньше не слышал
Найти что-то конкретное, это уже второй этап, когда хоть немного освоился с языком. Если не получилось определить по неймингу, то поиск действительно пригодится (что возможно может быть темой для отдельной фичи)
Drag-n-Drop нужен не сам по себе, на гифке он был в связке с Live Template. Что нужно было для того, чтобы не писать вручную и избежать синтаксических ошибок
Ну так список будет структурирован по разделам, а иначе от него толку мало будет. Что касается большого размера, ну так проекты (особенно фреймворки) тоже бывают больших размеров, и что-то я не видел, чтобы список файлов и папок оттуда приходилось долго грузить. А список сущностей языка скорее с ним и будет корректней сравнить, чем с автокомлитом. Список, выдаваемый комплитом, формируется динамически. А единый список будет статичным. Сформировать его нужно будет один раз, до тех пор пока не появится новая версия языка. Ну на крайний случай нужно будет этот один раз подождать, также как нужно ждать индексацию проекта/фреймворка (что обычно многократно окупается)
Так скобки (если я вас правильно понял) это синтаксис, а для IDE подсветка и проверка синтаксиса - одна из базовых вещей. Это во всяких там текстовых редакторах, если забыл поставить точку с запятой, то программа не запуститься, и придется гадать, а что не так. А для IDE эта проблема уже в прошлом.
Ассемблер это действительно отдельная тема, хотя опять же, возможно и тут вышеописанные принципы помогут. Назначение списка - узнать, из чего состоит язык, а if-else - это просто пример.
Но те языки, которые за пределами Intellij - для них действительно какое-то время все будет по старому, пока это не станет единым стандартом. Так что да, заголовок немного кликбейтный получился
Так эти фичи выполнения кода, показанные в гифке, это изначально фичи отладки - Quick Evaluate Expression, и Evaluate Expression (выполнение в отдельном окне). Они и в отладке довольно полезны, но там они предназначены для выполнения в контексте точки останова, и в радиусе нескольких строк от нее.
Просто с отладкой есть сложности, начиная с того что ее может быть сложно настроить (тот же Xdebug языка Php), и заканчивая тем, что не всегда можно быстро воспроизвести сценарий, при котором будет достигнута точка останова.
Ходить по файлам проекта в произвольном порядке и каждый раз достигать точку останова на новом месте, особенно если она была до, а не после старого - ну такое.
"Выполнение произвольного куска кода, без контекста, без инициализации данных, без взаимодействия с остальным кодом?" - так и говорилось про то, что если выражение имеет переменные, то нужно сначала подняться выше, и выполнить то выражение, которое их инициализирует. Но также говорилось про систему хранения и генерации примеров переменных, которая либо сделает это автоматически, либо запомнит пример значения переменной для следующего раза. См конец пункта 2
но тут говорится о русской раскладке клавиатуры о проблеме с ней, может это стало причиной. Но у меня у самого несколько тикетов просто висят без внимания несколько недель, раньше такого не было
UPD: все таки есть способ "прокинуть" автодополнение IDE в php -a. Правда, это недокументированная возможность, и в итоге даже больший костыль, чем Xdebug в качестве REPL, и в целом уступает ему по возможностям и удобству. Написал об этом отдельную статью
Ну пошагово, это еще нужно добраться до того места, это еще нужно отловить приложение на этом моменте. Ну где-то действительно больше подходит пошагово. Но когда в коде банально есть вызов какого-нибудь метода, который к к тому же не принимает параметры, то проще всего узнать что он возвращает - через Quick Evaluate Expression, потому что это можно сделать в один клик, без танцев с бубнами. А если таковых десятки, то это уже ощутимо, вручную на каждый из них засорять код дампами. К тому же Quick Evaluate Expression и Evaluate Expression делают графическое представление тех же массивов/объектов. Плюс окон Evaluate Expression можно открыть сколько угодно, и перед глазами будет удобный вывод результатов выполнения разных методов. Плюс можно быстро выполнить разные вариации выражений, без всяких перезапусков файла.
Да и в пошаговой отладке эти фичи тоже можно применять, изначально они для нее и сделаны
В общем с тех пор как я начал пользоваться всем этим, то уже и представить себе не могу процесс разработки без этого
Но только ни в какие левые песочницы и в scratch вы не подключите ваш проект с его классами и т.д. Не сможете протестировать методы из этих классов. И тем более не сможете выполнять там методы, которые например делают запросы к БД. Здесь же это возможно, нет никаких препятствий для этого. А это все бывает очень полезно, когда вы изучаете чужой код в проекте, и не можете понять, что делает данный его кусок. А тут можно его выполнить прямо в редакторе, "не отходя от кассы".
И никто не говорит что только в одну строку, в консоли можно и куски кода выполнять.
А scratch здесь больше для другого подходит, не как скрипт, а как "игровая площадка", куда можно просто накидать черновые куски кода и выполнять их. Можно и просто выполнять скрипты по выражениям, но не строго пошагово, как в обычной отладке, а в любом удобном вам порядке. В общем, вариантов для чего это можно использовать, много.
Это и есть на данный момент фичи отладки, но там у них другое назначение. Там они нужны для проверки выражений, находящихся близко к точке останова, а не для того чтобы ходить по всему проекту и выполнять выражения в произвольном порядке
Подсказка нужна для того, чтобы узнать, что указатель это указатель, а не какая-то там звездочка. Все, в этом суть. Ну и дать ссылку на страницу с полной документацией. Там уже можно подробно прочитать что-то, и взять примеры. А дальше в ход идет практика, трудности которой и их решение описаны в пункте 2.
А в php/js такого нет. И наверняка не только в них. То есть единым стандартом это не является. И это просто исходники, папки с файлами. Которые предназначены для другого (как я понимаю, это видимо stubs для быстрой документации и автодополнения, которые в том же php накиданы линейно по файлам). Может и можно этим списком пользоваться для того чтобы сориентироваться, но с натяжкой. Потому что он на это не заточен
Понятное дело что он должен быть разложен по иерархии, иначе от него толку не будет. А насчет того, чтобы это было в IDE, такого не видел. Ну если вы не имели ввиду пакет Java OpenJDK, который и использовался для гифок. Но это просто пакет из папок и файлов, где дополнительно отображаются классы и функции из этих самых файлов. Специально туда никто не полезет ради этого. И это именно в Java так, в других языках по другому.
Документация далеко не всегда разложена иерархически, а даже если и так - то далеко не всегда ее можно сходу найти. А если не найти, то может быть сделан вывод, что ее нет и вовсе. Так было со мной например, когда я в первый раз искал документацию по Java, зашел на сайт, и не смог найти, где же там описание функций. Мне тогда повезло, что я знал с чего начать, загуглил функции для работы со строками, и попал на страницу, где они были (вроде эта была). А если не знать с чего начать, то на этом все и закончится
На php.net к примеру список тоже есть, но опять же он там находится в неочевидном месте, и тоже нужно знать с чего начать. А даже если его и найти, то по нему еще и не вдруг поймешь, что это он - вот страница с ним
Гарантии того, что с ходу получится найти доки (либо функции в них) на такой-то язык - нет. Также как и нет гарантии того, что они структурированы, и получится быстро по ним пробежаться, и понять, что есть в языке
Если IDE сможет определить статическим анализом, какой из классов наследников возвращается в строке 37, то можно было бы сразу отправлять в этот класс. Но так как там тип указан Figure (родительский класс), и предполагается, что может быть получен любой дочерний, то тут скорее всего все по старому, то есть дать программисту выбрать самостоятельно, куда идти
В данном случае он перешел из класса, который не является наследником класса Figure, так что здесь будет по старому - IDE его никуда не отправит, а выведет список методов из классов наследников.
Ну это так сейчас происходит. Фича из пункта 7 предназначена для случаев, когда переход был из класса-наследника
Тут пол статьи не про подсказки
Так список в первую очередь несет обзорную функцию, а не поисковую. Он предназначен для ответа на вопрос "а что здесь вообще есть?". Чтобы это можно было узнать, когда делаешь первые шаги с каким-то языком программирования. И сразу перепробовать все что интересно. А заодно и не упустить что-нибудь. А то спустя несколько лет работы с языком, до сих пор обнаруживаешь встроенные функции, о которых раньше не слышал
Найти что-то конкретное, это уже второй этап, когда хоть немного освоился с языком. Если не получилось определить по неймингу, то поиск действительно пригодится (что возможно может быть темой для отдельной фичи)
Drag-n-Drop нужен не сам по себе, на гифке он был в связке с Live Template. Что нужно было для того, чтобы не писать вручную и избежать синтаксических ошибок
Ну так список будет структурирован по разделам, а иначе от него толку мало будет. Что касается большого размера, ну так проекты (особенно фреймворки) тоже бывают больших размеров, и что-то я не видел, чтобы список файлов и папок оттуда приходилось долго грузить. А список сущностей языка скорее с ним и будет корректней сравнить, чем с автокомлитом. Список, выдаваемый комплитом, формируется динамически. А единый список будет статичным. Сформировать его нужно будет один раз, до тех пор пока не появится новая версия языка. Ну на крайний случай нужно будет этот один раз подождать, также как нужно ждать индексацию проекта/фреймворка (что обычно многократно окупается)
Так в том то и дело, что при текущем функционале IDE это не получится, вся статья про это
Нет, скорее речь идет о востребованных языках, а они и покрываются платформой Intellij
Так скобки (если я вас правильно понял) это синтаксис, а для IDE подсветка и проверка синтаксиса - одна из базовых вещей. Это во всяких там текстовых редакторах, если забыл поставить точку с запятой, то программа не запуститься, и придется гадать, а что не так. А для IDE эта проблема уже в прошлом.
Ассемблер это действительно отдельная тема, хотя опять же, возможно и тут вышеописанные принципы помогут. Назначение списка - узнать, из чего состоит язык, а if-else - это просто пример.
Но те языки, которые за пределами Intellij - для них действительно какое-то время все будет по старому, пока это не станет единым стандартом. Так что да, заголовок немного кликбейтный получился
Так эти фичи выполнения кода, показанные в гифке, это изначально фичи отладки - Quick Evaluate Expression, и Evaluate Expression (выполнение в отдельном окне). Они и в отладке довольно полезны, но там они предназначены для выполнения в контексте точки останова, и в радиусе нескольких строк от нее.
Просто с отладкой есть сложности, начиная с того что ее может быть сложно настроить (тот же Xdebug языка Php), и заканчивая тем, что не всегда можно быстро воспроизвести сценарий, при котором будет достигнута точка останова.
Ходить по файлам проекта в произвольном порядке и каждый раз достигать точку останова на новом месте, особенно если она была до, а не после старого - ну такое.
"Выполнение произвольного куска кода, без контекста, без инициализации данных, без взаимодействия с остальным кодом?" - так и говорилось про то, что если выражение имеет переменные, то нужно сначала подняться выше, и выполнить то выражение, которое их инициализирует. Но также говорилось про систему хранения и генерации примеров переменных, которая либо сделает это автоматически, либо запомнит пример значения переменной для следующего раза. См конец пункта 2
По названию, плюс в IDE есть быстрая документация
но тут говорится о русской раскладке клавиатуры о проблеме с ней, может это стало причиной. Но у меня у самого несколько тикетов просто висят без внимания несколько недель, раньше такого не было
А надо выбирать третий путь - самообучение на пет-проектах, фрилансе и тестовых заданиях. Тогда и вкатится получится, и денег потратить не придется
UPD: все таки есть способ "прокинуть" автодополнение IDE в
php -a. Правда, это недокументированная возможность, и в итоге даже больший костыль, чем Xdebug в качестве REPL, и в целом уступает ему по возможностям и удобству. Написал об этом отдельную статьюНу пошагово, это еще нужно добраться до того места, это еще нужно отловить приложение на этом моменте. Ну где-то действительно больше подходит пошагово. Но когда в коде банально есть вызов какого-нибудь метода, который к к тому же не принимает параметры, то проще всего узнать что он возвращает - через Quick Evaluate Expression, потому что это можно сделать в один клик, без танцев с бубнами. А если таковых десятки, то это уже ощутимо, вручную на каждый из них засорять код дампами. К тому же Quick Evaluate Expression и Evaluate Expression делают графическое представление тех же массивов/объектов. Плюс окон Evaluate Expression можно открыть сколько угодно, и перед глазами будет удобный вывод результатов выполнения разных методов. Плюс можно быстро выполнить разные вариации выражений, без всяких перезапусков файла.
Да и в пошаговой отладке эти фичи тоже можно применять, изначально они для нее и сделаны
В общем с тех пор как я начал пользоваться всем этим, то уже и представить себе не могу процесс разработки без этого
Но только ни в какие левые песочницы и в scratch вы не подключите ваш проект с его классами и т.д. Не сможете протестировать методы из этих классов. И тем более не сможете выполнять там методы, которые например делают запросы к БД. Здесь же это возможно, нет никаких препятствий для этого. А это все бывает очень полезно, когда вы изучаете чужой код в проекте, и не можете понять, что делает данный его кусок. А тут можно его выполнить прямо в редакторе, "не отходя от кассы".
И никто не говорит что только в одну строку, в консоли можно и куски кода выполнять.
А scratch здесь больше для другого подходит, не как скрипт, а как "игровая площадка", куда можно просто накидать черновые куски кода и выполнять их. Можно и просто выполнять скрипты по выражениям, но не строго пошагово, как в обычной отладке, а в любом удобном вам порядке.
В общем, вариантов для чего это можно использовать, много.
Ну с некоторыми отличиями, но в целом да, с PyСharm она интегрирована