Android Studio – Set up a custom terminal

In my endless quest to make it unnecessary to leave the IDE, I figured it would make sense to use Git bash as my terminal in Android Studio rather than the default cmd.exe on Windows.

Turns out this is really simple.

1. Open your settings in Android Studio (CTRL-ALT-S) and type ‘terminal’ to find the correct settings.

2. Change the Shell path to Git bash. In my case it was ‘C:\Program Files (x86)\Git\bin\sh.exe –login -i‘. I just  copied this from the start menu shortcut’s properties.

Android Studio Terminal Setup

3. Restart your IDE.

4. Profit. You can bring up the terminal window with ALT-F12, so no need to use the mouse.

Android Studio TerminalOptionally, you can change the console colors in Editor > Colors & Fonts > Console Colors. Just remember to restart your IDE if you change them. If you are on the Darcula theme this is not necessary – everything just works.


My style guides

After starting to work on an Android project that has a lot of inconsistent styles all over the codebase, I decided to finally document what I consider to be the right style for Java and Android.

You can see them on my Github repo:

I’ve also exported my Android studio ‘Code styles’ and ‘Inspections’ to this repo. This is an attempt to get Android Studio to format our code according to these style guides.

By using the same ‘Code style’ settings across the team, we can get Android Studio to enforce the consistency for us.

You should be able to just run the script to copy them to your user folders (or just copy the contents of the config manually if you prefer that).

Android Studio tips – Mouseless development

I heard somebody making the comment that you can tell an expert by the mastery of their tools. Since I’m a developer (and a pretty good one), I figured it’s time to put in some more effort to master my tools (IDE, VCS, etc).

To this end, I’ve been stalking Hadi Hariri ( for the last few weeks and a couple of things he published has really resonated with me.

My Android Studio setupThe first was an article called No tabs in IntelliJ IDEA, which covers what you would expect – How to use IntelliJ IDEA without tabs. I wrote about my setup based on this here: My Android Studio setup.

This set me on a quest to use my mouse less, which eventually led me to Hadi’s Mouseless Driven Development talk, which is beyond awesome.

These 2 pieces of content has made me both more productive and happier (With my RSI, using a mouse is literally painful).

If you want to be a better developer, ditch the mouse.

My Android studio setup

I figured I’d start documenting some of my setup so that I can keep track of it. Most of this works for IntelliJ as well.

I like dark themes, so I use a modified version of the Darcula theme.

Turn off everything possible

One of the most surprising deviations seems to be the fact that I turn off tabs. They take up screen real-estate and make you either use a mouse or scroll through multiple tabs using keyboard shortcuts to find the one you are interested in.

There’s a great article about it here: No Tabs in IntelliJ IDEA

Editor -> General -> Editor Tabs

Placement: None

I also hide ‘Tool Buttons’ and the ‘Navigation Bar’ in the ‘View’ menu. UPDATE: I now turn off the “Toolbar” as well. I was only using the run button and I can use a keyboard shortcut for that 🙂

This is what you end up with:


The great thing with this set up is that it forces you to use keyboard shortcuts. You can easily get away with CTRL+B to select recent files, CTRL+SHIFT+B for recently edited files and double tapping SHIFT to search for anything.

It sounds counter-intuitive, but this is much faster than trying to find the correct tab in the open ones.

I also hide the Project view (and in fact all tool windows) when I’m not using it (ALT + 1 to turn it on or off quickly) and I’ve set it up to Autoscroll to/from Source so that when I open it the file I was in is selected and if I select a new file, it displays in the editor window:

Android Studio Project View

Change fonts and colors

I find this makes the code more readable.

Editor -> Colors & Fonts -> Font

Primary font: Consolas
Size: 14
Line spacing: 1.1

Font settings

Editor -> Colors & Fonts -> Android Logcat:

  • Assert: #9876AA
  • Debug: #6897BB
  • Error: #FF6B68
  • Info: #6A8759
  • Verbose: #BBBBBB
  • Warning: #BBB529

Android Logcat colors

Set up code styles

I’ve saved a version of my code styles in a github repo with an install script:

Creating high quality Android code – Getting started

My previous post highlighted some of the problems working with a legacy codebase (I agree with Michael Feathers that any code that doesn’t have tests is legacy code).

So how do we start refactoring in a situation like this?

Simply put, it is all about managing risk. You want to find the highest impact, smallest risk incremental improvements that you can make without too much effort.

Since we know that we read more code than we write, anything that makes code more readable is probably worthwhile and will make the code more maintainable.

Getting started

So, how do you make code more readable? The first step for me was to get everybody on the same page by creating a style guide for Java and for Android.

Fixing your code style doesn’t necessarily make the code any better, but it does make it more readable.

The next step for us was to start creating a best practice guide for Android. There are a lot of things to keep in mind for performance and stability which can ultimately make or break the user experience. By documenting these, we give new developers a place to start and everybody a place to reference these points.


We also follow the idea of the boy scout rule, which can be summed up as “Leave any code you touch in a better state than you found it”.

This is of course a bit of a slippery slope. Some reviewers argue that it makes code reviews more difficult because it’s hard to see what changes was due to refactoring, and what was specifically related to your task. Personally I think having to work a bit harder in the peer review to make the code more maintainable is a perfectly fair trade-off. One way to make it even easier is to make sure that you separate refactoring changes into their own commits.

Of course, if you don’t have test coverage you have to be very careful with the type of refactoring you do and focus on low risk items.

Peer review

Now that we have style guides, best practices and a plan to start refactoring, we need tho start enforcing it. The simplest way to do this is by starting to do peer reviews. Ideally, for styling, naming, etc, you should also get a CI server set up and running static analysis.

I tend to see a lot of pushback against peer reviews, but as long as you can create an environment where peer reviews can be constructive and can give feedback on the code without having people feel that they are being judged, there are no better way to drastically improve your code quality over time.

In summary

So, in summary, the low hanging fruit which you can start picking off without too much risk or effort:
  1. Create a style guide
  2. Create a best practice guide
  3. Do opportunistic refactoring. Refactor low risk items like styling, naming and big methods while you are working on the code.
  4. Start peer reviewing ALL code to make sure people adhere to style and best practice guides and that they are leaving the code in a better state than they found it in.