Knowing the tools, being an IDE expert and why it matters

Dylan Morley
Jul 2 · 7 min read

If you want to be a faster and more accurate coder, then learning the shortcuts is one of the most important things you can do.

As an engineer, you’ll be working with a variety of code editors that are built to help you read, write, navigate and understand code. You should become an expert user of the IDE (Integrated Development Environment) and dedicate time to learning exactly how the tools you’re using work and how they can make you more efficient.

Learning the shortcuts is guaranteed to make your development and debugging experience easier.

Particularly in a technical interview, where you may be expected to write some code, it immediately impresses when you demonstrate that you know the tools you’re going to be working with everyday. Being able to navigate and find things quickly and letting the IDE write and refactor code for you indicates you have invested time becoming an expert and are less likely to make basic errors.

When you’re writing code manually, you’ll make mistakes. You’ll get the casing wrong on a variable, or miss an underscore — or you’ll simply hit a wrong key and spell it incorrectly. It happens, and that’s why IDEs are packed full of macros and shortcuts which allow you to perform automated change, minimising the amount of manual work and typing you need to do.

This speeds you up so much — allowing you to trust the tooling and let it make large changes for you, confident that it’s 100% accurate.

At ASOS, we actively encourage you to perform automated refactoring and have an internal software crafters course where learning the shortcuts and solving common problems through key-combos is one of the major learning themes. We believe the time you invest in this will pay you back tenfold.

Let’s look at a few examples — the screen captures below are all from Rider. However, most modern IDEs have some sort of refactoring code prompt available and you should memorise the most useful commands.

I’m on Windows, so any key combos I mention are going to be Windows specific — however, your OS equivalent should be simple to find.

Writing class constructs

There are a number of ways to solve this, one is by using the ctorf macro (also available if you are a Resharper user). ctorf generates a class construct and adds whatever fields you have declared in your class as parameters — nice!

Another is by using the Alt-Enter combination over the variable you want to initialise. Alt-Enter is the swiss-army knife of refactors and if you have your cursor on a piece of code, it’s always worth seeing if there’s something that it can do.

By using Alt-Enter over a variable name, I can rename, change it’s access modifier and initialise it from a construct.

Refactor This

In this example, we have a class with no interface and we want to create one and put it in a new file. No manually adding files, no typing file names or writing any code — this is a 100% automated refactor.

Refactor This -> Extract Interface -> Alt+Enter -> Move To ‘FileName’

Extracting to files is a super useful shortcut. If you ever want to write a new class or interface, don’t do this

File -> Add -> Class or Interface -> Type File Name -> Write Code in new File

Just write the new class in an already existing file. Then…

Refactor This -> Move To ‘FileName’

Extracting Methods

The first rule of functions is that they should be small.

The second rule of functions is that they should be smaller than that.

You can see some code that can easily be extracted into its own function — the IDE can do that for you.

Highlight Code -> Extract Method -> Complete Dialog

Note in this example, the refactor understands the context of what is important and what needs to be returned from the extracted method in order for the code to be valid. It correctly identifies countOfThings as the value to return and initialises a variable with that value.


Here, we rename the variable and all four usages are updated. Updating the method name also updates the usage from the calling method.

This is a simple example — in real codebases you’ll often have complex hierarchies with calls from multiple locations, but that’s no problem — all usages are identified across multiple files.

The good thing is, since all change is done in one go you can apply the refactor, inspect the changes and if you don’t like them — Ctrl+Z to undo the entire refactor in one go.

General Refactoring

This let’s you follow the opportunistic refactoring principle and always leave the code behind in a better state than you found it.

Alt+Enter is the combo you’re looking for — I find these are generally sensible suggestions and improve the code. It’s always worth performing the refactor, inspecting the results, then either keeping or undoing depending on whether you think the result is an easier to read, more concise piece of code.

Moving Code


Automated change should be your standard position — let the IDE drive this for you.

Learn the shortcuts. Have a quick link to them in your browser toolbar, or printed out and visible where you work. If you search for whatever IDE you’re using, e.g. ‘Rider Shortcuts’, you’ll find documentation and examples you can use.

Learn them by solving refactoring Katas and challenging yourself to not use the mouse. It really is a case of muscle memory and learning by doing — you’ll find it painful going at first without the mouse, but it pays off every time another shortcut becomes second nature to you.

This matters professionally, you’ll be a faster, more efficient and happier engineer. It allows you to spend more time on the problem you’re trying to solve, rather than basic plumbing and scaffolding. It says to other engineers you’re working with that you’ve learned the tools — they’ll have confidence in you when they see you making large changes with no mistakes.

About me

ASOS is hiring across a range of roles. If you love clean code and are excited by things like ‘Refactor This’ and ‘Alt+Enter’, we would love to hear from you! See our open positions here.

The ASOS Tech Blog

A collective effort from ASOS's Tech Team, driven and…

The ASOS Tech Blog

A collective effort from ASOS's Tech Team, driven and directed by our writers. Learn about our engineering, our culture, and anything else that's on our mind.

Dylan Morley

Written by

Principal Software Engineer,

The ASOS Tech Blog

A collective effort from ASOS's Tech Team, driven and directed by our writers. Learn about our engineering, our culture, and anything else that's on our mind.