📜 ⬆️ ⬇️

AppCode 2019.2: Swift 5.1, analysis of code coverage by tests, display of disassembled code and more

Astrologers have announced a week of releases at JetBrains, the number of blog posts has tripled! In fact, this is also a release post, so if you participated in EAP, you already know everything.

If not, be sure to check out the cut, because in this release we not only have analysis of code coverage with tests and display of disassembled code, but also DSL support for Ruby and a lot of other interesting things!

Run with coverage


Language support

Started supporting Swift 5.1:

While in the process, the degree of readiness can be viewed here .

Code folding

Did folding closures:

Closure folding


You can’t just take and highlight a line of code without knowing what specific entities we are dealing with. Therefore, full highlighting is possible only after the complete construction of caches. But we know the keywords of the language in advance and can highlight them - now they are highlighted for Swift, even if indexing with caching has not yet ended:


Enumeration Element Generation

We continue to expand the scope of Create From Usage : now you can create an enumeration element from its use in the code, simply by pressing ⌥⏎:

Create from usage

Usage Search

The search for uses in AppCode searches for specific code constructs (variables, classes, functions, class methods, etc.) - this allows you to greatly narrow the search area compared to full-text. Until recently, for Swift, we only displayed where a particular design is used. In 2019.2, we implemented a grouping of uses by type, so now we can quickly understand also how we use a variable, function or class:

Find usages

Merging lines of code

Nothing special, just now you can glue the declaration and initialization of the variable using Join Lines ( ⌃⇧J ):

Join lines

Auto Imports

There is such a build system - BUCK . The BUCK build system by default uses header maps, the support of which we added a year ago, but did not have time to throw it into auto imports. As a result, after pressing ⌥⏎, a long path to the header was inserted, which is absolutely unnecessary. Now this does not happen, now everything is correct.


Disassembled code display

Colleagues from CLion made the mapping of disassembled code for LLDB in version 2019.1, and we creatively reused it in this release:

Disassembly view

Auto completion

Another useful thing originally made in CLion is the autocompletion of debugger commands in the LLDB console by pressing ⇥ (the same as in a regular console):

LLDB commands completion

Test coverage analysis code

Finally done, and done well. We select the test configuration, click Run With Coverage and leave to finalize the tests, we are happy with the result:

Run with coverage

To the left in the editor are the coverage results:

Coverage results

By clicking on the color indicator, a plate is displayed with the number of calls in this section of the code and useful actions:

Hit count

Coverage statistics are displayed briefly in the Project view, and in more detail in a separate window:


Build, run, debug, and test during indexing

Indexing and building caches is not a fast process, especially on large projects and especially the very first indexation. Nevertheless, you can do some actions with the project while it is going on, for example, build or run the application.

For a long time, these actions were blocked for us, because for normal use of the launch configuration it was necessary to first build caches on the project. Actually, this is not so necessary, therefore, in version 2019.2, we decisively untied the creation of launch configurations from caching, and now you can assemble, launch, debug or test the project immediately after its opening:

Build, Run, Debug and Test during indexing


TextMate Plugin

Often they are asked to add support for some language, which is not the main one for AppCode. Sometimes we do this if we understand that many users really need it, so at some point we dragged a part of WebStorm to ourselves, so that developers on React Native and PhoneGap would be comfortable working with HTML / CSS / JavaScript.

Then came the plugin for Markdown , because any README needs to be able to conveniently and quickly edit. There is also a plug-in for AppleScript made by one of the colleagues simply because he was interested in writing language support.

But you cannot cram the immensity, therefore we cannot implement support for all languages. For example, in iOS development, DSLs made in Ruby (CocoaPods and Fastlane configs) are often found. Initially, the request sounded like “turn on the entire Ruby support”, but in reality these configs are not often edited, and pulling half-RubyMine because of them does not seem reasonable. At the same time, having no support is not good either.

In this release, colleagues from WebStorm included in the default installation a plugin with support for the TextMate bundles, which gives a bunch of languages ​​a simple highlight and auto-completion. We followed their example, and now we also have this:

TextMate Bundles Plugin

Due to some inconsistencies in the support of Fastlane on the part of these bundles themselves, the configuration principle for Ruby DSL is still the same (however, you can help correct this situation).

Shell Script Plugin

Scripts are common in projects, so we have included support for editing them:

Shell script plugin

Commit window

More precisely, there is no longer any separate window - now it has become part of the Local Changes tab :

Commit window

This is the end. Write all questions and suggestions right here in the comments - we will be happy to answer!

AppCode Team


Source: https://habr.com/ru/post/461949/

All Articles