Apparently, I’m all about Continuous Learning - after I wrote the last post about IntelliJ Tips, I carried on through my trawl of the documentation and, of course, discovered a load more things I didn’t know. And this is all just in the Quick Start section!
So here’s the next batch (although once again I’m not sure how many are only applicable to IntelliJ 14). All shortcuts are for Windows unless otherwise stated, and Mac users should be able to replace the Ctrl key with Cmd in all these cases.
Navigate between methods
Now I knew you could use the structure thingie (Ctrl+F12) to let you navigate to methods in your class (although I never actually use it, it somehow never sticks in my head). What I did not know is that you can jump between methods using Alt+Up/Down arrows. This strikes me as being super useful, especially to browse tests.
Refactoring String Fragments
I’ve wanted this feature so many times, but could never find it or get it to work - did you know you can refactor out parts of a hardcoded string into variable/field/constant? Select the section of the String you want to extract, and use the normal “Extract…” shortcuts - e.g. Ctrl+Alt+V to extract it into a variable.
I’m sure I’ve tried this before and it didn’t work. But I’ve tested it and it does!
There doesn’t seem to be a keyboard shortcut mapped by default, but using “Refactor -> Invert Boolean…” (or using
our newly discovered “Navigate to Action” shortcut of Shift+Ctrl+A and typing “Invert”) you can tell IntelliJ you want
a boolean field to mean the opposite thing, and it will
flip the meaning everywhere.
For example, you might have an
saved flag, and you now want it to mean
notSaved - IntelliJ will make sure the
isSaved method returns
Magic Refactor Suggestions
You don’t always know exactly what refactoring operation you want to perform, and IntelliJ is ready to help - it can suggest refactorings available in the current context using the catchy magic incantation Ctrl+Shift+Alt+T. Seems useful, but I’m pretty sure I’m not going to remember that one.
Highlight implemented/overridden methods
I love everything about IntelliJ’s ability to find usages of things - finding where methods are called, finding implementations of a method, highlighting usages of a field, method or variable… What I didn’t know, is that you can highlight the methods that implement or override a specific interface or superclass. For some people, this might not add much, as your little “I override something” icon
combined with the
@Override annotation, might tell you all you need to know. But that only really works if you’re implementing a
a single interface. If you’ve correctly separated your concerns, you might implement several interfaces, and want to know
which are the methods from a particular one. That’s where Shift+Ctrl+F7 on the “extends” keyword comes in handy.
Run individual inspection by name
I use inspections quite a lot. They’re especially useful if you have a codebase that doesn’t quite conform to your ideal standards, so you can’t yet turn on automated checks like checkstyle to break the build when the code doesn’t conform - there’s an initial step where first you need to clean up the code. Inspections are great, because you can have IntelliJ give you little yellow marks to show where things are suboptimal, and aim to check in only files without little yellow marks.
What I didn’t know, is that you can run a single inspection on files in any scope. So if, for example, you wanted to make sure that the code you’ve touched in this change has no unused bits, like unused parameters or unused/untested methods, you could press Shift+Alt+Ctrl+I and type “unused”. Select the “Unused Declaration” inspection and choose to run this on all uncommitted files. This will tell you where you can clean up your code, and every commit should make your codebase that little bit better.
Saving Power With Highlighting
I did not know you could easily alter the active errors/warnings, and use that to save power. Quite Interesting.
Auto indent your lines
I almost obsessively reformat my code as I go, pressing Ctrl+Alt+L almost like a muscle twitch. What I’ve just discovered, though, is that there’s a shortcut which will just fix the line indentation, which is probably 80% of what I need anyway - Ctrl+Alt+I.
Fix Evil String Concatenation
I can’t believe I didn’t notice this one earlier - do you know how many times I’ve gone around and manually changed:
System.out.println("This thing " + something + " is " + somethingElse);
System.out.printf("This thing %s is %s%n", something, somethingElse);
Do you??? Anyway you don’t need to - Alt+Enter inside the params will suggest the replacement and do it for you. Nice.
VCS Quick Access
One of the areas where I definitely don’t use IntelliJ to the best of its abilities is the Git integration. I’ve been using SourceTree combined with IntelliJ to do most of my VCS management (I’m so sorry, I’m just not a command line person, I need to actually see it). With the new laptop, I haven’t installed SourceTree yet and I’m going to try and do everything via the IDE. Previously I used the right-click menu mostly for managing VCS operations, occasionally the VCS menu, and did most stuff in the “Changes” window. But now I’ve discovered Alt+“Back Quote” (Ctrl+V on the mac) to bring up the menu of git-shaped operations for this context. To stop you having to hunt all over the keyboard to find what on earth a “Back Quote” is, it’s `, which on both my UK and US (Windows) keyboards is in the top left corner of your keyboard (on the Mac, it’s on the bottom left next to the shift, but you shouldn’t need it since your shortcut is different anyway).
I’ve just discovered that you can commit a change which smushes up into your last commit and fixes it. I’m assuming it commits the new changes and (potentially) an updated commit message into the last change. I really wish I’d known about this earlier, on a number of occasions in the last few months I’ve done this either manually or by doing a rather dangerous soft reset. I will definitely be using this in the future.
The Cursor as a Breakpoint
Did you know that you can use the cursor as a temporary breakpoint? I did not. Well, now you know.
I hope by now none of us developers are doing that icky thing of having “Copy of…” and “Backup of…” filenames and directories to keep track of our versions. We’re all using a VCS of course. But if you’re being strict about making sure that every commit leads to a working build (we all do that, right…?) then sometimes even distributed file systems like git, with its local branches, are too heavyweight for experiments and debugging.
IntelliJ has Local History, which I personally think you should never rely on, but has occasionally saved my bacon in times of strife. It also does this really nice thing (automatically) where it labels versions where the tests passed, so you’ve got some level of confidence that at that point in time, at that revision, things weren’t hideously broken. At the very least, they must have compiled. What I did not know is that you can add your own labels, so you could label some local, non-committed version of the file as “feature x works but y doesn’t” (or probably something much shorter).
I think it looks useful. As I say though, not a replacement for VCS, but a suppliment.
So, that’s the end of Week One at JetBrains, and already I’ve learnt a whole heap of things. I’m sure there’s more to come, so stay tuned!