Hi, Habr!

Recently released AppCode 2016.2 , a new release of our IDE for iOS / OSX development. Under the cat a lot of gifs and reflections on automated refactorings in Objective-C and Swift.

Swift

Introduce Variable

Introduce Variable (also known as Extract Variable ) is a local refactoring that allows you to automatically extract part of a complex expression into a local variable. Of course, this can be done manually. Print the name of the variable, type it in, assign the necessary expression to it, manually fix everything in the code, check that you didn’t forget to fix every occurrence ... Good habit, and I remember from my own experience, when developing for iOS, it is produced quite quickly.
')
The truth is that this work is routine, and routine tasks are always better automated. For Objective-C, this refactoring was implemented in AppCode for a long time. By the way, an interesting effect of its frequent use is unwillingness to write variable names yourself and generally begin a line of code with the usual “variable type - variable name”.

After all, you can first write an expression - and then automatically select it into a variable by selecting a hint for its name or typing your own:



To implement Introduce Variable for Swift, we had to learn how to handle a huge number of language constructs - after all, to extract a variable, we need to know its type, and this is just one of the conditions.

By default, the constant is always retrieved, and you can change the let to var in a pop-up window:



Well, to make it even easier, you can optionally automatically substitute the type of a variable:



By the way, you don’t need to replace all entries in the code with your hands - AppCode will do it by itself:

Errors and warnings in the code editor window

When you write code, you want to see all errors and warnings right away. And in any case, not after compilation. In this version, we decided to integrate SourceKit to display errors and warnings in the editor:



And also to enable our users to use the same quick fixes that Xcode issues:



In fact, in AppCode, SourceKit is used as an external code linter, and in the meantime we continue to work on new code generation features using the IntelliJ platform.

Spell checker

It would seem that typos in the source code or comments are not so important - after all, they have absolutely no effect on the performance of the library or application. But what if the project becomes public and all these typos fall into the automatically generated source-based documentation? In this case, it is necessary to avoid them, and manually checking a large amount of code is a thankless task.

Now, AppCode is looking for typos in the comments to the code on Swift, as well as in the source code itself - the names of variables, classes and even parts of them, helping to quickly make corrections:



In Objective-C, as in C ++, this is also possible. Moreover, it is one of the mechanisms of the IntelliJ platform, adapted for a specific programming language. In more detail how work with inspections of a code is arranged in AppCode, it is possible to read here .

Live Templates

Live Templates are our source code templates. The point is to give the ability to quickly insert a fragment of the source code by abbreviation, an analogue of snippets in Xcode. What is the difference? For example, using Live Templates can be done like this:



By the way, for Objective-C, the analog is the built-in template with each abbreviation:



What is the magic? The fact that the input fields of values ​​in the AppCode can be sprite. For example, copy the value of the input value from one field to another. Or — as in the for template — to make the input field look for arrays in its neighborhood by which to iterate. The possibilities are not limitless, but they are - and you can read more about them here .

The second basic difference is the ability to wrap the selected fragment of the source code in any expression ( Surround With templates):



In AppCode 2016.2, we added support for all these mechanisms for Swift and made a basic set of templates, similar to the snippet in Xcode.

Input fields for autocompletion

In Objective-C and Swift code there are parameter names - this is the specificity of the language. Manually inserting them is inconvenient, so another basic feature added to this release is the automatic insertion of parameter names and fields for entering values ​​when autocompleting functions and methods in Swift:

Objective c

Complete statement

Among the types of code completion in JetBrains products, it is possible to quickly complete a specific construction in the code: insert a semicolon (even if the cursor is not at the end of the expression), round or curly braces and immediately go on to the next expression. In this version, we have thoroughly refined this type of autocompletion, and now it works like this:

Documentation

We were asked a long time ago to generate document comments for methods and functions in Objective-C, and most requests were limited to a request for functionality similar to VVDocumenter. And if, in our understanding, “properly done support of documentation for Objective-C in AppCode” would be limited to the action “insert comment template with prefilled parameters”, then we would have done it a long time ago - like this:



By the way, autocompletion of parameter names and documentation tags also works:



But this is not enough. The documentation needs to be updated, and anyone who has documented his project at least once knows that making yourself update a comment written once is much more difficult than writing it the first time. Therefore, we implemented the processing of comments in the code so that Rename for parameter names (as it seems to us, the most frequent case of changes) worked correctly:



Extra bonus - the display of such comments in the Quick Documentation window has been greatly improved.

Rename refactoring in mixed code

Swift is a new, actively developing language. But for a long time, it will exist side by side with Objective-C, and developers will use them together. Therefore, we say “refactorings in Swift”, but in reality in most cases we mean “refatorings in mixed code”. In AppCode, Rename has been around for quite some time, both for Swift and for Objective-C entities used from Swift. In this version, we worked on Rename for methods of Swift classes used from Objective-C.

When a class method in Swift does not contain any additional attributes, it is easy to rename it, since the name in Objective-C is the same as the method name in Swift:



Everything becomes much more interesting if the method has an alias, made using the @objc annotation. In this case, when Rename is called from Objective-C, AppCode will determine the name of the function in Swift and will change it:



Another interesting case is the presence of an external name for the function parameter in Swift. For example, for the function function(extParam param:String) corresponding method in Objective-C will be called functionWithExtParam . And we also handle such a case correctly:



While these features are implemented only for methods and classes, in the future we plan to do the same for class fields.

Code formatting

You can write a separate article about code formatting settings in AppCode, but we just briefly note that for Objective-C / C / C ++ two new predefined formatting styles have been added - LLVM and LLDB .

Demo

A small demo (in English) with a demonstration of new features:


All platform changes are well described in the post anastasiak2512 , in it you can read about new features for generating code for C ++ ( Generate operators and Generate definitions ). Traditionally, they are all available in the AppCode.

That's all. Read about other features of the product on our website , stay tuned to our English-language blog , and ask any questions you may have in the comments to this post.