Appcode для windows 10

Содержание
  1. AppCode 2020.1: улучшения быстродействия, автодополнение до конца индексации, генерация документации и многое другое
  2. Быстродействие
  3. Автодополнение во время индексации
  4. Документация для кода
  5. Иерархия типов
  6. Структурное представление кода
  7. Проверки кода и быстрые исправления
  8. Просмотр определения типа
  9. Touch Bar
  10. Режим LightEdit
  11. Дзен-режим
  12. JetBrains Mono
  13. AppCode 2020.3: локализация для Swift, переход к определению до индексации, улучшенные рефакторинги и многое другое
  14. Поддержка Swift
  15. Локализация
  16. Действия для изменения кода
  17. Change Signature
  18. Rename
  19. Переход к определению типа
  20. Отладчик
  21. Code With Me
  22. Контроль версий
  23. Поддержка XCFrameworks
  24. Просмотр определения
  25. AppCode 2019.1: Swift 5, улучшенная работа подсветки, навигации и автодополнения, перемещение выражений и многое другое
  26. Swift
  27. Swift 5
  28. Переименование
  29. Навигация к определению
  30. Перемещение выражений
  31. Многострочные литералы
  32. Подсветка, автодополнение, анализ кода и все-все-все
  33. Objective-C/C/C++
  34. Запуск и отладка
  35. Темы для IDE
  36. Список недавно просмотренных / измененных участков кода
  37. Похожие публикации
  38. Что нового в AppCode 2018.1
  39. AppCode 2017.2: Extract Method и улучшения автодополнения для Swift, поддержка __auto_type в Objective-C и многое другое
  40. AppCode 2017.1: улучшенная поддержка Swift, новые возможности кодогенерации и многое другое
  41. Вакансии компании JetBrains
  42. Комментарии 23

AppCode 2020.1: улучшения быстродействия, автодополнение до конца индексации, генерация документации и многое другое

Всем привет, в этом посте рассказываем про новый AppCode 2020.1, который мы выпустили буквально вчера.

Быстродействие

AppCode 2020.1 стал значительно быстрее работать с проектами на чистом Swift и смешанными проектами на Swift/Objective-C. Часть работы, делавшейся непосредственно при открытии файла и при этом каждый раз после открытия проекта, мы перенесли на момент индексации и стали кешировать результаты. Что это дало: первоначальное индексирование стало чуть дольше, зато все последующие — быстрее, как и скорость появления подсветки, работа автодополнения и вообще любых действий, связанных с кодом:

Кроме всего этого, оптимизировали автодополнение для параметров функций и методов, локальных переменных и глобальных переменных, объявленных в текущем файле. Этот сценарий использования встречается часто, поэтому автодополнение стало еще быстрее.

Убрали причину подвисания “Loading…” при открытии файла (под капотом там оказалась достаточно нетривиальная оптимизация парсинга бинарных выражений).

Все это вместе позволяет работать намного более комфортно, чем раньше.

Автодополнение во время индексации

Мы стараемся сделать как можно большее количество действий IDE доступным еще до конца индексации. Так, в AppCode 2019.2 мы реализовали возможность собирать, запускать, отлаживать и тестировать проект, даже если индексация еще в процессе. В этом релизе к таким возможностям добавилось автодополнение:

Для того чтобы это сделать, мы творчески переиспользовали SourceKit. Пока в этом режиме не работают плэйсхолдеры для параметров (вставляется просто текст), нет возможности быстро переключаться между параметрами методов и функций, но даже с этими ограничениями нам кажется удобным иметь автодополнение как можно раньше.

Документация для кода

Закрываем старые запросы, добиваем консистентность: теперь для Swift можно сгенерировать комментарий для любой кодовой конструкции просто напечатав /// и нажав ⏎ :

Иерархия типов

Доделали окно иерархии типов для Swift — теперь оно есть, и работает так же, как в Objective-C:

Структурное представление кода

Оно же Structure view. Добавили три режима сортировки элементов: по алфавиту, по типу и по области видимости:

Проверки кода и быстрые исправления

В прошлом релизе добавили достаточно много быстрых исправлений для Swift, в этом — еще одно новое и пара проверок:

Просмотр определения типа

Раньше можно было посмотреть определение любого символа в коде через Quick Definition ( ⌥Space ), а теперь можно сделать то же самое для типа этого символа через Quick Type Definition:

Touch Bar

В предыдущих версиях интеграцию Touch Bar в AppCode пришлось выключить из-за вызванных ей проблем с быстродействием. Отличная новость — проблемы мы ликвидировали, Touch Bar снова работает.

Режим LightEdit

Теперь для обычного редактирования текста весь проект открывать не нужно, достаточно просто открыть файл с Welcome Screen, или через командную строку с помощью скрипта запуска, сгенерированного для IDE. Будет открыт только этот файл — быстро, легко, просто.

Дзен-режим

Многие знают про дополнительные режимы для UI в AppCode, например режим Presentation, название которого говорит само за себя (кстати, очень удобно показывать демки с ним), а также Distraction Free, в котором окно IDE выглядит как минималистичный текстовый редактор без окон, тулбаров и прочего. С дзен-режимом все просто — это полноэкранный Distraction Free, чтобы совсем ни на что не отвлекаться.

JetBrains Mono

Шрифты мы любим, а крутые моноширинные шрифты, сделанные специально для разработчиков — особенно. Теперь шрифтом по умолчанию у нас и в других IDE от JetBrains будет JetBrains Mono (и, конечно же, он поддерживает лигатуры).

На этом все. Коротко про планы на будущее — над поддержкой SPM пока работаем, целимся в следующий релиз, работать над быстродействием также продолжим.

Читайте также:  Gamdias hera windows 10

Все вопросы и пожелания пишите прямо тут в комментариях — будем рады ответить!

Источник

AppCode 2020.3: локализация для Swift, переход к определению до индексации, улучшенные рефакторинги и многое другое

Вышел AppCode 2020.3. Те, кто читал статьи на английском в нашем блоге, уже и так все знают, а тем, кто еще не в курсе и хочет быстро ознакомиться со всеми изменениями, — добро пожаловать под кат.

Поддержка Swift

Поддержали пачку новых возможностей языка:

Локализация

В AppCode давно есть локализация для строк в Objective-C, в этом релизе реализовали то же самое для Swift:

Действия для изменения кода

Добавили несколько небольших, но полезных действий по модификации кода:


Change Signature

Rename, который работает для смешанного Objective-C/Swift кода, у нас уже есть. А в этом релизе доработали Change Signature, чтобы он тоже работал сразу же со смешанным кодом. Кроме этого:

Rename

Сделали новое отображение для настроек рефакторинга Rename — открыть их можно по ⇥ :

Переход к определению типа

Работает даже до конца индексации — реализовали по тому же принципу, что и автодополнение с использованием SourceKit.

Отладчик

В отладчике появилось несколько полезных платформенных возможностей:


Code With Me

Многие, наверное, слышали про новый сервис от JetBrains для совместного редактирования кода — Code With Me. Теперь он работает в AppCode через соответствующий плагин. Подробнее про него можно прочитать вот тут.

Контроль версий

Теперь вместо changelist’ов можно включить git stage :

А Search Everywhere получил новый таб для поиска по коммитам:

Поддержка XCFrameworks

Просмотр определения

Возможен прямо из Project view с помощью ⌥Space :

На этом всё! Все вопросы и пожелания пишите прямо тут в комментариях — будем рады ответить!

Источник

AppCode 2019.1: Swift 5, улучшенная работа подсветки, навигации и автодополнения, перемещение выражений и многое другое

Неделю назад мы выпустили AppCode 2019.1 — поговорим об изменениях в нем. Под катом куча нового, полезного, исправленного и дополненного.

Swift

Swift 5

Все новые возможности Swift 5 корректно работают в AppCode 2019.1:

Переименование

Была проблема с переименованием перегруженных методов и методов класса-родителя — а теперь ее нет.

Казалось бы, что может быть проще и элементарнее перехода к определению метода или класса? Стандартное, привычное действие.

И все действительно так в Objective-C: название типа при инициализации объекта стоит отдельно, сам метод-инициализатор — отдельно. Соответственно, если курсор стоит на названии типа, мы переходим к определению типа, если на инициализаторе — к определению инициализатора. А вот в Swift все становится сложнее. Инициализатор слился с названием типа воедино, и, если воспроизводить поведение Xcode, теряем возможность перехода именно к инициализатору. Если же оставлять поведение AppCode 2018.3.x, ломаем привычку пользователя (“как в Xcode”, то есть переход не к определению инициализатора, а к определению типа). Это по понятным причинам не нравится пользователям.

В итоге выработали серединное решение: все-таки выражение, инициализирующее объект в Swift, по-прежнему состоит из двух частей. Все, что до круглых скобок, — название типа, а все внутри — сигнатура инициализатора. Поэтому, если курсор стоит на названии типа, переходим к определению типа, если внутри круглых скобок — к определению инициализатора:

Оба сценария использования сохранены, все счастливы.

Перемещение выражений

Пока пользователи Xcode выделяют мышкой и копипастят, пользователи AppCode ставят курсор на выражение и двигают его целиком легким нажатием ⇧⌘↑ / ↓ :

Работает для циклов, функций, методов, классов, условий, в общем, почти для всего.

Многострочные литералы

Как превратить однострочный литерал в многострочный? В AppCode теперь достаточно нажать ⏎ :

Подсветка, автодополнение, анализ кода и все-все-все

Чем корректнее мы строим дерево символов, которое используется для подсветки, анализа кода, навигации и прочих функций IDE (даже для отображения переменных в отладчике), тем лучше и правильнее будет работать AppCode. В этом релизе мы решили несколько фундаментальных проблем, которые портили жизнь пользователям:

Objective-C/C/C++

Коллеги из CLion добавили стили именования кодовых конструкций для C/C++, а мы их получили еще и для Objective-C ( Preferences | Editor | Code Style | C/C++/Objective-C | Naming Convention) :

Запуск и отладка

AppCode теперь умеет присоединяться к процессам, запущенным не только на симуляторе, но и на устройстве ( ⇧⌘A → Attach to process ):

В настройки конфигураций запуска добавлена возможность выбора языка и региона приложения:

Пересчет переменных при отладке теперь можно запретить с помощью действия Mute Variables в контекстном меню:

Темы для IDE

Внимательный читатель уже заметил, что все скриншоты в посте сделаны с использованием новой темы оформления Dark Purple:

Темы IDE теперь можно делать самостоятельно, поэтому в репозитории плагинов кроме нескольких тем, сделанных нами, уже можно найти несколько пользовательских вариантов оформления. А до 3-го мая можно не только сделать свою тему, но и поучаствовать в конкурсе, недавно анонсированном нами.

Читайте также:  Windows 10 где находится главное меню

Список недавно просмотренных / измененных участков кода

Есть несколько полезных действий для навигации к недавно открытым или измененным местам в коде:

Перемещение к последнему отредактированному участку кода вообще сложно переоценить, особенно когда редактируешь файл большого размера.

Теперь появился еще и список недавно просмотренных / измененных мест Recent Locations ( ⇧⌘E ):

Вот такой получился релиз. Все вопросы, пожелания и даже баг-репорты пишите прямо тут в комментариях — будем рады ответить!

Похожие публикации

Что нового в AppCode 2018.1

AppCode 2017.2: Extract Method и улучшения автодополнения для Swift, поддержка __auto_type в Objective-C и многое другое

AppCode 2017.1: улучшенная поддержка Swift, новые возможности кодогенерации и многое другое

Вакансии компании JetBrains

Комментарии 23

Зачем все эти фичи, если среда зависает намертво и ресурсы жрет хуже хрома!
Серьёзно… Просто попытался воспроизвести первую гифку — и аппкод зависает намертво.

а так задумка, конечно же, хорошая…

Серьёзно… Просто попытался воспроизвести первую гифку — и аппкод зависает намертво.

Вот, к сожалению, жаль, что у такого хорошего инструмента нет автоматического отслеживания подобных вещей. Всё работает, подсветка есть, индекс собран, по файлам прыгает. Но в какой-то момент при попытке перейти на определение по cmd+b — фриз полностью главного потока. И висит оно так минут 10.

Спасибо за пути возможного решения.

Спасибо, пользуюсь 2019.1, но мне кажется 2018 версия была шустрее. После следующих изменений стало, вроде, лучше:
1. Добавил некоторые JVM флаги ( stackoverflow.com/questions/5651538/speedup-intellij-idea). После настроек сделал max 2Gb и min 1Gb и это оказалось лучше чем я когда выставлял max 7Gb, все равно AppCode всегда показывает использование памяти ок 800Мб.
2. Комплишен оооочень медленный, в итоге убрал галочки на smart и base completion, мне важно чтобы комплит появлялся, то что он мне помогал бы не совсем важно, иначе с этими галочками приходится по 5 — 10 секунд ждать первые подсказки, а без них всего пару секунд. Еще есть хак, если нужно вызвать метод или переменную из локального скоупа (class/struct/etc) то нужно всегда писать self. тогда видимо отсекаются глобальные области поиска и комплит почти сразу работает. Для глобальных функций/переменных как долго работал так и работает, проще дописать руками или открыть Xcode и там написать и потом обратно переключиться.

Буквально на днях заметил странную штуку, сборка в AppCode намного дольше чем на Xcode. Тесты проводились следующим образом.
Xcode:
1. Закрыл Xcode
2. Почистил DerivedData (Library/. /Xcode/DerivedData)
3. Открыл Xcode и сразу нажал запустить проект на симуляторе (то есть полная сборка + запуск)
Время на всё ушло 3:50-4:00 минуты в Xcode

AppCode, тоже самое, только чистил его DerivedData (../Caches/../AppCode 2019/../DerivedData/) и AppCode мне выдавал больше 5 минут (нажимал на жука чтобы включить отладку я так понимаю).

Еще мне очень сильно не нравится в 2019 после 2018 версии, что довольно часто после изменения кода (например изменить имя приватной функции, добавить дополнительный параметр в функцию) всё перестает работать секунд на 10-20, то есть IDE UI не блокирован, но если попробовать посмотреть описание любой переменной или функции в классе (да хочь чего) через cmd+touchpad то ничего не показывает, если нажать на любой (тут я подчеркиваю, что работа с другой нетронутой функцией, а не которая была переименована) вызов функции то не переходит в ее дефенишен и более того эта функция даже не подсвечивается (что по ней можно перейти).

Еще замечаю (любая версия IDE), что бывают выражения, которые программа с другом вывозит. Вот например внутри функции был код

вот после того как написал знак деления сразу стали видны лаги UI причем постоянные толи пока курсор не убрал с этой линии, толи пока выражение не дописал, но суть в том, что после знака деления комплит наотрез отказался работать (ну или ждать минуту надо). Подобное поведение встречается в сложных выражениях и автокомплит работает после полуминуты ожидания. Ужас.

Очень плохо резолвится chaining, прям проблема

Тут всегда даже подсветка не работает, я уже не говорю, что не может вывести тип. Такое часто когда тип объекта object из другого модуля.

2019 версия стала подсвечивать больше кода, конечно есть участки где IDE не может понять, но их стало меньше — за это спасибо.

Уже не помню, но вроде компишен дженериков тоже очень плохо работает

Вот всегда при объявлении подобных переменных тип приходится писать руками, автокомплит молчит.

Читайте также:  Hp laserjet color 1600 windows 10

в итоге убрал галочки на smart и base completion

Буквально на днях заметил странную штуку, сборка в AppCode намного дольше чем на Xcode.
то есть полная сборка + запуск

довольно часто после изменения кода (например изменить имя приватной функции, добавить дополнительный параметр в функцию) всё перестает работать секунд на 10-20

Еще замечаю (любая версия IDE), что бывают выражения, которые программа с другом вывозит.

Тут всегда даже подсветка не работает, я уже не говорю, что не может вывести тип. Такое часто когда тип объекта object из другого модуля.

А вот тут бы тестовый проект, потому что крайне трудно воспроизвести то, о чем вы говорите. Если брать минимальный пример типа:

то здесь все подсвечивается. Поэтому проблема не в chaining, как таковом, а, скорее всего, в сочетании generics в ваших объектах. Понять точно было бы полезно.

Уже не помню, но вроде компишен дженериков тоже очень плохо работает

Error:Build failed with 0 errors

Это касается как разницы между кол-вом в Swift относительно Objective-C так в целом между AppCode и ReSharper например.

Ну, если коротко, то рук не хватает и мы постоянно ищем разработчиков. К слову, их количество неуклонно растет.

Если более подробно, то нельзя сравнивать Swift и какой-либо другой язык. Для начала, не существует просто Swift. Есть связка Swift + Objective-C/C++, mixed code. Либо это библиотеки, либо еще крайне многое. В итоге мы тут решаем задачу, которую ни один другой продукт JetBrains не решает — делаем кроссязыковое взаимодействие не в виде приятного бонуса, а как часть функциональности, без которой IDE просто бесполезна. Любой C-подобный язык сразу же вызывает рост сложности реализации любой фичи, потому что нельзя так просто взять и распарсить код с текстовыми подстановками в виде #define. То есть на самом деле — это крайне непростая задача, и делать ее крайне долго, когда речь идет о рефакторингах, работающих в контексте всего проекта. С локальными проще, и их мы понемногу реализуем.

Идем дальше. Раз в год выходит Xcode. Выход Xcode — это сразу же поддержка изменений в нем, о которых не знает никто. Поэтому часть времени всегда уходит на это. Допустим, с Xcode 8 пару раз сменился формат, в котором хранится документация кода. Один раз полностью изменился, большой кусок пришлось переписывать, а казалось бы, просто документацию отобразить. Тот же ReSharper работает с API плагинов, там ситуация, по-моему более предсказуема.

Смотрим дальше. Есть проблемы в поддержке языка, и в этом смысле мало кому нужны новые фичи, пока имеющееся работает хорошо не всегда. Кроме того, любой рефакторинг завязан на то, насколько корректно работает движок по анализу кода. Плохо работает движок — рефакторинг не гарантирует корректности, в итоге он никому не нужен. Поэтому у нас пока основной фокус на поддержку языка и так будет до тех пор, пока не добьем до состояния, когда действительно будет иметь смысл взяться за рефакторинги.

Еще — по сути весь предыдущий год мы сместили фокус с «примерно пополам исправления и фичи, но фич чуть больше» в сторону «максимум исправлений по самым больным вопросам, а фичи если останется время». Потому что быстродействие и корректность важнее. Почти каждое из реализованных крупных исправлений заметно не сразу, но решает проблемы «по площадям», и среднее время реализации — где-то от полугода. Плюс изменения настолько масштабные, что война с регрессиями тоже отнимает приличное время.

Ну и с фичами если смотреть, тут всегда приходится выбирать. Вот есть Code Coverage, который мы точно можем сделать хорошо. Его используют вообще все. Важнее ли он, допустим, Inline-рефакторинга? С точки зрения пользователей — важнее, это четко видно по трекеру.

Понимаю, что теоретически можно это самому написать, поэтому был бы рад ссылочкам с чего начать)

Плохо работает движок — рефакторинг не гарантирует корректности, в итоге он никому не нужен

Речь о нашем собственном парсере и resolve engine, который является расширением модели IntelliJ. Они у нас свои, потому что SourceKit нужных нам возможностей не дает. Я вот тут достаточно подробно рассказывал, почему. Основное там — нет нормальных кэшей. Без кэшей ни одно сложное преобразование, работающее в контексте проекта или workspace невозможно. Ни одно из сторонних решений эту задачу пока не решило.

SourceKit мы используем для показа ошибок/предупреждений и чтобы получить часть преобразований кода, которые он дает (fix-it), то есть по сути как линтер.

В будущем, посмотрим, к чему приведет движение CLion к clang и возможно, переиспользуем тот же подход для части задач.

Источник

Поделиться с друзьями
Советы экспертов и специалистов
Adblock
detector