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.

Creating high quality Android code – History

I recently started working on a legacy Android code base. This is a massive project with slightly more than 250 000 lines of code, zero tests, lots of code duplication and in general, massive issues.

There’s no consistent formatting, naming or even package structure. I’ve seen classes and activities with 8500 lines of code.

The code is peppered with things like:

The app often crashes with OutOfMemoryError’s, which has led the developers to just catch those as well.

This raises a few issues.

How do you get an objective measure of how bad the code quality is?

This is necessary for a couple of reasons, but the most important in my opinion is to start getting an indication of whether the code is getting better or worse over time.

The simplest solution here is probably tools like static analysis which can give you a standardised metric and maybe test coverage.

All of these numbers are at least somewhat useless, ambiguous and possibly misleading, but tracking them over time in some kind of sensible manner can at least give you an indication of whether your code is improving.

How do you explain to an inexperienced developer why these practices are wrong?

In a recent code review, I called a developer out on catching a NullPointerException. His argument was that he would need to do 3 null checks, so why can’t he rather just catch it once?

My first thought was: “Because it’s wrong”. Everybody knows you never catch unchecked exceptions. My second though was that catching an NPE gives me an instant indication that you don’t know better, so I can’t trust your code and need to be much more careful with anything else you do.

But why? What reasons do I give this developer? Saying “Because it’s wrong” doesn’t help anybody.

How do you start fixing this project?

There are lots of big problems:

  • We are still developing new features. We can’t stop dev to refactor.
  • Which parts of the codebase would most benefit from improvement? This is not necessarily purely a matter of quality. If I have a really bad module, but nobody has touched it for two years, it might not need to be improved.
  • There are less experienced developers on the project. How do you stop them (or the more experienced devs for that matter) from adding more bad code.
  • The lack of tests means that we have to be very careful about how we refactor.
  • The code is not testable at the moment:
    • There is no inversion of control, so most things cannot be mocked out.
    • The app relies on heaps of global state which makes testing harder (It also leads to the aforementioned OutOfMemoryError’s).
  • Where do you start? There are so many major problems, which do you tackle first?

Where to go from here?

I’ll tackle these in upcoming blog posts. I expect this will turn into a fairly big series of posts… I’ll add links to the relevant posts here as I create them.

While I’m specifically referring to Android development, most of what I discuss will make perfect sense to Java developers and I suspect the practices will apply to any development.

This is what I think is necessary at the moment. This list may change as I work on these:

  1. Starting to fix legacy code
  2. Style guides
  3. Identifying problem areas
  4. Best practices
  5. Sensible refactoring
  6. Starting testing?

Living the Buffer values – getting started

In my last post I mentioned that I want to start living the buffer values.That’s great, but those are some pretty big ideas, so I need somewhere to start without feeling overwhelmed…My first thought was to start measuring as much as I can (not a problem… I’m quite the data geek in any case) and then to try and find meaning in that data.This will mainly help me with living smarter and self-improvement.

Around the data, I’ve signed up for Exist (which I’m loving) and I’m trying to find a way to track Pomodoros so I can start honing in on more productivity.

I already use a Fitbit to track my activity and sleep.

The other change I’m making is trying to be more mindful and conscious of bad habits. Here I’m thinking this should help me figure out how to be more positive, grateful and to listen more.

To that end, I’m thinking about starting to use something like the 5 minute journal.

I’ve also installed the Buffer values new tab page chrome plugin, so every time I open a new tab I see one of these values and try to take a moment to reflect on it.

I expect this will be a long journey and I’ll be posting more specific things I’m trying.

Living the Buffer values

I recently came across the set of values that Buffer aspires to, and I actually find them pretty inspiring.

So I decided to start trying to live these values as well.

These are the values:

Some of these I’m pretty good at already:
  • Default to transparency
  • Focus on self- improvement
  • Be a no-ego doer
  • Do the right thing
Some I’ve been working to get better at:
  • Listen first, then listen more
  • Communicate with clarity
  • Live smarter, not harder
And some I really need to work harder at:
  • Choose positivity
  • Make time too reflect
  • Show gratitude
I’ll go into more detail on how I plan to improve these areas in subsequent posts.