IDE functionalities I cannot live without

The title is of course an overstatement, but in the day-to-day life of someone’s spending hours upon hours in their IDE, I always cannot thank myself enough when a simple functionality or shortcut is saving me minutes/hours of work.

It is a pretty common advise that learning how to properly use your tool is very important to maximize your productivity and potential when you do any kind of work. I think it is even more true for developers since the environment we work in can be so complex and feature dense.

Just focusing on the IDE, the holy place we write our code in, I know I might only be using a fraction of the functionalities it offers me. But every single time I went out of my way, and didn’t say to myself “let’s do that manually”, I ended up learning something that I am now using naturally every day.

Here are some of the functionalities I appreciate the most when using IntelliJ IDEA:

Debugger #

Learning to use the basis of the debugger is very common advice given to beginners developers, and to be fair, I know that a fair amount of experienced developers still under use it, or way less often that what they should.

It helps tremendously with the common situation developers end up facing: debugging a program, wondering where the issue is happening, why they aren’t getting the expected behavior, etc…

Lots of developers will add print statement in their code to display the content of their variables at a certain statement, and it can quickly get very messy, by adding multiple statements in multiple files, still not being able to understand what is happening at every statement during the runtime, etc…

But, with a debugger, you simply put a breakpoint at the statement you want the program to pause, you run it in debug mode, and it will stop. At this point you can look back through the whole call stack to understand how you got here, see the content of your variables, and even evaluate expressions!

You can now resume the program, pause it whenever you want, add other breakpoints and stop at the next one, even progress statement by statement to analyzer thoroughly what is going on.

No need to add print statements or any kind of logic in the codebase. No need to rebuild and rerun the program multiple times.

Shortcuts & Navigation #

Modern IDE will give you a plethora of possible actions. So much, that it is impossible to remember them all. To solve this, you have a shortcut in IntelliJ that let you search all the actions: Ctrl + Shift + A

But for those that you end up using often, that is multiple times a day if not multiple times per hour, you can define shortcuts for instant usage. Here are the ones I always have in mind:

Select next occurrence with Alt + J

Select all occurrences with Alt + Shift + J

Refactor > Rename with Shift + F6

Find occurrences in Files (when the file is selected in the tree navigation) with Ctrl + Shift + F

Replace in Files (when the file is selected in the tree navigation) with Ctrl + Shift + R

Go to file with Ctrl + Shift + N

Select in > project view Alt + &

I actually use the two last ones together, when navigating a monorepo with hundreds of microservices. Since I deactivated the option that open the current file in the project tree (to avoid a mess when navigating a code base), I now navigate in the project tree by going to a file with the Go to File shortcut, then Select in > Project View.

History #

I am not much of a git GUI user, I still prefer the CLI as I have plenty of aliases:

co = checkout
ci = commit
s = status
r = review
p = pull
preb = pull --rebase
lg = log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit
lgrep = ! git log --grep="$1" --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit #
lpath = ! git log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit -- "$1" #
tgrep = ! git log --reverse --tags --simplify-by-decoration --pretty="format:%ci %d" | grep "$1" #
br = branch --format='%(HEAD) %(color:yellow)%(refname:short)%(color:reset) - %(contents:subject) %(color:green)(%(committerdate:relative)) [%(authorname)]' --sort=-committerdate
rm-untracked = ! rm $(git ls-files --others --exclude-standard) #
aliases = ! git config --get-regexp ^alias\. | sed -e s/^alias\.// -e s/\ /\ =\ /
can = ! git commit --amend --no-edit #
rh = ! git reset --hard HEAD~"$1" #
prune-branches = ! echo 'Delete all local branches other than master ? (Ctrl + C to cancel)'; read temp; git branch | grep -v master | xargs git branch -D #
oops = ! git add . && git commit --amend --no-edit #
rd = ! git review -d "$1" #

But sometimes the git GUI can be great, for instance when cherry-picking changes to add to stash. And the visual interface is quite great to self-review your own changes:

Git history also something that is available in the CLI, but which is great in the IDE. The navigation being way simpler, you can just right click on a folder > Git > Show history, and you will be displayed a great interface to navigate all the commits that affected the selected folder’s content, with as much information as you need (author, timestamp, diffs, etc…)

Copilot #

This one can be a bit controversial for certain people, but using GitHub Copilot has been nothing but a net gain of productivity to me. The simple integration of the AI agent in my IDE, helped with:

• Completing instantly long lines or pieces of code
• Generating boilerplate code
• Filling test data
• Generating tests for some code (however, be careful with this one. In most cases generating tests from a piece of code is a wrong practice as, if the code is wrong, the generated tests might only be as wrong, hence the use for tests would be rigged)

However, you have to double, if not triple, check everything that is written for you. As the results can contain errors, hidden bug, or whatever mistakes. No matter how correct and elegant the results are, be doubtful of it. But in the end, we should be also as doubtful about our own produced code.