{"id":17071,"date":"2018-09-06T12:36:50","date_gmt":"2018-09-06T12:36:50","guid":{"rendered":"https:\/\/blog.jetbrains.com\/dotnet\/?p=20042"},"modified":"2018-09-12T01:52:26","modified_gmt":"2018-09-12T01:52:26","slug":"live-templates-file-templates-rider-2018-2","status":"publish","type":"dotnet","link":"https:\/\/blog.jetbrains.com\/pt-br\/dotnet\/2018\/09\/06\/live-templates-file-templates-rider-2018-2","title":{"rendered":"Live templates and file templates in Rider 2018.2"},"content":{"rendered":"

Using live templates and file templates can improve coding efficiency a lot while dealing with repetitive content, boilerplate code and language ceremony<\/strong>. For everyone who hasn\u2019t heard of them:<\/p>\n

\"Invoking<\/p>\n

In previous versions, we could already invoke existing templates. However, seventy developers<\/a> can\u2019t be wrong that editing templates<\/strong> in Rider is one of the most wanted features we miss from good ol\u2019 ReSharper times – besides dotCover integration<\/a> of course! Today we are pleased to announce that the necessary changes have been merged to Rider 2018.2. Be ready to browse and edit live templates and file templates from Rider\u2019s settings dialog!<\/p>\n

Learning the basics<\/h2>\n

Navigating to Rider\u2019s settings dialog, we can find two new nodes Editor | Live Templates<\/strong> and Editor | File Templates<\/strong>. Both nodes can be further expanded to browse available templates by languages. On the right-hand side, we can select from a list of pre-installed and custom templates. Below the list, an editor shows the code for an actual template along with a couple of related settings:<\/p>\n

\"Pre-installed<\/p>\n

For both custom and pre-installed templates, we can set a shortcut<\/strong> that specifies how the templates are invoked.<\/p>\n

The editor for file templates looks roughly the same:<\/p>\n

\"Pre-installed<\/p>\n

Some templates are being used in related quick-fixes and context actions. For instance, the template for Razor MVC View<\/strong> can be invoked from a quick-fix when the view doesn\u2019t yet exist<\/a>. We can modify this template to our needs and still have it deeply integrated into our development workflow.<\/p>\n

Of course, the greatest power is only revealed, when adding custom templates for our individual needs, which can even be shared via DotSettings among our team<\/a>. So how can we do that?<\/p>\n

<\/p>\n

Writing a custom live template<\/h2>\n

Generally, a template is just text that is copied into the current caret position. However, to make it a little more flexible, we can use variables<\/strong> (sometimes also refered to as hotspots or placeholders). Such variables will only get their final value at the time we execute the live template. We can either manually enter a value – usually used for identifiers and other text – or use so-called macros<\/strong>, which can help us finding a value from the current context:<\/p>\n

\"List<\/p>\n

For instance, we could have a template \/\/ TODO $USER$: $END$<\/code> that can help us to add TODO comments in a flexible and convenient way. The $USER$<\/code> variable can be configured to use the current user\u2019s full name<\/em> macro, while $END$<\/code> denotes the final position of the caret. We can jump between variables by hitting TAB<\/kbd><\/strong>. Note that the $USER$<\/code> variable can still be marked as editable, to allow modifications, for instance during pair-programming sessions:<\/p>\n

\"Custom<\/p>\n

At times, we might need to use the same placeholder\/value in multiple places. In that case, we can select which specific occurrence should be the editable occurrence<\/strong>:<\/p>\n

\"Setting<\/p>\n

Other times, we can completely skip to edit a placeholder, like for the template FakeItEasy.A.Fake<$TYPE$>()<\/code> where $TYPE$<\/code> will apply the Guess type expected at this point<\/em> macro. Note that sometimes it\u2019s a good idea to fully qualify the member, since we cannot expect the required namespace to be imported. In this case, Shorten qualified references<\/strong> will automatically clean up things:
\n\"Custom<\/p>\n

Writing custom file templates<\/h2>\n

Out-of-the-box, Rider comes with file templates for classes, enums, test fixtures and many more. The test fixture template is actually written for NUnit – the most commonly used test framework. This is a good opportunity to look at how we can add our own file template<\/strong> that uses xUnit.net along with FluentAssertions to write tests. Here is how it could look like:<\/p>\n

using FluentAssertions;\r\nusing Xunit;\r\n\r\n\/\/ ReSharper disable ArgumentsStyleLiteral\r\n\r\nnamespace $NAMESPACE$\r\n{\r\n  public class $CLASS$\r\n  {\r\n    [Fact]\r\n    public void $NAME$Test() { $END$ }\r\n  }\r\n}\r\n<\/pre>\n
Since test code is in some way different to production code, it comes in very handy that we can also apply certain adjustments to inspection and code formatting. However, alternatively we can also use project-specific settings<\/a>. Basically, this depends on our individual needs.<\/p>\n
We must not forget to add the file template to the quicklist menu<\/strong>:<\/p>\n
\"Adding<\/p>\n
Afterwards, we can create a new file based on our template, by selecting the destination in the Solution View and hitting Alt+Insert<\/kbd><\/strong>:<\/p>\n
\"Invoking<\/p>\n
Remember that we actually defined the test method on only one line? This magic happens if we enable the Reformat<\/strong> option, which will automatically reformat the template output according to the current formatting settings. This is especially helpful to allow templates being used across different solutions with different code styles.<\/p>\n
Download Rider 2018.2 now!<\/a><\/strong>\u00a0We\u2019d love to hear your feedback!<\/p>\n","protected":false},"author":553,"featured_media":0,"comment_status":"open","ping_status":"open","template":"","categories":[1401],"tags":[211,1938,1978],"cross-post-tag":[],"acf":[],"_links":{"self":[{"href":"https:\/\/blog.jetbrains.com\/pt-br\/wp-json\/wp\/v2\/dotnet\/17071"}],"collection":[{"href":"https:\/\/blog.jetbrains.com\/pt-br\/wp-json\/wp\/v2\/dotnet"}],"about":[{"href":"https:\/\/blog.jetbrains.com\/pt-br\/wp-json\/wp\/v2\/types\/dotnet"}],"author":[{"embeddable":true,"href":"https:\/\/blog.jetbrains.com\/pt-br\/wp-json\/wp\/v2\/users\/553"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.jetbrains.com\/pt-br\/wp-json\/wp\/v2\/comments?post=17071"}],"version-history":[{"count":0,"href":"https:\/\/blog.jetbrains.com\/pt-br\/wp-json\/wp\/v2\/dotnet\/17071\/revisions"}],"wp:attachment":[{"href":"https:\/\/blog.jetbrains.com\/pt-br\/wp-json\/wp\/v2\/media?parent=17071"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.jetbrains.com\/pt-br\/wp-json\/wp\/v2\/categories?post=17071"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.jetbrains.com\/pt-br\/wp-json\/wp\/v2\/tags?post=17071"},{"taxonomy":"cross-post-tag","embeddable":true,"href":"https:\/\/blog.jetbrains.com\/pt-br\/wp-json\/wp\/v2\/cross-post-tag?post=17071"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}