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
Maybe you’ve declared some variables and you now need to initialise them from a construct — definitely don’t start writing it yourself.
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.
Another tool to use as much as possible is the ‘Refactor This’ menu, which offers a multitude of different options depending on the context of your cursor.
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’
Maybe you’re looking at some code and a function is looking a little large and you remember Uncle Bob saying…
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.
Every time you give a variable a better name, you’re helping the next engineer to read the code and understand it easily. In this example, I can be totally confident that renaming a local variable is 100% safe if I let the tooling do it for me. Since the method GetCountOfThings is private, I can also be confident I can rename it without introducing any breaking change.
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.
The IDE is constantly giving you feedback about the state of your code. Learn to look for the cues and listen to the feedback, the IDE is trying to help you. By looking for different highlights & underlines, you’ll understand that there’s a refactoring opportunity — the IDE is telling you that it can do something for you if you put your cursor at the correct location.
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.
Sometimes you need to move blocks of code around, you can use the Expand Selection and Move options to do this for you. Here, I want to select the for loop, then move it up to the top of the method. Note that the IDE gives me feedback about the move, becoming invalid at the top due to the variable and unused when moved to the bottom.
By using the shortcuts, you can take the repetitive tasks of writing code out of the equation. Creating files, renaming variables, extracting methods and moving things— it can all be done for you and in a way that saves you time and is always correct.
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.
I’m Dylan Morley, one of the Principal Software Engineers at ASOS. I primarily work on the back-end commerce APIs that enable our shopping experience.
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.